14

If I understand correctly, SIGHASH_NONE in the output input signature means that spender of this output doesn't sign his outputs. But doesn't that mean that the spending transaction is by design insecure? E.g. a malicious miner could switch the outputs to his addresses and put a modified version in the block.

Am I missing something? What is SIGHASH_NONE intended for?

Edit: Now I understand why I was confused! The SIGHASH_NONE is in the input signature, not in the output. Somehow I thought it's an attribute of the output, and it didn't make sense to me why the previous spender would be able to decide how the next transaction should be signed.

| improve this question | |
  • note that the sighash byte appended to the signature cannot be modified by the miner. eg the miner cannot change a sighash_anyonecanpay into a sighash_none. this is because even though the signature itself does not form part of the message (txhash) to be verified, the sighash byte actually does form part of the message and so it is verified in the signature. more detail here – mulllhausen May 27 '15 at 0:58
16

The bitcoin wiki OP_CHECKSIG page describes the behaviour of SIGHASH_NONE like this:

The output of txCopy is set to a vector of zero size.

All other inputs aside from the current input in txCopy have their nSequence index set to zero

Think of this as "sign none of the outputs-- I don't care where the bitcoins go."

The contracts page also talks about SIGHASH_NONE:

SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.

If I sign a transaction where all the inputs are SIGHASH_NONE then a miner can change the outputs to whatever he likes. If any of the inputs are SIGHASH_ALL then the miner can't change the outputs. So a group of people can each sign their own SIGHASH_NONE input to a transaction, send them privately to the coordinator who signs his own SIGHASH_ALL input before publishing the transaction. That way the individual contributors don't need to know the destination address so long as they trust the coordinator.

| improve this answer | |
  • 3
    One should note that the ability to add additional inputs depends on the SIGHASH_ANYONECANPAY bit being set as well. – runeks Apr 27 '16 at 14:05
0

This is discussed here.

i.e., that would require AnyoneCanPay to be vulnerable as you describe it.

| improve this answer | |
  • 3
    So... as long as the spending transaction has other inputs, it's safe. But a spending transaction with only one input would be vulnerable, even without AnyoneCanPay, right? – hmp Jul 19 '12 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.