SIGHASH precedence for multisig? - page 2.

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: amaclin on March 02, 2016, 11:04:02 AM

Quote from: jl777 on March 02, 2016, 10:25:15 AM

I can verify it is a valid signature, but what happens if there is SIGHASH_ALL for one sig, SIGHASH_SINGLE for another and SIGHASH_ANYONE_CAN_PAY for the third sig for the same input.

It is not a problem.
let me give you some pseudocode:

byte[] pubkey = getPubkey ( );
byte[] param = getSignaturePlusHashtype ( ); // signature concatenated with hash type
byte[] signature, int hashtype = param.split ( ); // get bare asn1 signature and 1-byte hashtype
byte[] digest;
switch ( hashtype )
{
case SIGHASH_ALL : digest = tx.createDigest ( all ); break;
case SIGHASH_NONE: digest = tx.createDigest ( none ); break;
}
verify ( signature, digest, pubkey )

Thanks you, but this is not the question. Assume the sigs verify. see above response

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: TierNolan on March 02, 2016, 10:56:22 AM

Quote from: jl777 on March 02, 2016, 10:25:15 AM

I can verify it is a valid signature, but what happens if there is SIGHASH_ALL for one sig, SIGHASH_SINGLE for another and SIGHASH_ANYONE_CAN_PAY for the third sig for the same input.

You compute the transaction for each signature separately. You can't just work out the hash once, you have to do it for each of the signers (if they use different sighashes)

I understand this.

My question is AFTER it is validated, what does it mean?

Assume all the sigs verify. My understanding is that SIGHASH_SINGLE would affect things differently than SIGHASH_ALL, so with a valid SIGHASH_SINGLE and a valid SIGHASH_ALL mixed together in the same vin (from different multisig signers). Do I treat that input as a SIGHASH_SINGLE or SIGHHASH_ALL as it pertains to the side effects that go beyond the scope of vin itself. Or do I allocate half the funds as SIGHASH_ALL and half the funds as SIGHASH_SINGLE.

Do you see my problem?

For things like RBF where it has dominant precedence, the presence if it in any input makes the entire tx RBF enabled.

Similarily, if 1 of the N sigs is SIGHASH_xxx does SIGHASH_xxx dominate SIGHASH_yyy? And which is the xxx and yyy? Maybe its just a theoretical question and there arent any actual multisig tx with different SIGHASH types for the same vin, but unless the behavior is explicitly defined, would this create a split network unless all the bitcoin cores follow the same rules?

If the rules are so ambiguous and confusing (or missing), then it seems this could even be a current attack vector, unless all current nodes are following the identical rules. What are these rules?

James

amaclin

legendary

Activity: 1260

Merit: 1019

Quote from: jl777 on March 02, 2016, 10:25:15 AM

I can verify it is a valid signature, but what happens if there is SIGHASH_ALL for one sig, SIGHASH_SINGLE for another and SIGHASH_ANYONE_CAN_PAY for the third sig for the same input.

It is not a problem.
let me give you some pseudocode:

byte[] pubkey = getPubkey ( );
byte[] param = getSignaturePlusHashtype ( ); // signature concatenated with hash type
byte[] signature, int hashtype = param.split ( ); // get bare asn1 signature and 1-byte hashtype
byte[] digest;
switch ( hashtype )
{
case SIGHASH_ALL : digest = tx.createDigest ( all ); break;
case SIGHASH_NONE: digest = tx.createDigest ( none ); break;
}
verify ( signature, digest, pubkey )

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: jl777 on March 02, 2016, 10:25:15 AM

I can verify it is a valid signature, but what happens if there is SIGHASH_ALL for one sig, SIGHASH_SINGLE for another and SIGHASH_ANYONE_CAN_PAY for the third sig for the same input.

You compute the transaction for each signature separately. You can't just work out the hash once, you have to do it for each of the signers (if they use different sighashes)

jl777

legendary

Activity: 1176

Merit: 1134

Quote from: TierNolan on March 02, 2016, 09:54:57 AM

Quote from: jl777 on March 02, 2016, 09:25:49 AM

But for a multisig output that is being signed by multiple signers and where the signers are using different SIGHASH types, I think there needs to be a defined way of figuring out what SIGHASH mode is in effect.

From what I understand, the SIGHASH flag is used to determine what the signature actually signs.

transaction --- SIGHASH ---> signature-target --- ECDSA ---> Signature.

Since each signature has a different sighash byte, they can also use a different signature target.

There are only 2 steps. The bottom 5 bits select one of the output options and the 6th bit selects if you want to blank out the other inputs.

Unless the bottom 5 bits are 0x02 (SIGHASH_NONE) or 0x03 (SIGHASH_SINGLE), all the outputs are included. If the bit for 0x20 is set, then all inputs are blanked except the current input (SIGHASH_ANYONE_CAN_PAY).

See here.

While it could potentially be expanded, that would be a hard fork to include it in the basic script. P2SH or SW could include new sighash operations in their script (and SW is expandable).

That is the part about how to make the modified tx to sign, but how do I treat a set of sigs for a tx where the different multisig signers use different SIGHASH modes?

I can verify it is a valid signature, but what happens if there is SIGHASH_ALL for one sig, SIGHASH_SINGLE for another and SIGHASH_ANYONE_CAN_PAY for the third sig for the same input. Things are complicated enough with the different vins for a tx, which might or might not be dependent on each other, but do I do an M of N and count any mismatched SIGHASH as invalid? and which ones are mismatched if there are three different ones? Maybe depending on other clues, it can be determined which SIGHASH mode is valid for a specific tx, but what if more than one could be valid? It seems there would need to be a precedence or at least much clearer explanation on what should happen in these mixed SIGHASH vins.

Then I can start to worry about what happens when we have a single tx that contains mixed SIGHASH vins. As it is, it is tempting to just require SIGHASH_ALL across the board.

James

TierNolan

legendary

Activity: 1232

Merit: 1094

Quote from: jl777 on March 02, 2016, 09:25:49 AM

But for a multisig output that is being signed by multiple signers and where the signers are using different SIGHASH types, I think there needs to be a defined way of figuring out what SIGHASH mode is in effect.

From what I understand, the SIGHASH flag is used to determine what the signature actually signs.

transaction --- SIGHASH ---> signature-target --- ECDSA ---> Signature.

Since each signature has a different sighash byte, they can also use a different signature target.

There are only 2 steps. The bottom 5 bits select one of the output options and the 6th bit selects if you want to blank out the other inputs.

Unless the bottom 5 bits are 0x02 (SIGHASH_NONE) or 0x03 (SIGHASH_SINGLE), all the outputs are included. If the bit for 0x20 is set, then all inputs are blanked except the current input (SIGHASH_ANYONE_CAN_PAY).

See here.

While it could potentially be expanded, that would be a hard fork to include it in the basic script. P2SH or SW could include new sighash operations in their script (and SW is expandable).

jl777

legendary

Activity: 1176

Merit: 1134

As you know there are several SIGHASH types, each signature has a byte at the end to indicate how it was signed.

I searched, but could not find any definitive explanation of the precedence and how all the various SIGHASH types affect each other.

For most inputs with a single signer, this is a moot issue, though even that doesnt seem to be true as some parts of an input appear to propagate to the entire tx, or its outputs or at least something beyond the apparent scope of the vin that is being signed.

But for a multisig output that is being signed by multiple signers and where the signers are using different SIGHASH types, I think there needs to be a defined way of figuring out what SIGHASH mode is in effect.

A few lines in the official docs leaves a lot to the imagination. Is it even valid for there to be different SIGHASH types in the same vin? Maybe it is just rejected if they dont all match? Or maybe there is an implicit precedence that applies?

James

Topic: SIGHASH precedence for multisig? - page 2. (Read 1533 times)