Difference between revisions of "SIGHASH flags"

Line 1: Line 1:
 +
A SIGHASH flag is used to indicate which part of the transaction is signed by the [[Digital Signatures (ECDSA) | ECDSA signature]]. The mechanism provides a flexibility in constructing transactions. There are in total 6 different flags that can be added to a digital signature. 
 +
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
 
! Flag
 
! Flag
 +
! Value
 
! Functional Meaning
 
! Functional Meaning
 
|-
 
|-
 
| SIGHASH_ALL
 
| SIGHASH_ALL
 +
| 0x00000001
 
| Sign all inputs and outputs
 
| Sign all inputs and outputs
 +
|-
 +
| SIGHASH_NONE
 +
| 0x00000002
 +
| Sign all inputs and no output
 
|-
 
|-
 
| SIGHASH_SINGLE
 
| SIGHASH_SINGLE
 +
| 0x00000003
 
| Sign all inputs and the output with the same index
 
| Sign all inputs and the output with the same index
 
|-
 
|-
| SIGHASH_NONE
+
| SIGHASH_ALL <nowiki>|</nowiki> ANYONECANPAY
| Sign all inputs and no ouput
+
| 0x00000081
 +
| Sign its own input and all outputs
 
|-
 
|-
| SIGHASH_ALL | ANYONECANPAY
+
| SIGHASH_NONE <nowiki>|</nowiki> ANYONECANPAY
| Sign its own input and all outputs
+
| 0x00000082
 +
| Sign its own input and no output
 
|-
 
|-
| SIGHASH_SINGLE | ANYONECANPAY
+
| SIGHASH_SINGLE <nowiki>|</nowiki> ANYONECANPAY
 +
| 0x00000083
 
| Sign its own input and the output with the same index
 
| Sign its own input and the output with the same index
|-
 
| SIGHASH_NONE | ANYONECANPAY
 
| Sign its own input and no output
 
 
|}
 
|}
  
  
  
{| class="color" |}Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:
+
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:
  
 
SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, are signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".
 
SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, are signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".

Revision as of 16:36, 15 November 2019

A SIGHASH flag is used to indicate which part of the transaction is signed by the ECDSA signature. The mechanism provides a flexibility in constructing transactions. There are in total 6 different flags that can be added to a digital signature.

Flag Value Functional Meaning
SIGHASH_ALL 0x00000001 Sign all inputs and outputs
SIGHASH_NONE 0x00000002 Sign all inputs and no output
SIGHASH_SINGLE 0x00000003 Sign all inputs and the output with the same index
SIGHASH_ALL | ANYONECANPAY 0x00000081 Sign its own input and all outputs
SIGHASH_NONE | ANYONECANPAY 0x00000082 Sign its own input and no output
SIGHASH_SINGLE | ANYONECANPAY 0x00000083 Sign its own input and the output with the same index


Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:

SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, are signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this". 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. SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others". The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.

Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:

2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY There are two general patterns for safely creating contracts:

Transactions are passed around outside of the P2P network, in partially-complete or invalid forms. Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast. This is to ensure that people always know what they are agreeing to.

Together, these features let us build interesting new financial tools on top of the block chain.