Rearranging sig and pubkey order before broadcasting an m-of-n transaction

[No_2]

From what I understand to redeem an OP_CHECKMULTISIG the sigs need to be presented in the right order. Only the sigs are required in the input for P2PKH as the pubkeys (Edit: pubkeyhashs) are already provided in full in the output of the previous transaction. But for P2SH both the pubkeys and sigs are required as the script output is provided only as a hash.

So to take the following example:

Code:

5 <AlicePubKey> <BobPubKey> <CharliePubKey> <DavePubKey> <EvePubKey> <FrankPubKey> <GregPubKey> <HilderPubKey> 8 OP_CHECKMULTISIG

Wold be satisfied by:

Code:

<BobSig> <DaveSig> <FrankSig> <GregSig> <HilderSig>

So my question is if I wish to redeem an existing P2SH output for which I need 5 of the 8 signatories to sign, and I have 5 of the sigs (and pub keys for P2SH) for an appropriate redeeming transaction, but I received the sigs out of order, can I rearrange the sigs to make the transaction valid before I broadcast it to the network?

Have I understood this correctly, e.g. are there any dependencies between the sigs etc that I may be unaware of.

[1714116719]

1714116719

[1714116719]

1714116719

[hhanh00]

There are no dependencies between signatures.

[No_2]

Thanks.

Is there a call to send a sig between clients? Or does this have to be done via another medium?

[fbueller]

No, there is no medium for exchanging signatures. I'm working on something to facilitate requesting a signature for an input at the moment, I think it's an interesting problem.

If you have all required signatures, and knowledge of the redeemScript, you can build a valid transaction:

• For each input, calculate the message hash (for ECDSA)
• Check all input signatures against against the message hash, and link signatures to a public key
• Looping through the public keys in the script (the necessary order) you can now build the correct script

Each input has as unique message to be signed, but in P2SH, all parties are signing the same data. So you can extract signatures from 5 partially signed transactions and compose them into a fully signed one, so long as none of the data captured by the signature has changed (other inputs, output values/scripts, locktime, etc)

[DeathAndTaxes]

Only the sigs are required in the input for P2PKH as the pubkeys are already provided in full in the output of the previous transaction.

Correction, the output contains only the pubkeyhash not the pubkey so the ScriptSig will need to provide both the Signature and the PubKey.  There is only one possible order however.

can I rearrange the sigs to make the transaction valid before I broadcast it to the network?

Yes.  The ScriptSig is mutable.  You or anyone can change the order of the Signatures.  The person broadcasting the txn will need to ensure they are in the correct order before broadcasting.  If in an invalid order the txn will be dropped as invalid.  Technically nodes could be designed to change the order as necessary and 'fix' the txn for you but they don't as that could be used as a DDOS vector.  Keep in mind that changing the order of the signatures (or anything in the ScriptSig) will change the TxId.

[No_2]

Only the sigs are required in the input for P2PKH as the pubkeys are already provided in full in the output of the previous transaction.

Correction, the output contains only the pubkeyhash not the pubkey so the ScriptSig will need to provide both the Signature and the PubKey.  There is only one possible order however.

Opps, yes the pubkeyhash not the pubkey. I'm guessing the pubkey is not expressed twice in the input script for P2SH use of OP_CHECKMULITSIG?

...can I rearrange the sigs to make the transaction valid before I broadcast it to the network?

Yes.  The ScriptSig is mutable.  You or anyone can change the order of the Signatures.  The person broadcasting the txn will need to ensure they are in the correct order before broadcasting.  If in an invalid order the txn will be dropped as invalid.  Technically nodes could be designed to change the order as necessary and 'fix' the txn for you but they don't as that could be used as a DDOS vector.  Keep in mind that changing the order of the signatures (or anything in the ScriptSig) will change the TxId.

Where ScriptSig is the sig and pub key?