BIP210 Proposal (DOA)

Considering current P2SH (multisiginature) implementation in bitcoin-core [bitcoin.org] ,for any set of 3 public keys we have six possible 2 out of 3 multisig addresses. The order of the keys in the set has direct effect on address generation and even signing one multisignature transaction.

let me show you what I mean:

let’s say we have these 3 addresses to begin with:

Address 0: 12irNBGCHnwjd8DN8YBJxvGv7kwYNv9q6B

Public Key: 03ea446154132cb6828711cee60ce99713130bba9d0e1c504086997b76b9e81995

 

Address 1: 1HjRTzGLofwaUk1YaZZJFuJLBxTr6PqQir

Public Key: 0312db381f3138882a0b313032659e27d8d4d8ea154c467532b815804b26b0b1df

 

Address 2: 1KmmW1wRBM65DNztaVczqFsz3qWhkKmPid

Public Key: 0382bd8f573c6e452084ed0cb1f61f6495eb48c1eb5f7c067cc933a229ed9d5982

All the possible orders:

==================

keys[0], keys[1], keys[2] keys[0], keys[2], keys[1] keys[1], keys[0], keys[2] keys[2], keys[0], keys[1] keys[1], keys[2], keys[0] keys[2], keys[1], keys[0]

==================

Or to be more exact all the possible 2 out of 3 multisig combinations:

0 <0232ad80a4683e51117cf14340f3fa6a96cd8909603038f8384403b380ae552a29>

1 <030e8e0d4c5d5442bd4daa598f8e36d7c3f230274deb6d014f633e5951597d1d4e>

2 <02f46cd541b8d3262b9f426dd04bde5c47e2a661ce20e0d2c1a203b268898637a8>

Multisig address: 38H6Ug5FQLkidbYnFsDybtZhbciQBMWKWM

 

0 <0232ad80a4683e51117cf14340f3fa6a96cd8909603038f8384403b380ae552a29>

2 <02f46cd541b8d3262b9f426dd04bde5c47e2a661ce20e0d2c1a203b268898637a8>

1 <030e8e0d4c5d5442bd4daa598f8e36d7c3f230274deb6d014f633e5951597d1d4e>

Multisig address: 3QYJynJXkdbW5AwHqhaLmuw4dxKqXWQHG2

 

1 <030e8e0d4c5d5442bd4daa598f8e36d7c3f230274deb6d014f633e5951597d1d4e>

0 <0232ad80a4683e51117cf14340f3fa6a96cd8909603038f8384403b380ae552a29>

2 <02f46cd541b8d3262b9f426dd04bde5c47e2a661ce20e0d2c1a203b268898637a8>

Multisig address: 3JbuTp76yX4XtxEhD3hee85P4eENvzSGop

 

2 <02f46cd541b8d3262b9f426dd04bde5c47e2a661ce20e0d2c1a203b268898637a8>

0 <0232ad80a4683e51117cf14340f3fa6a96cd8909603038f8384403b380ae552a29>

1 <030e8e0d4c5d5442bd4daa598f8e36d7c3f230274deb6d014f633e5951597d1d4e>

Multisig address: 333uo1hVEaju9Wz5xRDmfqQdcX1p9J3SSB

 

1 <030e8e0d4c5d5442bd4daa598f8e36d7c3f230274deb6d014f633e5951597d1d4e>

2 <02f46cd541b8d3262b9f426dd04bde5c47e2a661ce20e0d2c1a203b268898637a8>

0 <0232ad80a4683e51117cf14340f3fa6a96cd8909603038f8384403b380ae552a29>

Multisig address: 3P4UQoM6qkAdiWURRowa3fTTYdPM1i1dXw

 

2 <02f46cd541b8d3262b9f426dd04bde5c47e2a661ce20e0d2c1a203b268898637a8>

1 <030e8e0d4c5d5442bd4daa598f8e36d7c3f230274deb6d014f633e5951597d1d4e>

0 <0232ad80a4683e51117cf14340f3fa6a96cd8909603038f8384403b380ae552a29>

Multisig address: 3Q6owwdB7ckuF99R8DX4xPbjvZVttiHQzC

So we end up having:

All the possible 2 out of 3 multisig addresses: 

  1. 38H6Ug5FQLkidbYnFsDybtZhbciQBMWKWM
  2. 3QYJynJXkdbW5AwHqhaLmuw4dxKqXWQHG2
  3. 3JbuTp76yX4XtxEhD3hee85P4eENvzSGop
  4. 333uo1hVEaju9Wz5xRDmfqQdcX1p9J3SSB
  5. 3P4UQoM6qkAdiWURRowa3fTTYdPM1i1dXw
  6. 3Q6owwdB7ckuF99R8DX4xPbjvZVttiHQzC

As a software developer perspective this is madness, as a hacker bitcoiner kind of view, this is how everything should be in the first place, no limits on choices, per say.

But we need a standard in the software library level, at least to make sure a set of 3 keys would generate the sam emultisignature address on one application that was generated on the other.

BIP201 proposal:

 Lexicographically sort of pubkeys in multisig

(address generation and signing)

I’m glad I didn’t start writing the BIP proposal first and had to implement a multisig mult-device wallet. That’s when I realized It’s not such a great idea to sort addresses by default, because it would introduce some logical issues to multisig applications.

Let’s say we have the combination of (keys[2] ,keys[1] ,keys[0]), and here would be one of the multisignature wallet implementations that seems practical:

  1. Client makes the unsigned transaction
  2. Client signs the transaction using keys[0] and sends the partially signed transaction to the server
  3. Server receives the transaction
    1. checks the statements (multisig security stuff, while list/blacklist addresses or other implementation of multisig ideas)
    2. signs using keys[1] and broadcast to the network

So let’s say the server goes down and now it’s time to use your backup key to save your funds from the multisignature address. So let’s implement it this way as a practical -first way that comes in mind- implementation :

  1. Client makes the unsigned transaction
  2. Client signs the transaction using keys[0]
  3. Using the Back up signing tools Client signs the partially signed transaction using keys[2]
  4. Client broadcasts the transaction to the network

So the signed transaction ends up being invalid and client fails to broadcast it to bitcoin network.

Here is why [bitcoin.org]:

Warning icon OP_CHECKMULTISIG warning: The multisig verification process described above requires that signatures in the signature script be provided in the same order as their corresponding public keys in the pubkey script or redeem script. For example, the following combined signature and pubkey script will produce the stack and comparisons shown:

OP_0 <A sig><B sig> OP_2 <A pubkey> <B pubkey> <C pubkey> OP_3

Sig Stack       Pubkey Stack  (Actually a single stack)

———       ————

B sig           C pubkey

A sig           B pubkey

OP_0          A pubkey

1. B sig compared to C pubkey (no match)

2. B sig compared to B pubkey (match #1)

3. A sig compared to A pubkey (match #2)

Success: two matches found

—————————————————

But reversing the order of the signatures with everything else the same will fail, as shown below:

OP_0 <B sig> <A sig> OP_2 <A pubkey> <B pubkey> <C pubkey> OP_3

Sig Stack          Pubkey Stack  (Actually a single stack)

———            ————

A sig           C pubkey

B sig           B pubkey

OP_0          A pubkey

1. A sig compared to C pubkey (no match)

2. A sig compared to B pubkey (no match)

Failure, aborted: two signature matches required but none found so far, and there’s only one pubkey remaining

——————————————————-

It’s not a big deal at all, it just means if you design your wallet system based on the described system above, the production wallet would fail to use the backup key to sign a transaction on some of the multisig addresses (with the one-third probability of happening)  and would need a redesigned client application to use the backup key first, that might end up changing the the designed concept of importing/signing with backup key on the application.

 

%d bloggers like this: