Public Verification of P2WSH Threshold Multi-Signature Addresses

[da2ce7]

Hello BitcoinTalk,

I have been asked to help the Grin community verify their Bitcoin P2WSH Threshold Multi-Signuture Address.

They have a 4 out-of 6 address, however need to prove to the community that they have access to all six keys.

https://github.com/grincc/security/issues/1


The proposed solution was to create a transaction that 'oversigns' with 6 keys, included and include that transaction on the blockchain.

They created a test transaction:
https://blockstream.info/tx/cfbc3792e42a6832825f5b4f9dcb264d7a84662f0365661a05c1db591546bac3?expand

In the process they had all six keys sign the transaction.  However when viewed on the blockchain it seems that only four of the six signatures are present.

Maybe this is a bug in electurm? It truncates the unseeded signatures, maybe to save on blockchain space? However this is exacly not what we want in this case.


Overall it would be great to get some feedback on how to properly verify and collate the keys and signatures of multi-signature transactions.  Some sort of nice GUI that displays the information clearly would be of great help.

[BlackHatCoiner]

Your case seem very rare. You want to have a 4-of-6 multi-sig, but if 6 out of 6 have signed the transaction, you want it to be shown. A quick solution that comes in my mind is to create another 6-of-6 wallet (with the same xpub keys) and move the money from the 4-of-6 address to a 6-of-6's address. If you did that, then in the blockchain it'd be clear that all of the co-signers of the 6-of-6 address agree upon that transaction.

[ranochigo]

Your case seem very rare. You want to have a 4-of-6 multi-sig, but if 6 out of 6 have signed the transaction, you want it to be shown. A quick solution that comes in my mind is to create another 6-of-6 wallet (with the same xpub keys) and move the money from the 4-of-6 address to a 6-of-6's address. If you did that, then in the blockchain it'd be clear that all of the co-signers of the 6-of-6 address agree upon that transaction.

I think OP's point is for redundancy, in case of certain disagreements so at least 4 of 6 of the parties can agree on it and the approval of the final 2 isn't needed. Moving it to a 6-of-6 musig wouldn't make that much sense in comparison.

Wallets should probably discard excess signatures for obvious reasons, because it is quite rare for people to have to prove that all of the parties are in control of their keys. Would it be possible for you to just create 2 transactions, with one of the parties signing both TXes and the other parties being unique.

[pooya87]

Maybe this is a bug in electurm? It truncates the unseeded signatures, maybe to save on blockchain space? However this is exacly not what we want in this case.

No, in case of a P2WSH (or any other SegWit transaction) it is a consensus rule that mandates the stack to be empty after execution. If you include more signatures they won't be popped so the stack remains un-empty after evaluation so the transaction verification fails.

If this were P2SH then it would simply be non-standard but at the same time those extra signatures could be anything like random data instead of a valid signature. Which means even if the blockchain contained such a transaction it doesn't mean validity.

The idea of using OP_CheckMultiSig with m < n is flawed on its own because the script is not designed to verify all signatures. Instead extra self-defined rules should be used in form of an OP_Return where n signatures are placed in the script itself and m-n signatures are placed in OP_Return output for the "other protocol" to verify.

[da2ce7]

Thankyou, I have updated the GitHub issue with you sugestion

Would it be possible for you to just create 2 transactions, with one of the parties signing both TXes and the other parties being unique.

I agree with @ranochigo idea, it's most practical idea to prove that all 6 keys are accessible. Additionally, mentioning which key will be used and other detail (such as receiving address with it's amount) on both transaction makes it more convincing.

P.S. I would recommend sign message 2 times with different set of keys, but i don't remember if there are any wallet which support such feature.

[Anynomous0]

Thank you all for your suggested solutions .
I agree that making two transactions would indeed offer the simplest solution, the Grin Community Council can use this method for the time being.
However, because I do think it would be great to have a general solution for MultiSig holders that does not have the costs of an extra transactions, I will finish a script I am working on to parse the signatures from the Partially Signed Bitcoin Transaction text (PSBT, BIP174) and I will provide simple Python script to verify all the signatures. This script will be made available as an open source solution.

For future references, I would also like to note that a transaction does not prove the time of signing unless a time proof such as a recent blockhash is provided in an OP_RETURN statement. So for perfect security, proof of time should be signed to, similar to how the text in the first Bitcoin transaction proofs its time of creation.

Link to PSBT, BIP174:
https://bitcointechweekly.com/categories/consensus

[NotATether]

If the total number of signatures is known in advance, as in your case, you can write a non-standard scriptPubKey (replace with redeem script if you're using P2WSH-P2SH, which has a P2SH script wrapped around it) which looks something like:

OP_DROP OP_DROP OP_4 <include all six public keys> OP_6 OP_CHECKMULTISIG

OP_DROP removes the extra elements, in this case, the first two signatures from the stack.

In the scriptsig you place:

<first signature>
<second signature>
OP_0 <--- necessary because of a bug in OP_CHECKMULTISIG
<third, fourth, fifth, sixth signature>

Then you're basically signing with the last four public keys. The first two public keys are in the scriptsig but aren't automatically verified but they can be verified manually.

[pooya87]

OP_DROP OP_DROP OP_4 <include all six public keys> OP_6 OP_CHECKMULTISIG

The problem with anything like this is that the 2 signatures won't be validated ever which means they might as well be arbitrary data.

Here is an idea, use OP_IF.
Redeem script:

Code:

OP_IF OP_4 OP_ELSE OP_6 OP_ENDIF <pub 1 to 6> OP_6 OP_CHECKMULTISIG

What this does is that it lets the signer decide what number for "m" they want to push to the stack. If the provide TRUE to OP_IF it will push m=4 but if they provide FALSE it pushes m=6. This way the redeem script is still pretty simple and short but at the same time it provides both 4of6 and 6of6 multi-sig.

To spend from this you'll use the same signature script as you were before but with a OP_1 before the redeem script and to provide proof (needing all 6 sigs) use OP_0 something like this:
Spending tx:

Code:

OP_0 <sig 1 to 4> OP_1 <RedeemScript>

Proof tx:

Code:

OP_0 <sig 1 to 6> OP_0 <RedeemScript>

[Anynomous0]

I have a Python script up and running that checks the signature with the same witness script (4 out of 6) using the cryptotools python package. I replace the first signature each time with one of the two additional keys and verify the script.
https://github.com/mcdallas/cryptotools

Unfortunately I heard  from others who tried it they get a lot of errors when installing the library. I will contact the owner of the package to try to solve these issues.
The solution is not perfect yet, since it does check the 6 signatures, but in theory, one of the six MultiSig holders could have generate the additional signatures making sure he/she is the first one to sign, the script would replace her own signature with the additional signature he/she provided.....

While writing this I think I found the solution!
Currently, I only replace the first signature each time with one of the 2 additional keys provided.
If I try to replace every one of the 4 signatures with each of the additional 2 signatures, this proves it is not a signature from one of the 4 key holders! If one of the key-holders from the original 4 signatures in the online transaction would have created the additional signatures, the script would fail when replacing 3 out of the 4 signatures present in the witness script, since the transaction would only be valid when replacing your own signature, in the other cases, 2 signatures are presented for one public-key leaving only two additional signatures, meaning only 3/4 signatures are valid.