MultiSig address based on the same repeated public key

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: BrewMaster on November 24, 2019, 06:31:55 AM

you can't test what achow said by "broadcasting" the transaction because when you broadcast it, your transaction is subjected to standard rules and as he explained this is a non-standard tx and will be rejected.

to test whether it was right or not, you have to "mine" the transaction and see if the block that contains the tx is rejected or not.
you can probably do it in testnet or regtest.

Null dummy is actually a consensus rule, I forgot that that was part of the Segwit soft fork as BIP 147.

You don't need to test on regtest or testnet to check if a transaction is consensus valid. The getblocktemplate RPC allows you to submit block proposals. Block proposals are just blocks but with invalid PoWs. The block proposal is verified exactly like a normal block except that the PoW is not checked. So you can create a block proposal with whatever non-standard transactions you want in it and Bitcoin Core will check whether they are consensus valid. The only caveat is that the transactions they spend must already be in the blockchain or included as part of the block proposal. I have a Python script that constructs and submits the proposal for you.

Quote from: MrFreeDragon on November 24, 2019, 04:55:30 AM

Thank you. Probably you are right. For m/n multisig wallet there should be exactly m signatures, and not more.

...

It seems that it is the issue with multisig accounts. Multisig m/n wallets should be signed exactly by m signatures, not less and not more. But why is this the issue? It is illogical: if 7 signatures are required to release funds from 7/10 multisig account, why more signatures (8,9 or 10) can not do it?

The reason is transaction malleability. The null dummy consensus rule was put in place to enforce that third parties cannot just modify the dummy element or other parts of the scriptSig in order to change the transaction id without causing the transaction to become invalid. Transaction malleability has, and continues to, cause problems for wallets because they are seen as double spends. Prior to the null dummy rule (which came with the segwit soft fork), you could have more signatures. You could have invalid signatures on the stack. You could have a dummy element that was whatever you wanted. In fact, most of those you could have now. You can put your extra signatures after the dummy element and they will be consensus valid. Those signatures aren't being viewed as signatures by the script interpreter, just bytes on the stack. The reason that your transactions do not work is because the item on the stack that the interpreter views as the dummy element is not what you intended the dummy element to be.

BrewMaster

legendary

Activity: 2128

Merit: 1293

There is trouble abrewing

Quote from: MrFreeDragon on November 24, 2019, 04:55:30 AM

I have just tested with 1/2 multisig wallet and signed the outgoing tx with 2 signatures (more than required 1), and this transaction was not accepted with the same error as described in OP:

you can't test what achow said by "broadcasting" the transaction because when you broadcast it, your transaction is subjected to standard rules and as he explained this is a non-standard tx and will be rejected.

to test whether it was right or not, you have to "mine" the transaction and see if the block that contains the tx is rejected or not.
you can probably do it in testnet or regtest.

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Quote from: achow101 on November 23, 2019, 08:24:42 PM

The transaction itself is not consensus invalid. It is merely non-standard which means it will not be accepted for relay by most nodes. You can fix this by just removing the extra signatures.

Thank you. Probably you are right. For m/n multisig wallet there should be exactly m signatures, and not more.

I have just tested with 1/2 multisig wallet and signed the outgoing tx with 2 signatures (more than required 1), and this transaction was not accepted with the same error as described in OP:

Code:

0100000001127d74781621dfee3f898a6aa2b27d7e42f640402b20502b4ea80c741f5d02b501000000da00483045022100df4c09df0951eea224e900388b47ef020bd0b2f87748c80eabee8a8d0ae4e7a702205751e2b91aae0e5720878b45befd63fc60cd4e74d7370b13e69dfed338e100ea0147304402207b9559cafd32bae0eb4826616b65a8dec5c916c30f071aa4616bfbba23efd22602207bfab004c3b5a1389ff4d84eb7e2b80583088a87475f4c0225ee79e0026de207014751210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179852aeffffffff02384a00000000000016001485cd618735e8c2101ca908b7ac3d616b0d4c26cc10270000000000001976a91404e0fb570daf91ea5cb64443d05989979a6716de88ac00000000

If I sign the same transaction with just one signature (as required), it is accepted by the network:

Code:

0100000001127d74781621dfee3f898a6aa2b27d7e42f640402b20502b4ea80c741f5d02b5010000009200483045022100df4c09df0951eea224e900388b47ef020bd0b2f87748c80eabee8a8d0ae4e7a702205751e2b91aae0e5720878b45befd63fc60cd4e74d7370b13e69dfed338e100ea014751210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f8179852aeffffffff02384a00000000000016001485cd618735e8c2101ca908b7ac3d616b0d4c26cc10270000000000001976a91404e0fb570daf91ea5cb64443d05989979a6716de88ac00000000

Quote from: BitcoinGirl.Club on November 23, 2019, 10:51:12 AM

Quote

I suppose that it is because 10 signatures were added to the signed transaction, but only 7 are required.

I think this is not the issue here. You can sign with all the keys you have but the minimum needs to be 7 since this is a 7/10 wallet.

It seems that it is the issue with multisig accounts. Multisig m/n wallets should be signed exactly by m signatures, not less and not more. But why is this the issue? It is illogical: if 7 signatures are required to release funds from 7/10 multisig account, why more signatures (8,9 or 10) can not do it?

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: MrFreeDragon on November 23, 2019, 07:39:33 PM

If I check the signed transaction, it looks fine and has 10 signatures out of 10 (however only 7 are required).

There's your problem. It is non-standard to have those other 3 signatures because they are not consumed by the OP_CHECKMULTISIG.

The way that OP_CHECKUMULTISIG works is that it takes a signature and checks it against each of the public keys to find the one it verifies to. It does this until the threshold has been met. A quirk (bug) of the implementation is that it consumes one extra element but doesn't do anything with it. A standardness rule dictates that that extra element is a 0 (the byte 0x00). This element is known as the Dummy element. Since in your transaction you have extra signatures, one of those extra signatures becomes the dummy element, and because it is not null, fails the standardness check.

Additionally, even if that element was 0, you would still have extra items on the stack which is also non-standard.

The transaction itself is not consensus invalid. It is merely non-standard which means it will not be accepted for relay by most nodes. You can fix this by just removing the extra signatures.

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Quote from: achow101 on November 23, 2019, 06:42:21 PM

Can you post the signed transactions so that we can examine it?
How did you create the multisig? How did you sign the transaction?

I used coinb.in

Here is the signed transaction:

Code:

0100000001ef446ea4384879ddec294424279451cdd6f4edaa5b0d40cd767cf71a5a15a1b400000000fd2b040047304402202c0a5676c83ea2735063373eb20fff5f2b3341f5c3326a683f69455971e3a7b5022065c6a3ef165b91ab698dbb9f000df02946d9299c9274bcfcd19473495de700410147304402202c0a5676c83ea2735063373eb20fff5f2b3341f5c3326a683f69455971e3a7b5022065c6a3ef165b91ab698dbb9f000df02946d9299c9274bcfcd19473495de700410147304402202c0a5676c83ea2735063373eb20fff5f2b3341f5c3326a683f69455971e3a7b5022065c6a3ef165b91ab698dbb9f000df02946d9299c9274bcfcd19473495de700410147304402202c0a5676c83ea2735063373eb20fff5f2b3341f5c3326a683f69455971e3a7b5022065c6a3ef165b91ab698dbb9f000df02946d9299c9274bcfcd19473495de700410147304402202c0a5676c83ea2735063373eb20fff5f2b3341f5c3326a683f69455971e3a7b5022065c6a3ef165b91ab698dbb9f000df02946d9299c9274bcfcd19473495de700410147304402202c0a5676c83ea2735063373eb20fff5f2b3341f5c3326a683f69455971e3a7b5022065c6a3ef165b91ab698dbb9f000df02946d9299c9274bcfcd19473495de700410147304402202c0a5676c83ea2735063373eb20fff5f2b3341f5c3326a683f69455971e3a7b5022065c6a3ef165b91ab698dbb9f000df02946d9299c9274bcfcd19473495de700410147304402202c0a5676c83ea2735063373eb20fff5f2b3341f5c3326a683f69455971e3a7b5022065c6a3ef165b91ab698dbb9f000df02946d9299c9274bcfcd19473495de700410147304402202c0a5676c83ea2735063373eb20fff5f2b3341f5c3326a683f69455971e3a7b5022065c6a3ef165b91ab698dbb9f000df02946d9299c9274bcfcd19473495de700410147304402202c0a5676c83ea2735063373eb20fff5f2b3341f5c3326a683f69455971e3a7b5022065c6a3ef165b91ab698dbb9f000df02946d9299c9274bcfcd19473495de70041014d570157210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817985aaeffffffff013f0600000000000016001485cd618735e8c2101ca908b7ac3d616b0d4c26cc00000000

The multisig redeem script is:

Code:

57210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798210379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f817985aae

If I check the signed transaction, it looks fine and has 10 signatures out of 10 (however only 7 are required).

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Can you post the signed transactions so that we can examine it?

How did you create the multisig? How did you sign the transaction?

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Also tried 2/2 and 3/3 multisig accounts created from the same repeated public key - just one signature is required, and funds are successfully released.

But for 1/2 multisig account I meet the same error as for 7/10 account described in OP: 64: non-mandatory-script-verify-flag (Dummy CHECKMULTISIG argument must be zero)

I also tried to broadcast in different networks - the same error.

BitcoinGirl.Club

legendary

Activity: 2800

Merit: 2736

Farewell LEO: o_e_l_e_o

Quote from: MrFreeDragon on November 23, 2019, 10:42:47 AM

For some test purposes I have created the 7/10 multisig address based on the same public key repeated 10 times (the same public key was used 10 times rather than 10 different). For the release condition I used 7 signatures.

Very peculiar experiment and it makes sense. Not sure if anyone else had this idea before you LOL

Quote

I suppose that it is because 10 signatures were added to the signed transaction, but only 7 are required.

I think this is not the issue here. You can sign with all the keys you have but the minimum needs to be 7 since this is a 7/10 wallet.

MrFreeDragon

sr. member

Activity: 443

Merit: 350

For some test purposes I have created the 7/10 multisig address based on the same public key repeated 10 times (the same public key was used 10 times rather than 10 different). For the release condition I used 7 signatures.

I transferred small amount to this address, but now can not release it. While I sign the output transaction I use the private key once, and as the private key refers to every of 10 addresses, it adds 10 signatures. And finally I received the signed message 10/10, but only 7/10 is required.

When I broadcast the signed transaction, I receive the error: non-mandatory-script-verify-flag (Dummy CHECKMULTISIG argument must be zero) (code 64)

I suppose that it is because 10 signatures were added to the signed transaction, but only 7 are required.
Do you know now to release funds from my test multisig address?

PS. Before this I created 2/2 multisig account based on 2 different public keys generated from the same private key (one public key was compressed, another was uncompressed). It was not possible to release the funds signing by 2 signatures. But after that I tried to sign only once with one compressed address signature, and it added all 2 required signatures to the transaction and released it. It is interesting - for multisig addresses it does not mean if the private key compressed or not.

Topic: MultiSig address based on the same repeated public key (Read 180 times)