Topic: SIGHASH precedence for multisig? (Read 1533 times)

I think it would be inaccurate to call a node that cannot validate the complete original rules of the system a full node.

Also, Bitcoin Core plans to remove that mechanism entirely. It no longer provides a useful performance improvement on most systems; and right now is really only preserved because it prevents some corner case DOS attacks (ones unrelated to signatures).

You don't have to do anything. But a complete and correct implementation of Bitcoin's rules will handle this. Bitcoin core can reorganize back to block 1 just fine (though will refuse to do so while checkpoints are enabled).

I am assuming I dont have to worry about bitcoin reorganizing 100,000+ blocks. Do I?

What is a strong definition of "fully validating node"? (without referring to Satoshi client)
What would you do in case of reorganizing the mainchain from the block #289999? from the block #200000? from the block #1?

If I use the block 290000 checkpoint to skip verifying sigs prior to that, could I still claim to be a fully validating node? (without being inaccurate)

Up to you. Bitcoin is voluntary system.
You have a right not to check signatures at all.

For a while I was definitely profoundly confused, but debugging the code has a way of clarifying things.

And the whole sequenceid not really doing much, but the docs do say it doesnt really do anything.

Anyway, onward and upward, I am glad the pace of bitcoin improvements is much faster now.

I plan to implement parallel sync support to other iguana nodes based on each bundle (2000 blocks), would need to include the sigs so it can be verified, but after that each non-relaying node can just purge it and save half the space. I am assuming only sigs after block 290000 need to be verified as long as the checkpoints match, or should all sigs be verfied?

James

Generally the "says" is that you can signal it. Not that the bitcoin protocol is always a paragon of perfect design, but it should generally not be possible to signal something that shouldn't work-- when thats possible it reliably leads to bugs. so it shouldn't be done without good reason. Being able to control sighash per signature is pretty useful.

But fair enough; I just wanted to make sure you weren't confused in more profound ways, but I follow your thinking now.

There isn't-- though Bitcoin Core can already do this. It can run a full node, with transaction and block relaying (but not serving historical blocks) with less than 2GB of space; this isn't a default behavior yet because we have not yet implemented mechanisms for nodes to retain and locate random chunks of the history so that nodes can collectively support other nodes bootstrapping.

You can sign a vin properly by multiple signers and get multiple signatures, each with a different sighash. What I assumed incorrectly was that all signers of a specific vin have to use the same sighash. Can you show me where it says that the same vin can be signed by different signers using different sighashes?

I always used bitcoind for tx signing before, but now doing it all from scratch. The context is that I was preparing the data for doing the signing and noticed I had made a wrong assumption that all sighashes would be the same, this is true in 99%+ of cases.

Anyway, please dont be alarmed, it was just an informational field that was to show what sighash mode a vin used, but it wasnt being used by anything else and it appears to need to be a vector, which is probably not worth doing as I can just iterate through all the sigs and grab the last byte.

I am making the iguana be able to be a lossless codec that uses half the space with the sigs and able to purge the sigs to get a 75% reduction in size, I estimate about 15GB size for the dataset without sigs. Do you see any reason for a non-relaying node to keep around sigs that have already been verified?

James

That is a concerning misunderstanding. I'm not sure how you'd think that-- the sighash in use is part of the ecdsa signature (input to checksig).

Not sure if you are still wondering this, but simply put, the transaction is atomic. All the vins get transferred to the vouts if and only if every vin script pass regardless of its content. So yeah, you can create interesting combinations if you some of the scripts have different SIGHASH values.

certainly when I am on the side of generating the scripts, but I am working on the core side now, so have to understand the proper handling of arbitrary vins/vouts

If you are doing it as part of a protocol, you would insist that the output scripts all match the expected template.

Either use CHECKSIGVERIFY or make sure CHECKSIG is the last operation to execute.

I cant see a way that sighash isnt on a per sig basis as it is intimate part of the signing.

I think I was thinking about it a bit backwards, as the sigs are the endpoint of the process and not an intermediate that affects anything, other than if the vin is valid or not.

But actually, the sig not validating still doesnt mean the vin is always invalid, right? The vout script could just pop all data off and push a true. So a vin without a valid sig could still be spent...

Just the murkiness about crossing all possible vout spend scripts with all possible vins gave me pause.

James

Well, I would be 90% sure that the sighash applies on a per signature basis, but when in doubt, it is worth testing.

OK, so I am not crazy thinking this is a possible case of undefined behavior

I noticed it as I found my code was assuming only a single SIGHASH type per vin, but clearly there can be multiple signers.

I think so, but it is probably worth checking a few transactions with mixes of signatures on testnet.

So unlike RBF enabled in one vin propagates to the entire tx, the signatures are always self contained regardless of how they are mixed. In a MofN multisig it is possible changing the tx will change the validity of some sigs, but as long as there are still M or more valid sigs, it is valid.

As long as there is no propagation beyond the current vin, I think it is ok. The RBF in any vin affecting all vins, just spooked me a bit and I wasnt sure about the local scope of SIGHASH. I guess I overcomplicated things.

Thanks

James

Signatures are pass/fail, they don't have meaning other than that.  SIGHASH_SINGLE means that you just sign the output that you are interested in.  You are saying "This signature is valid for any transaction which pays to this output".

Assume you had 2 inputs and 2 outputs and you are checking input zero.

The first signature is sighash_single & anyone_can_pay.  That means that you only include output zero.  The anyone can pay means that you also delete all the inputs, except the one you are signing (input zero).  Those inputs and outputs are the only ones that are involved in the signature.

The person who signed that signature signed any transaction with that input and that output.

That means you can add inputs and outputs and the transaction will remain valid (as long as that input and that output are in the same position).

The second signature is sighash_all.  That person signed the entire transaction.  If you change anything about the transaction, then it becomes invalid.

In theory, the first person could create a one input and one output transaction and sign it with (sighash_single | anyone_can_pay) and then sign it.  The second person can then take the transaction and modify it (adding the 2nd input and 2nd output) and then sign with sighash_all.  That 2nd signature is also valid, but only if there are no more changes.

And how to treat the x if the M sigs all use different sighash types?

My confusion is not about the actual signing or verifying step (of course I was quite confused about that till I got it working), but rather how to interpret the resulting signed tx.

A tx has multiple inputs and multiple outputs. But the inputs and outputs range from being totally indpendent to totally dependent and multiple sighash types within a single input seems to create a large number of implementations possible that all follow the rules and all end up with a different result.

It is the semantics of the different SIGHASH types that still confuse me. SIGHASH_ALL is thankfully used for majority and that is simple. The signature assumes everything is the same, no changes allowed. But the others do allow the tx to be changed. So what happens when we have M of N sigs, some that allow the tx to change and others that dont?

Maybe there is some actual documentation that describes things clearly?

Is the rule simply that if all the sigs verify for an input, we treat that input as verified fully? There is no possibility that a SIGHASH type that is different can invalidate the validity when it interacts with other SIGHASH types?

Like the SIGHASH_SINGLE, it appears to require a 1:1 correspondence of vins/vouts, but the different vins are independent. So if one msig signer uses SIGHASH_SINGLE and another uses SIGHASH_ALL, then the SIGHASH_SINGLE would be valid for more tx than the SIGHASH_ALL, so it makes sense that if the tx changes to invalidate the SIGHASH_ALL then the M of N is now M-1

I think that makes sense, but all combinations of SIGHASH modes needs to be well defined. I havent done the full matrix of possibilities yet, that is why I posted. I was hoping that such a thing was already thought through and documented

James

Ok, verify ( signature, digest, pubkey ) method returns either 1 or 0
Note, that this method doesn't depend on any other variables. it does not know anything about satoshi sighash types.
The msig script m-of-n is valid if there are at least m hits of positive verifies