SIGHASH flags

Flag	Functional Meaning
SIGHASH_ALL	Sign all inputs and outputs
SIGHASH_SINGLE	Sign all inputs and the output with the same index
SIGHASH_NONE	Sign all inputs and no ouput
ANYONECANPAY	Sign its own input and all outputs
ANYONECANPAY	Sign its own input and the output with the same index
ANYONECANPAY	Sign its own input and no output

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.