Bitcoin Wiki - User contributions [en]

Metanet Protocol

2020-07-10T17:49:18Z

Wei:

[[File:Metanet_graph.png|thumb|A typical Metanet graph.]]

The '''Metanet Protocol''' is a layer-2 overlay protocol that defines a method for creating data structure over Bitcoin SV. The protocol utilises [[Metanet_Protocol#Node and Edge Structure|nodes and edges]] to specify directed acyclic graph (DAG) data structures on the Bitcoin SV ledger. The Metanet protocol can be used to construct diverse systems such as file systems, internet domains, ownership structures and code repositories.

There are tools available to [[Metanet_Protocol#Writing Metanet Graphs|write]] and [[Metanet_Protocol#Reading Metanet Graphs|read]] Metanet graphs, and a growing a range of [[Metanet_Protocol#Usage|projects]] that use the Metanet protocol to structure their application data.

==Node and Edge Structure==

The Metanet Protocol is a protocol for creating graph structures comprising nodes and edges on the ledger. In the Metanet protocol the following definitions of node and edge are used:

* '''Metanet Node''' - A transaction using the Metanet protocol format.
* '''Metanet Edge''' - An input signature linking two Metanet nodes.

A Metanet node is a transaction that conforms to the Metanet transaction format specified in [https://nchain.com/app/uploads/2019/06/The-Metanet-Technical-Summary-v1.0.pdf Metanet technical summary] document produced by nChain. The basic components of a Metanet transaction include a protocol flag, Metanet-specific data attributes, and any content data that is to be stored by a Metanet node transaction.

The protocol flag is a 4-byte hexadecimal prefix that signifies that a transaction is using the format of the Metanet protocol. The hexadecimal value of the prefix was chosen to be the hexademical encoding 0x4d455441 of the string 'meta' by [https://twitter.com/BitcoinAssn/status/1136232235798016001?s=20 public poll] on June 5th 2019.

The Metanet-specific data attributes of a Metanet node transaction include the following:

* '''<math>P_{node}</math>''' - the public key defining the node.
* '''<math>TxID_{node}</math>''' - the unique transaction ID of the node.
* '''<math>P_{parent}</math>''' - the public key defining a parent of the node.
* '''<math>SigP_{parent}</math>''' - a signature created using the private key associated with the public key defining a parent of the node.
* '''<math>TxID_{parent}</math>''' - the unique transaction ID of the a parent of the node.

The Metanet-specific data attributes listed above are used collectively to define a Metanet node and its position within a larger graph structure of multiple Metanet nodes, known as a ''Metanet graph''.

It is possible that a node does not have any parents and such a node is termed a ''root node''. A root node will have null values for any <math>P_{parent}</math>, <math>SigP_{parent}</math>, and <math>TxID_{parent}</math> attributes, and can therefore use a valid signature from any public key in its input(s).

A Metanet transaction is defined as a transaction that contains an OP_FALSE OP_RETURN payload containing:

* The Metanet flag
[[File:Metanet_node.png|thumb|A Metanet node transaction.]]
* A node public key '''<math>P_{node}</math>'''
* A parent transaction ID '''<math>TxID_{parent}</math>''' (null if a root node).

In order to qualify as a Metanet-valid node, the transaction must also be signed by the public key corresponding to its parent '''<math>P_{parent}</math>'''.

Any content data and its encoding can be included following these core Metanet attributes in the OP_FALSE OP_RETURN payload. The Metanet protocol does not specify the use of any one scheme for content data and additional attributes, and any valued usage of the Metanet protocol attributes above constitute a Metanet node transaction.

A basic example of a Metanet node transaction that conforms to this format is shown in the diagram on the right.

The Metanet graph is formed by creating edges between parent Metanet nodes and child Metanet nodes. An edge is created between a parent and child by the creation and insertion of the signature '''<math>SigP_{parent}</math>''' in the child node, using the parent public key. [[File:Metanet_edge.png|thumb|The creation of a Metanet edge.]]

The fact that this signature is in a transaction input means that the signature itself may be validated by miners. This means that attempts to spoof a Metanet node can be mitigated either by validating the signature explicitly or by confirming that is the node is spending an appropriate previous output.

== Rules of the Metanet Protocol==

The Metanet protocol specifies a simple and extensible rule set for creating Metanet graphs and data structures. The base rule set is the following:

* Nodes are transactions.
* Edges are created by signatures.
* Each node is uniquely identified by the pair of attributes: '''<math>P_{node}</math>''', '''<math>TxID_{node}</math>'''.
* Each node must specify the node ID of itself and its parent: '''<math>ID_{node}</math>''', '''<math>ID_{parent}</math>'''.

The unique node identifier for a node is defined mathematically as '''<math>H(P_{node}||TxID_{node})</math>''', where '''<math>H()</math>''' is a cryptographic hash function.

Metanet graph structures may be created using this base rule set alone. It is also possible to impose additional rules to Metanet graph structures in order to achieve different properties for data structures.

A simple extension of the rule set is to impose the following constraints:
[[File:Metanet_rules.png|thumb|A simple Metanet rule set.]]

* The in-degree of a node should be 0 (no parent) or 1 (one parent).
* The out-degree of a node should be a free parameter.

These additional rules allow domain-like structures to emerge as Metanet DAGs, which can be used to structure websites and file systems which inherit the permissioning structure of a Metanet graph.

R-Puzzles

2020-03-05T10:49:25Z

Wei:

An R-Puzzle is a new type of script that allows for the spending party to sign the input UTXO using any valid Bitcoin keypair. This can be used to sign Metanet node addresses or addresses that hold tokens, or be randomly generated.

==k==
In an R-puzzle, a knowledge proof of a value called 'k' is used to allow coins to be spent. 'k' is from the same mathematical set as Bitcoin [[Private Keys]] and must be known to the spender and used to generate 'r', which is the x-coordinate of k multiplied by the [[G|Generator point]]. 'r' is extracted from the signature used in the transaction and tested against a hash stored in the ScriptPubKey. k-chains can be managed using the same deterministic techniques as Bitcoin keychains.

Generating an [[Elliptic Curve Digital Signature Algorithm|ECDSA]] signature involves a few steps.

Inputs to the signature:
#k value 'k'
#keypair 'P1' = 'S1' · [[G]]
#Message 'm'

Method:
#Calculate R = k · G
#Define r = x-coordinate of R
#Calculate s = k-1(H(m) + S1 * r)mod n
Signature is (r, s) plus 5 bytes of formatting and a [[SIGHASH flags|SIGHASH]] type

==Signature Structure==

{| class="wikitable"
|-
! Data Structure
! Length
! Data (hex)
|-
| Sequence Identifier
| 1
| 30
|-
| Length of Sequence
| 1
| 46
|-
| Integer Identifier
| 1
| 02
|-
| Byte-length of r
| 1
| 21
|-
| Needed when left(r, 1) > 7f
| 1
| 00 NOTE: This byte is not always needed
|-
| r
| 32
| e9d34347e597e8b335745c6f8353580f4cbdb4bcde2794ef7aab915d996642
|-
| Integer identifier
| 1
| 02
|-
| Byte-length of s
| 1
| 21
|-
| Needed when left(s, 1) > 7f
| 1
| 00
|-
| s
| 32|
| df2ccb52c7243c55bde34934bd55efbdac21c74a20bb7b438d1b6de3311f
|-
| Sighash type
| 1
| 01
|}

When serialised the signature looks like this:

''3046022100e9d34347e597e8b335745c6f8353580f4cbdb4bcde2794ef7aab915d996642022100df2ccb52c7243c55bde34934bd55efbdac21c74a20bb7b438d1b6de3311f01''

==Extracting r==

The following piece of script pulls r out of the signature string by extracting first the length of R which is the 4th byte of the packet, and then using it to split r from the signature.

'''OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP'''

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
| <sig>
| OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP
| scriptSig is loaded, signature on the stack
|-
| <3 bytes> <sig'>
| OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP
| First 3 bytes of signature are split
|-
| <sig'>
| OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP
| 3 byte data item is removed
|-
| <r Length> <sig">
| OP_SWAP OP_SPLIT OP_DROP
| 1 byte containing r length is split from sig'
|-
| <sig"> <r Length>
| OP_SPLIT OP_DROP
| r Length parameter is moved to top of stack
|-
| <r> <sig'">
| OP_DROP
| r is split from sig"
|-
| <r>
|
| sig'"== is dropped from stack, leaving r
|}

==P2RPH==
Packaging this subscript into the following gives a Pay to R-Puzzle Hash script:
'''OP_OVER''' OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP '''OP_HASH160 <Hash(r)> OP_EQUALVERIFY OP_CHECKSIG'''

==Security Considerations==

===Protecting Private Keys===
If two signatures are published using the same ''k'' then anyone who knows the value of ''k'' can derive the secret key used to create the signatures.

To mitigate this issue, ensure that the same ''k'' value and private key are never used to create more than one signature.

===Signature Forgeability===
Given an R-puzzle signature <r,s>, a public key P, and a message m, a forger can create a different message m', and calculate a new public key P' such that
P' = P + [r^-1 [H(m)-H(m')] ].G. Then signature <r,s> is a valid signature on message m' with respect to the public key P'. Note that, the forger does not know and does not need to know the private key corresponding to P' in this forgery.

When implementing R-puzzle, it is important to take this into account.

One way to mitigate this is to require another signature to prove that the signer knows the private key corresponding to the public key used in the R puzzle. That is, two signatures in the unlocking script, <r,s> and <r',s'>, and one public key P. It is important to have r not equal r' for the first security consideration. Both signatures should be valid subject to the same public key P.

This solution would propose the following input solution:

'''<sig'> <pubkey> <sigr>

which spends outputs with the following script:

'''OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rhash> OP_EQUALVERIFY OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG'''

=R-Puzzle Use Cases=
*Delegation of authority
*Tokens
*Multi-signature schemes (with advanced scripting)

R-Puzzles

2020-03-05T10:48:44Z

Wei:

An R-Puzzle is a new type of script that allows for the spending party to sign the input UTXO using any valid Bitcoin keypair. This can be used to sign Metanet node addresses or addresses that hold tokens, or be randomly generated.

==k==
In an R-puzzle, a knowledge proof of a value called 'k' is used to allow coins to be spent. 'k' is from the same mathematical set as Bitcoin [[Private Keys]] and must be known to the spender and used to generate 'r', which is the x-coordinate of k multiplied by the [[G|Generator point]]. 'r' is extracted from the signature used in the transaction and tested against a hash stored in the ScriptPubKey. k-chains can be managed using the same deterministic techniques as Bitcoin keychains.

Generating an [[Elliptic Curve Digital Signature Algorithm|ECDSA]] signature involves a few steps.

Inputs to the signature:
#k value 'k'
#keypair 'P1' = 'S1' · [[G]]
#Message 'm'

Method:
#Calculate R = k · G
#Define r = x-coordinate of R
#Calculate s = k-1(H(m) + S1 * r)mod n
Signature is (r, s) plus 5 bytes of formatting and a [[SIGHASH flags|SIGHASH]] type

==Signature Structure==

{| class="wikitable"
|-
! Data Structure
! Length
! Data (hex)
|-
| Sequence Identifier
| 1
| 30
|-
| Length of Sequence
| 1
| 46
|-
| Integer Identifier
| 1
| 02
|-
| Byte-length of r
| 1
| 21
|-
| Needed when left(r, 1) > 7f
| 1
| 00 NOTE: This byte is not always needed
|-
| r
| 32
| e9d34347e597e8b335745c6f8353580f4cbdb4bcde2794ef7aab915d996642
|-
| Integer identifier
| 1
| 02
|-
| Byte-length of s
| 1
| 21
|-
| Needed when left(s, 1) > 7f
| 1
| 00
|-
| s
| 32|
| df2ccb52c7243c55bde34934bd55efbdac21c74a20bb7b438d1b6de3311f
|-
| Sighash type
| 1
| 01
|}

When serialised the signature looks like this:

''3046022100e9d34347e597e8b335745c6f8353580f4cbdb4bcde2794ef7aab915d996642022100df2ccb52c7243c55bde34934bd55efbdac21c74a20bb7b438d1b6de3311f01''

==Extracting r==

The following piece of script pulls r out of the signature string by extracting first the length of R which is the 4th byte of the packet, and then using it to split r from the signature.

'''OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP'''

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
| <sig>
| OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP
| scriptSig is loaded, signature on the stack
|-
| <3 bytes> <sig'>
| OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP
| First 3 bytes of signature are split
|-
| <sig'>
| OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP
| 3 byte data item is removed
|-
| <r Length> <sig">
| OP_SWAP OP_SPLIT OP_DROP
| 1 byte containing r length is split from sig'
|-
| <sig"> <r Length>
| OP_SPLIT OP_DROP
| r Length parameter is moved to top of stack
|-
| <r> <sig'">
| OP_DROP
| r is split from sig"
|-
| <r>
|
| sig'"== is dropped from stack, leaving r
|}

==P2RPH==
Packaging this subscript into the following gives a Pay to R-Puzzle Hash script:
'''OP_OVER''' OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP '''OP_HASH160 <Hash(r)> OP_EQUALVERIFY OP_CHECKSIG'''

==Security Considerations==

===Protecting Private Keys===
If two signatures are published using the same ''k'' then anyone who knows the value of ''k'' can derive the secret key used to create the signatures.

To mitigate this issue, ensure that the same ''k'' value and private key are never used to create more than one signature.

===Signature Forgeability===
Given an R-puzzle signature <r,s>, a public key P, and a message m, a forger can create a different message m', and calculate a new public key P' such that
P' = P + [r^-1 [H(m)-H(m')] ].G. Then signature <r,s> is a valid signature on message m' with respect to the public key P'. Note that, the forger does not know and does not need to know the private key corresponding to P' in this forgery.

When implementing R-puzzle, it is important to take this into account.

One way to mitigate this is to require another signature to prove that the signer knows the private key corresponding to the public key used in the R puzzle. That is, two signatures in the unlocking script, <r,s> and <r',s'>, and one public key P. It is important to have r not equal r' for the first security consideration. Both signatures should be valid subject to the same public key P.

'''Solution'''
A possible solution is to include another signature <sig'> in the unlocking script and apply it to a different message using modified sighash flags.
<sig'> must also use a different value of r so as not to leak the private key.

This solution would propose the following input solution:

'''<sig'> <pubkey> <sigr>

which spends outputs with the following script:

'''OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rhash> OP_EQUALVERIFY OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG'''

=R-Puzzle Use Cases=
*Delegation of authority
*Tokens
*Multi-signature schemes (with advanced scripting)

R-Puzzles

2020-03-05T10:01:19Z

Wei:

An R-Puzzle is a new type of script that allows for the spending party to sign the input UTXO using any valid Bitcoin keypair. This can be used to sign Metanet node addresses or addresses that hold tokens, or be randomly generated.

==k==
In an R-puzzle, a knowledge proof of a value called 'k' is used to allow coins to be spent. 'k' is from the same mathematical set as Bitcoin [[Private Keys]] and must be known to the spender and used to generate 'r', which is the x-coordinate of k multiplied by the [[G|Generator point]]. 'r' is extracted from the signature used in the transaction and tested against a hash stored in the ScriptPubKey. k-chains can be managed using the same deterministic techniques as Bitcoin keychains.

Generating an [[Elliptic Curve Digital Signature Algorithm|ECDSA]] signature involves a few steps.

Inputs to the signature:
#k value 'k'
#keypair 'P1' = 'S1' · [[G]]
#Message 'm'

Method:
#Calculate R = k · G
#Define r = x-coordinate of R
#Calculate s = k-1(H(m) + S1 * r)mod n
Signature is (r, s) plus 5 bytes of formatting and a [[SIGHASH flags|SIGHASH]] type

==Signature Structure==

{| class="wikitable"
|-
! Data Structure
! Length
! Data (hex)
|-
| Sequence Identifier
| 1
| 30
|-
| Length of Sequence
| 1
| 46
|-
| Integer Identifier
| 1
| 02
|-
| Byte-length of r
| 1
| 21
|-
| Needed when left(r, 1) > 7f
| 1
| 00 NOTE: This byte is not always needed
|-
| r
| 32
| e9d34347e597e8b335745c6f8353580f4cbdb4bcde2794ef7aab915d996642
|-
| Integer identifier
| 1
| 02
|-
| Byte-length of s
| 1
| 21
|-
| Needed when left(s, 1) > 7f
| 1
| 00
|-
| s
| 32|
| df2ccb52c7243c55bde34934bd55efbdac21c74a20bb7b438d1b6de3311f
|-
| Sighash type
| 1
| 01
|}

When serialised the signature looks like this:

''3046022100e9d34347e597e8b335745c6f8353580f4cbdb4bcde2794ef7aab915d996642022100df2ccb52c7243c55bde34934bd55efbdac21c74a20bb7b438d1b6de3311f01''

==Extracting r==

The following piece of script pulls r out of the signature string by extracting first the length of R which is the 4th byte of the packet, and then using it to split r from the signature.

'''OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP'''

{| class="wikitable"
|-
! Stack
! Script
! Description
|-
| <sig>
| OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP
| scriptSig is loaded, signature on the stack
|-
| <3 bytes> <sig'>
| OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP
| First 3 bytes of signature are split
|-
| <sig'>
| OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP
| 3 byte data item is removed
|-
| <r Length> <sig">
| OP_SWAP OP_SPLIT OP_DROP
| 1 byte containing r length is split from sig'
|-
| <sig"> <r Length>
| OP_SPLIT OP_DROP
| r Length parameter is moved to top of stack
|-
| <r> <sig'">
| OP_DROP
| r is split from sig"
|-
| <r>
|
| sig'"== is dropped from stack, leaving r
|}

==P2RPH==
Packaging this subscript into the following gives a Pay to R-Puzzle Hash script:
'''OP_OVER''' OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP '''OP_HASH160 <Hash(r)> OP_EQUALVERIFY OP_CHECKSIG'''

==Security Considerations==

===Protecting Private Keys===
If two signatures are published using the same ''k'' then anyone who knows the value of ''k'' can derive the secret key used to create the signatures.

To mitigate this issue, ensure that the same ''k'' value and private key are never used to create more than one signature.

===Signature Forgeability===
Given an R-puzzle signature <r,s>, a public key P, and a message m, a forger can create a different message m', and calculate a new public key P' such that
P' = P + [r^-1 [H(m)-H(m')] ].G. Then signature <r,s> is a valid signature on message m' with respect to the public key P'. Note that, the forger does not know and does not need to know the private key corresponding to P' in this forgery.

When implementing R-puzzle, it is important to take this into account.

One way to mitigate this is to require another signature to prove that the signer knows the private key corresponding to the public key used in the R puzzle. That is, two signatures in the unlocking script, <r,s> and <r',s'>, and one public key P. It is important to have r not equal r' for the consideration above.

'''Solution'''
A possible solution is to include another signature <sig'> in the unlocking script and apply it to a different message using modified sighash flags.
<sig'> must also use a different value of r so as not to leak the private key.

This solution would propose the following input solution:

'''<sig'> <pubkey> <sigr>

which spends outputs with the following script:

'''OP_DUP OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rhash> OP_EQUALVERIFY OP_OVER OP_CHECKSIGVERIFY OP_CHECKSIG'''

=R-Puzzle Use Cases=
*Delegation of authority
*Tokens
*Multi-signature schemes (with advanced scripting)

Legacy Sighash Algorithm

2020-02-19T16:50:52Z

Wei:

The legacy sighash algorithm was used to generate a hash value that is signed by an ECDSA signature. The input to the algorithm consists of a transaction and sighash flags.

Within the algorithm, it calls an serialisation algorithm that is used to serialise transaction, "CTransactionSignatureSerializer". Depending on the sighash flags, different parts of the transaction will be modified before the transaction is fed to the serialisation algorithm. Contrary to the use of hashes in the new sighash algorithm, the modification is simply to remove strings or to replace strings with zeros or one in the transaction. Once serialised, the transaction is then fed to double SHA256 to produce a hash value for either ECDSA signature creation or verification.

The detail can be found at https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/interpreter.cpp
by searching "CTransactionSignatureSerializer".

Legacy Sighash Algorithm

2020-02-19T16:46:14Z

Wei:

The legacy sighash algorithm was used to generate a hash value that is signed by an ECDSA signature. The input to the algorithm consists of a transaction and sighash flags.

Within the algorithm, it calls an serialisation algorithm that is used to serialise transaction, "CTransactionSignatureSerializer". Depending on the sighash flags, different parts of the transaction will be modified before the transaction is fed to the serialisation algorithm. Once serialised, the transaction is then fed to double SHA256 to produce a hash value for either ECDSA signature creation or verification.

The detail can be found at https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/interpreter.cpp
by searching "CTransactionSignatureSerializer".

Legacy Sighash Algorithm

2020-02-19T16:45:59Z

Wei:

The legacy sighash algorithm was used to generate a hash value that is signed by an ECDSA signature. The input to the algorithm consists of a transaction and sighash flags.

Within the algorithm, it calls an serialisation algorithm that is used to serialise transaction, "CTransactionSignatureSerializer". Depending on the sighash flags, different parts of the transaction will be modified before the transaction is fed to the serialisation algorithm. Once serialised, the transaction is then fed to double SHA256 to produce a hash value for either ECDSA signature creation or verification.

The detail can be found athttps://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/interpreter.cpp
by searching "CTransactionSignatureSerializer".

Legacy Sighash Algorithm

2020-02-19T16:45:20Z

Wei: Created page with "The legacy sighash algorithm was used to generate a hash value that is signed by an ECDSA signature. The input to the algorithm consists of a transaction and sighash flags. W..."

The legacy sighash algorithm was used to generate a hash value that is signed by an ECDSA signature. The input to the algorithm consists of a transaction and sighash flags.

Within the algorithm, it calls an serialisation algorithm that is used to serialise transaction, "CTransactionSignatureSerializer". Depending on the sighash flags, different parts of the transaction will be modified before the transaction is fed to the serialisation algorithm. Once serialised, the transaction is then fed to double SHA256 to produce a hash value for either ECDSA signature creation or verification.

The detail can be found at https://github.com/bitcoin-sv/bitcoin-sv/blob/88ee5b7012e03eb99ccaf695eab0b2f0fff7cb5c/src/script/interpreter.cpp
by searching "CTransactionSignatureSerializer".

OP CHECKSIG

2020-02-19T15:43:30Z

Wei:

'''OP_CHECKSIG''' is an opcode that verifies an [[Elliptic Curve Digital Signature Algorithm| ECDSA signature]]. It takes two inputs from the stack, a public key (on top of the stack) and an ECDSA signature in its DER_CANONISED format concatenated with sighash flags. It outputs true or false on the stack based on whether the signature check passes or fails.

== Parameters ==

In addition to the stack parameters, OP_CHECKSIG needs to have
# the current transaction <math>TX_{current}</math>,
# the index of the transaction input in which the signature is checked <math>i</math>,
# the scriptPubKey in which this OP_CHECKSIG belongs <math>previousScriptPubKey</math>, and
# the value in satoshi that the outpoint represents <math>amount</math>.

Note that <math>previousScriptPubKey</math> is from previous transaction, in which the output is spent in current transaction.

== How it works ==
In short, OP_CHECKSIG calls a function called "sighash" which produces a hash value of the serialised transaction. (For legacy sighash algorithm, please click [[Legacy Sighash Algorithm | here]].) The hash value is the message on which the signature is verified. The signature and the public key involved in the verification are obtained from the stack.

In detail,

# Check the stack size is not less than 2.
# the public key and the signature are popped as the top 2 items of the stack.
# Check the signature encoding is of the correct format [<DER signature><hashtype>]. An example: 47304402205a2b556c71ee1c12d8e0b460c3446aeca0e3ee71b7bc11c6ddd3da8beeec99c60220783a1f0c0158674df8904022ec30fab5154c4fc4c7e8467086f0204cc8e16cbb01, where 47 indicates number of bytes in hex (71 in decimal) of the signature including 1 byte of sighash flag at the end, the next 46 bytes (70 in decimal) are the ECDSA signature (r,s), the last byte is the sighash flag "ALL".
# Check the public key encoding is of the correct format. Both compressed public key and uncompressed public key can be acceptable. An example: 210220798b9772a8ae06d13027e6f501d09ea07f6dfc4b7afc3db3a6d6c57bf24239, where 21 indicates the number of bytes in hex of the public key, 02 indicates this is a compressed public and the y-coordinate is an even number, the rest is the value of the x-coordinate of the public key. Note that if the second byte is 04, then it indicates that the public key is given in its uncompressed form.
# A new subScript is created from the <math>previousScriptPubKey</math>. The subScript starts from the most recent OP_CODESEPARATOR (the one just before the OP_CHECKSIG that is executed here) to the end of the <math>previousScriptPubKey</math>. If there is no OP_CODESEPARATOR, the entire <math>previousScriptPubKey</math> becomes the subScript.
# Any remaining OP_CODESEPARATORS are removed from the subScript.
# A serialisation algorithm (sighash) is called to produce an input to double SHA256 depending on sighash type:
## nVersion in <math>TX_{current}</math> (4-byte little endian)
## double SHA256 of the serialisation of all input outpoints (32-byte hash)
### if ANYONECANPAY flag is set, then this should be a 32-byte zero.
## double SHA256 of the serialisation of nSequence of all inputs (32-byte hash)
### if ANYONECANPAY flag is set, then this should be a 32-byte zero.
## the outpoint being spent (32-byte for transaction ID + 4-byte little endian for index)
## length in bytes of the subScript (big endian)
## the subScript
## <math>amount</math> (8-byte little endian)
## nSequence of this outpoint (4-byte little endian)
## double SHA256 of the serialization of all output amount (8-byte little endian) with scriptPubKey (These are the outputs in <math>TX_{current}</math>.)
### If SINGLE flag is set and the input index is smaller than the number of outputs, then this should be the double SHA256 of the output with scriptPubKey of the same index as the input
### If NONE flag is set, then this should be a 32-byte zero.
## nLocktime of the transaction <math>TX_{current}</math> (4-byte little endian)
## sighash type of the signature (4-byte little endian)
# The serialisation in bytes from the step above will be fed to double SHA256 to produce the 32-byte message. This message is used to check the ECDSA signature, together with the public key and the signature obtained from the stack. Note that the [[secp256k1]] elliptic curve is used for the verification with the given public key.

== Return values ==

OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
OP_CHECKSIGVERIFY leaves nothing on the stack but will cause the script validation to fail immediately if the check does not pass.

==References==
https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/interpreter.cpp

See [[SIGHASH flags]] for more detail on the effect of combinations of flags.

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/OP_CHECKSIG under [https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. Although it may have been extensively revised and updated we acknowledge the original authors.

Smart contracts

2020-02-19T11:44:30Z

Wei:

===Introduction===
A smart contract is a self executing contract where terms of the contract are implemented in code. A common misconception is that Bitcoin is incapable of executing smart contracts, paving the way for the creation of other blockchains like [https://ethereum.org/ Ethereum].

The bitcoin scripting language is designed to be as primitive as possible. Using a set of OP codes, the language achieves maximum security while minimizing attack surfaces through intentional limitations, which often leads to an underestimation of bitcoin’s true potential. In fact, by simply focusing on the bitcoin scripting language, there is a risk that many other interesting features of the protocol may be overlooked. To understand how bitcoin is smart-contract friendly, one needs to zoom in and out on the bitcoin transaction as well as the entire stage on which the bitcoin transaction plays its role.

By doing this, it becomes apparent that there are many ways to construct smart contracts on bitcoin. We can summarise them roughly as

* smart locking scripts,
* smart use of sighash flags,
* layered networks, and
* payment channels.

===Smart contract platforms===

[http://tokenized.com Tokenized] is a smart contract platform that uses on-chain commands to instruct an agent in the issuance and distribution of tokens based on a set of smart contract rules.

[http://scrypt.studio/ sCrypt] is a web-based integrated development environment (IDE) where developers can implement Bitcoin script in a higher level, more familiar programming language.

[https://github.com/gear-sv GearSV] is a means of writing and running smart contracts on the Bitcoin SV network. Leveraging other development tools, contracts can be deployed on-chain as data, then run and validated off-chain by oracles or software agents.

Contact the Bitcoin Association to have your smart contract platform added.

Payments in Bitcoin

2020-02-19T11:07:46Z

Wei:

Payments are an important aspect of Bitcoin. Every transaction is a payment of some sort. Transactions are the only means through which information can be written onto the ledger.

Block discovery events are agreed upon through the acceptance of a [[Coinbase]] transaction as a valid payment. A block is simply the process of having a collection of payments set down, collated and agreed upon as valid.

There are many methods of requesting and making payments.

==BIP-0270==
[https://github.com/moneybutton/bips/blob/master/bip-0270.mediawiki BIP270] is a simplified version of the [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70 Payment Protocol] introduced in 2013. It is a protocol for communication between a payment host (usually either a merchant, a payment processor, or simply the recipient's wallet) and their customer (the sender of the funds). It enables:
* Better experience
* Simpler wallet infrastructure
* Multiple outputs
* Better security against man-in-the-middle attacks

BIP-270 is designed for wallets that use [[Simplified Payment Verification]] to achieve huge improvements at scale. Transactions can be exchanged partially or in iterations. This is far faster when done peer to peer between the payer and the payee, writing to the ledger only at the end to settle the transaction(s).

This BIP is an optimisation of BIP-0070. Changes include:
* Moves all signature exchange and validation to the communication later (usually HTTPS)
* Add multiple outputs
* A library optimised for peer to peer transaction management

==BSVAlias==
[[BSVAlias]] is a set of protocols that lay out a structure for making and receiving payments using identity as the means to link sender and receiver.

[[Paymail]] is the first practical implementation of BSVAlias.

==Payment Channels==
Any transaction that has both an [[nLocktime]] in the future and an [[nSequence]] that is less than 0xFFFFFFFF is not finalised, and potentially from a [[Payment Channels|payment channel]].
The transaction can be updated once, or many times between peers until either nSequence is finalised or nLocktime runs out and one of the parties transmits the transaction to the blockchain.
Payment channels are useful for streaming data, operating a sequence of events or operating with a live dataset in applications such as gaming and more.
Payment channels have been unavailable since the early versions of Bitcoin and have been re-enabled since the [[Genesis upgrade]], enabling many potential use cases.

==Legacy Payment Protocols==
These are payment protocols where the payer is asked to broadcast a transaction to the network (instead of the payee) so the payee can scan the network for relevant transactions rather than handling the transaction peer-to-peer as with [[Simplified_Payment_Verification|SPV]].

===IP to IP payments===
The original version of the Bitcoin node client had the facility to conduct IP-IP payments where a receiver could give a payer their IP address. The payer's client would reach out to the Payee's client and request a public key for the payment to be addressed to.
This payment method was one of the first features removed by the Bitcoin Core team when they took over the project.
New payment processes are in development which draw from this original idea, and will allow network peers to interact securely using cryptographically verified IP addresses.

===BIP-0021===
[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP-0021] has been one of the predominant means of making mobile payments in Bitcoin throughout it's history. Almost all QR codes based payment gateways used within Bitcoin are or are an extension of BIP0021. BIP0021 itself is an extension of [https://tools.ietf.org/html/rfc3986 RFC-3986], the RFC standard for URIs (Universal Resource Identifiers).

===BIP-0070===
[https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP-0070] was a payment protocol for reaching out to receivers using an extension of BIP-0021 that added a URL. The URL directed the device to reach out to a server which would provide it a script or address linked to the QR code.

Payments in Bitcoin

2020-02-19T11:06:27Z

Wei:

Payments are an important aspect of Bitcoin. Every transaction is a payment of some sort. Transactions are the only means through which information can be written onto the ledger.

Block discovery events are agreed upon through the acceptance of a [[Coinbase]] transaction as a valid payment. A block is simply the process of having a collection of payments set down, collated and agreed upon as valid.

There are many methods of requesting and making payments.

==BIP-0270==
[https://github.com/moneybutton/bips/blob/master/bip-0270.mediawiki BIP270] is a simplified version of the [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP70 Payment Protocol] introduced in 2013. It is a protocol for communication between a payment host (usually either a merchant, a payment processor, or simply the recipient's wallet) and their customer (the sender of the funds). It enables:
* Better experience
* Simpler wallet infrastructure
* Multiple outputs
* Better security against man-in-the-middle attacks

BIP-270 is designed for wallets that use [[Simplified Payment Verification]] to achieve huge improvements at scale. Transactions can be exchanged partially or in iterations. This is far faster when done peer to peer between the payer and the payee, writing to the ledger only at the end to settle the transaction(s).

This BIP is an optimisation of BIP-0070. Changes include:
* Moves all signature exchange and validation to the communication later (usually HTTPS)
* Add multiple outputs
* A library optimised for peer to peer transaction management

==BSVAlias==
[[BSVAlias]] is a set of protocols that lay out a structure for making and receiving payments using identity as the means to link sender and receiver.

[[Paymail]] is the first practical implementation of BSVAlias.

==Payment Channels==
Any transaction that has both an [[nLocktime]] in the future and an [[nSequence]] that is less than 0xFFFFFFFF is in a [[Payment Channels|payment channel]].
The transaction can be updated once, or many times between peers until either nSequence is finalised or nLocktime runs out and one of the parties transmits the transaction to the blockchain.
Payment channels are useful for streaming data, operating a sequence of events or operating with a live dataset in applications such as gaming and more.
Payment channels have been unavailable since the early versions of Bitcoin and have been re-enabled since the [[Genesis upgrade]], enabling many potential use cases.

==Legacy Payment Protocols==
These are payment protocols where the payer is asked to broadcast a transaction to the network (instead of the payee) so the payee can scan the network for relevant transactions rather than handling the transaction peer-to-peer as with [[Simplified_Payment_Verification|SPV]].

===IP to IP payments===
The original version of the Bitcoin node client had the facility to conduct IP-IP payments where a receiver could give a payer their IP address. The payer's client would reach out to the Payee's client and request a public key for the payment to be addressed to.
This payment method was one of the first features removed by the Bitcoin Core team when they took over the project.
New payment processes are in development which draw from this original idea, and will allow network peers to interact securely using cryptographically verified IP addresses.

===BIP-0021===
[https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki BIP-0021] has been one of the predominant means of making mobile payments in Bitcoin throughout it's history. Almost all QR codes based payment gateways used within Bitcoin are or are an extension of BIP0021. BIP0021 itself is an extension of [https://tools.ietf.org/html/rfc3986 RFC-3986], the RFC standard for URIs (Universal Resource Identifiers).

===BIP-0070===
[https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki BIP-0070] was a payment protocol for reaching out to receivers using an extension of BIP-0021 that added a URL. The URL directed the device to reach out to a server which would provide it a script or address linked to the QR code.

OP CODESEPARATOR

2020-02-19T11:00:50Z

Wei:

OP_CODESEPARATOR was originally designed to be inserted between the ScriptPubKey and ScriptSig by the script evaluation engine. When OP_CHECKSIG is called in the ScriptPubKey, it will remove everything before OP_CODESEPARATOR. In this case, the entire ScriptSig will be removed. This is because ScriptSig which contains the signature is not signed by the signature.

There is no rule to prevent users from inserting OP_CODESEPARATOR into the ScriptPubKey. However, OP_CODESEPARATOR will only be effective if it is read by OP_CHECKSIG in the same ScriptPubKey. OP_CHECKSIG will only read the closest OP_CODESEPARATOR just before it, and remove all contents before that.

Based on the understanding above, we can construct the following ScirptPubKey:

OP_CODESEPARATOR OP_CHECKSIGVERIFY OP_CODESEPARATOR OP_CHECKSIGVERIFY OP_CODESEPARATOR OP_CHECKSIG

To unlock this ScriptPubKey, we can use the following ScriptSig:

<Sig A> <PK A> <Sig B> <PK B> <Sig C> <PK C>

Note that the first OP_CHECKSIG will verify <Sig C> <PK C> on a message that including "OP_CHECKSIGVERIFY OP_CODESEPARATOR OP_CHECKSIGVERIFY OP_CODESEPARATOR OP_CHECKSIG".

The second OP_CHECKSIG will verify <Sig B> <PK B> on a message that including "OP_CHECKSIGVERIFY OP_CODESEPARATOR OP_CHECKSIG" and excluding the first OP_CHECKSIGVERIFY.

The last OP_CHECKSIG will verify <Sig A> <PK A> on a message that including " OP_CHECKSIG" and excluding the first two OP_CHECKSIGVERIFY.

If someone changes the order of the signature in the ScritSig, the verification of the signature will fail.

OP CODESEPARATOR

2020-02-19T10:32:07Z

Wei:

OP_CODESEPARATOR was originally designed to be inserted between the ScriptPubKey and ScriptSig by the script evaluation engine. When OP_CHECKSIG is called in the ScriptPubKey, it will remove everything before OP_CODESEPARATOR. In this case, the entire ScriptSig will be removed. This is because ScriptSig which contains the signature is not signed by the signature.

There is no rule to prevent users from inserting OP_CODESEPARATOR into the ScriptPubKey. However, OP_CODESEPARATOR will only be effective if it is read by OP_CHECKSIG in the same ScriptPubKey. OP_CHECKSIG will only read the closest OP_CODESEPARATOR just before it, and remove all contents before that.

Based on the understanding above, we can construct the following ScirptPubKey:
OP_CODESEPARATOR OP_CHECKSIGVERIFY OP_CODESEPARATOR OP_CHECKSIGVERIFY OP_CODESEPARATOR OP_CHECKSIG

To unlock this ScriptPubKey, we can use the following ScriptSig:
<Sig A> <PK A> <Sig B> <PK B> <Sig C> <PK C>

Note that the first OP_CHECKSIG will verify <Sig C> <PK C> on a message that including "OP_CHECKSIGVERIFY OP_CODESEPARATOR OP_CHECKSIGVERIFY OP_CODESEPARATOR OP_CHECKSIG".

The second OP_CHECKSIG will verify <Sig B> <PK B> on a message that including "OP_CHECKSIGVERIFY OP_CODESEPARATOR OP_CHECKSIG" and excluding the first OP_CHECKSIGVERIFY.

The last OP_CHECKSIG will verify <Sig A> <PK A> on a message that including " OP_CHECKSIG" and excluding the first two OP_CHECKSIGVERIFY.

If someone changes the order of the signature in the ScritSig, the verification of the signature will fail.

Bitcoin Transactions

2020-02-14T15:45:32Z

Wei:

A Bitcoin '''transaction''' consists of a version number, a locktime value, a list of inputs and a list of outputs.

The primary functionality of a Bitcoin transaction is to transfer ownership of Bitcoin from one to another.

A Bitcoin transaction can also serve as a vehicle for smart contracts, recording data, attestation and many other secondary functionalities.

A transaction can be created and iterated inside a [[Payment Channels|Payment Channel]] using [[nLocktime and nSequence]] interlocks, or sent directly to [[the Core Network|The Bitcoin Network]] for inscription into a [[block]].
A transaction uses [[UTXO|unspent transaction outputs (UTXOs)]] as inputs and distributes their value to new outputs. UTXOs are the 'coins' in which all Bitcoins are stored.

Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block. Once transactions have been seen and validated by a majority of block creating nodes in the Bitcoin network, they can be considered settled. When they are eventually mined into a block, miners collaboratively agree on the order in which they were seen by the network.

Transactions are referenced using their [[TXID]] which is a double [[SHA-256]] hash of the fully serialised transaction.

Transaction outputs are puzzle scripts called ScriptPubKeys which are typically used to lock the contained Bitcoin value, sometimes also called locking script. Outputs are redeemed by making them inputs to new transactions and providing a ScriptSig (sometimes called unlocking script) which is a valid solution that unlocks the Bitcoin held in the ScriptPubKey. Outputs may have zero value in Bitcoin, but may carry value in another form such as data or tokens. Scripts can be complex and specialised and may have more than one way to be redeemed.

All transactions are captured on the ledger in [[Block|blocks]] on the [[blockchain]], and can be viewed with a [[block explorer]]. This can be useful for seeing the technical details of transactions in action and for verifying payments.

==General format of a Bitcoin transaction==
The following outlines the elements that are serialised to build a valid Bitcoin transaction.
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Version no
|currently 1
|4 bytes
|-
|In-counter
| positive integer [[ Protocol#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of inputs
|[[Bitcoin_Transactions#Format_of_a_Transaction_Input|Input Structure]]
|<in-counter> qty with variable length per input
|-
|Out-counter
| positive integer [[ Protocol#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of outputs
|[[Bitcoin_Transactions#General_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|Output Structure]]
|<out-counter> qty with variable length per output
|-
|[[NLocktime_and_nSequence#nLockTime|nLocktime]]
|if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final
|4 bytes
|}

==Transaction Inputs and Outputs==

Each Bitcoin transaction is comprised of Inputs and Outputs. Inputs provide the funds to be spent in the transaction, and Outputs define where those funds should be allocated.

=== Inputs ===
An '''input''' is a reference to an output from a previous transaction, and a transactions can include between 1 and 2<super>32</super>.

All of the new transaction's input values (that is, the total coin value of the previous outputs referenced by the new transaction's inputs) are added up, and the total (less any [[transaction_fees|transaction fee]]) is consumed by the outputs of the new transaction. '''Previous tx''' is a [[Wikipedia:Cryptographic_hash_function|hash]] of a previous transaction. '''Index''' is the specific output in the referenced transaction. '''ScriptSig''' is the first half of a [[Opcodes_used_in_Bitcoin_Script|script]] which is provided when a UTXO is spent as an input to a transaction.

An input ScriptSig may contain many components. In a P2PKH script the public key must match the hash given in the script of the redeemed output. The public key is used to verify the redeemer's signature, which is the second component. More precisely, the second component is an [[Elliptic Curve Digital Signature Algorithm|ECDSA]] signature. Dependent on the [[SIGHASH flags]] used, the signature may cover a hash representing part or all of the transaction. Combined with the public key, this proves the transaction was created by a person or process that controls the keys needed to spend the Bitcoin in the input.

=== Format of a Transaction Input ===
Otherwise known as a TXIN, the following table outlines the required elements of a valid transaction input.
{| class="wikitable"
|-
! Field
! Description
! Size
|-
| Previous Transaction hash
| [[TXID]] of the transaction the output was created in
| 32 bytes
|-
| Previous Txout-index
| Index of the output (Non negative integer)
| 4 bytes
|-
|Txin-script length
| Non negative integer [[ Protocol#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|Txin-script / scriptSig
| [[Opcodes_used_in_Bitcoin_Script|Script]]
| <in-script length>-many bytes
|-
| Sequence_no
| Used to iterate inputs inside a payment channel. Input is final when nSequence = 0xFFFFFFFF
| 4 bytes
|}

The input sufficiently describes where and how to get the bitcoin amount to be redeemed.
If it is the (only) input of the first transaction of a block, it is called the [[Coinbase]] message and includes information about which block it was mined in and a miner configurable data element.

== Outputs ==
An '''output''' contains a piece of [[Opcodes_used_in_Bitcoin_Script|Bitcoin Script]] which can be used to lock Bitcoins, requiring a certain set of keys or information to be provided to unlock them. Outputs can also be used to inscribe data onto the ledger.

This '''ScriptPubKey''' is the second half of a full script and is only completed when the output is spent. There can be more than one output, and they share the combined value of the inputs.
The '''Value''' of each output is the number of Satoshis that the script unlocks when solved.
Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire value of the combined inputs needs to be allocated to the transaction outputs. Any [[Satoshis]] left unallocated are considered to be paid in mining fees and are awarded to the miner whose node generates the block that the transaction is included in.

If a user's input is larger than the value they want to send, the transaction must create at least two outputs, one sending the required funds to the destination, and one sending the [[change]] back to the user.

Outputs can have a value of zero satoshis. Currently, these outputs are limited to [[False Return]] scripts and are typically used to carry other information or tokens for [[Application layer protocol|Application layer protocols]].

===Format of a Transaction Output===
Otherwise known as a TXOUT, the following table outlines the required elements of a valid transaction output.
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|value
|non negative integer giving the number of [[Satoshis]] to be transferred
|8 bytes
|-
|Txout-script length
|non negative integer
|1 - 9 bytes [[ Protocol#Variable_length_integer|VI = VarInt]]
|-
|Txout-script / scriptPubKey
|[[Opcodes_used_in_Bitcoin_Script|Script]]
|<out-script length>-many bytes
|}
The output's scriptPubKey sets the conditions to release this bitcoin amount later. The sum of the output values of the first transaction is the value of the mined bitcoins for the block plus possible transactions fees of the other transactions in the block.

== Transaction Validation ==
To verify that inputs are authorized to collect the values of referenced outputs, Bitcoin uses a [[wikipedia:Forth_(programming_language)|Forth]]-like [[Advanced Bitcoin Scripting|scripting]] system. The input's scriptSig and the referenced output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by the scriptSig. The input is authorized if scriptPubKey returns true. Through the scripting system, the sender can create very complex conditions that must be met in order to claim the output's value.

For example, it's possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys or be redeemable with a password instead of a key.

= Puzzles and Solutions =

The flexible scripting language enabled by the Bitcoin protocol allows a multitude of different transaction types to be created. Each scriptSig/scriptPubKey pair is validated by the network miners and mined into a block if the script returns true. Some commonly used Bitcoin puzzle types are described below:

== Pay to Public Key (P2PK) ==

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

When redeeming coins that have been sent to a Bitcoin public key the script validates that the provided signature was generated by the private key that also corresponds to the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig>
| <pubKey> OP_CHECKSIG
| Signature is added to the stack.
|-
|<sig> <pubKey>
| OP_CHECKSIG
| Pubkey is added to stack.
|-
|true
|Empty.
|Signature is checked.
|}

== Pay to Public Key Hash (P2PKH) ==

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

A Bitcoin [[address]] is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

== Pay to R-Puzzle Hash (P2RPH) ==

scriptPubKey: OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

Bitcoins locked in an [[R-Puzzles|R-Puzzle]] script require the spending party to sign using a known value for '[[R-Puzzles#k|k]]' rather than a random number. To redeem the script, the spending party provides both the signature and the public key.

The script verifies that the provided signature was signed using the correct k-value, then checks the signature against the public key. Because the public key is not checked as part of the script solution, it is possible to sign the transaction using any keypair.

This can be useful when dealing with tokens that are associated with a Bitcoin address as the pubkey that corresponds to that address can be used to sign the transaction without the requirement for there to be Bitcoin in the address. The technique is also relevant for Metanet node signing as the Metanet keys can be signed with an R-Puzzle without needing a separate signature.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <sig>
| OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| Second from top stack item is duplicated.
|-
|<sig> <pubKey> <3 bytes> <sig'>
| OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| First 3 bytes of signature are split
|-
|<sig> <pubKey> <sig'>
| OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| 3 byte data item is removed
|-
|<sig> <pubKey> <R Length> <sig">
| OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| 1 byte containing R length is split from sig'
|-
|<sig> <pubKey> <sig"> <R Length>
| OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R Length parameter is moved to top of stack
|-
|<sig> <pubKey> <R> <sig'">
| OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R is split from sig"
|-
|<sig> <pubKey> <R>
| OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| sig'"== is dropped from stack
|-
|<sig> <pubKey> <rHashA>
| <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R is double hashed (SHA256 followed by RIPEMD160) and result left on stack
|-
|<sig> <pubKey> <rHashA> <rHash>
| OP_EQUALVERIFY OP_CHECKSIG
| Previously defined R-Hash is pushed onto stack
|-
|<sig> <pubKey>
| OP_CHECKSIG
| Script checks if rHashA = rHash
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

== Pay to Multi Signature (P2MS) ==

scriptPubKey: OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
scriptSig: OP_1 <sig1> <sig2> <sig4>

OP_CHECKMULTISIG offers users the capability to lock coins with a requirement for multiple parties to sign the scriptSig before coins can be spent. OP_CHECKMULTISIG can check many signatures against many public keys as long as the signatures in the scriptSig are provided in an order that corresponds to the order in which the public keys are arrayed on the stack when it is executed. The first opcode in the ScriptPubKey defines how many signatures must be provided in order for the coin to be successfully spent. The last one before OP_CHECKMULTISIG indicates to the scripting engine how many public keys to evaluate those signatures against. There must be at least as many items on the stack as are required for the OP_CHECKMULTISIG opcode to process or the script will be invalid.

'''Note:'''
The current version of the scripting engine also includes a bug that requires an additional value to be placed on the stack before the signatures. In this example, OP_1 has been used to push a 1 to the top of the stack, but in theory any piece of data can be used. This value is consumed by the checking process but is not evaluated.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| OP_1 <sig1> <sig2> <sig4> OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
| scriptSig and scriptPubKey are combined.
|-
|1 <sig1> <sig2> <sig4>
| OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
| Constants from scriptSig are added to the stack.
|-
|1 <sig1> <sig2> <sig4> 3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5
| OP_CHECKMULTISIG
| Constants from scriptPubKey are added to the stack.
|-
|true
|Empty.
|Multisignature script evaluation is performed
|}

== Other Puzzle Types ==
Bitcoin's scripting language is rich and diverse and allows a user to create almost any kind of financial instrument that we have today, and many that we don't have. Puzzles do not need to conform to any particular standard or template however it is expected that the vast majority of transactions will be built using template scripts.

Examples of more complex script can be found [[Complex Script Examples| here]]

Pieces of script can be combined to make larger and more complex transactions, and scripts can be built inside conditional loops allowing a single transaction output to be redeemed in multiple different ways.

Prior to the Genesis upgrade, complex scripts that fell outside the 'isstandard' testing schema were required to be compressed into a transaction format called '[[P2SH|Pay to Script Hash (P2SH)]]' This format is now deprecated in favour of using the full, rich scripting language inside transactions.

=See Also=

* [[Opcodes used in Bitcoin Script]]
* [[Protocol#"tx" messages|Protocol rules - "tx" messages]]
* [[Protocol#Transaction Verification|Protocol documentation - Transaction Verification]]
* [[Transaction Malleability]]

History of OP RETURN

2020-02-07T10:54:08Z

Wei:

The OP_RETURN opcode has a controversial history that has resulted in it being used as the primary mechanism to store arbitrary data on-chain. The original functionality was intended to behave as a return operation that ends execution of the script. The original implementation of the opcode had a critical bug and was quickly [https://github.com/bitcoin/bitcoin/commit/73aa262647ff9948eaf95e83236ec323347e95d0 patched by Satoshi Nakamoto.]

=== 1 RETURN Bug ===
OP_RETURN was originally intended to return the top value on the stack.

Given the script:

OP_TRUE OP_RETURN

True would be returned from the script and the script would terminate, ignoring any opcodes that came afterwards; because of this, this example script could prepend any unlocking script, granting the ability for one to steal anyone's Bitcoin.

The functionality of the opcode was changed to always return false instead of returning the value on top of the stack.

=== Bitcoin Core Rhetoric ===
In Bitcoin Core's [https://bitcoin.org/en/release/v0.9.0#rebranding-to-bitcoin-core v0.9.0 update], OP_RETURN output was made standard but was only relayed with a 40 byte limit, which was then later increased to an 80 byte limit. Bitcoin Core made this change advising the users of the network that in their opinion, arbitrary data should not be stored in the [[block_chain|blockchain]].

=== Storing data on-chain ===
The modification to OP_RETURN to always return false had interesting implications. Any opcodes or data are not evaluated after the OP_RETURN so users of the network began using this opcode to store arbitrary data.

This opcode was used instead of the OP_PUSHDATA opcodes since the max script size was limited to 520 bytes. These two fundamental changes to Bitcoin resulted in the opcode being used in an unforeseen and interesting way, outside of its original intent.

In January 2019, a [https://www.yours.org/content/the-unfuckening-of-op_return-b10d2c4b52da discovery] was made that because the OP_RETURN opcode terminated the script such that nodes did not validate anything after it occurred, this also meant that nodes did not check that the script did not exceed the max script size limit of 520 bytes. Communication of this went out to the miners on the network who then raised their maximum transaction size to 100KB. This resulted in the users putting various data on the [[block_chain|blockchain]], for example, an entire [https://whatsonchain.com/tx/21a5c896f23bea81ae5018dfeb8801ddc68691d0186a7e2d8c011e65e0a396d9 website].

=== Return to original functionality ===
The [[Genesis_upgrade|Genesis upgrade]] in February 2020 restored the original functionality of the opcode. This did not impact the ability to store arbitrary data on-chain, however the best practice has been amended to advise the use of [[False Return]] scripts for applications that still seek to do so.

Reverting to the ability to return a value will enable more robust scripts to be created; for example scripts can now return different values based on conditional logic.

{{DISPLAYTITLE:History of OP_RETURN}}

OP RETURN

2020-02-07T10:50:08Z

Wei:

'''OP_RETURN''' is a [[Opcodes_used_in_Bitcoin_Script|script]] opcode used to terminate the script and return the top value on the stack. This opcode is analogous to the return function in programming languages. The OP_RETURN opcode has a [[History_of_OP_RETURN|controversial history]] in Bitcoin and as a result has been primarily used as a means of storing data on the [[block_chain|blockchain]].

===OP_RETURN Functionality===
OP_RETURN terminates the script leaving the stack as-is and letting the result on top of the stack determine the success or failure of the script. Note that if the top stack is non-empty and non-zero (zero including a string of zeros, of zero bytes), then it is considered as successful. Otherwise, it is considered as fail. OP_RETURN can be used in combination with [[Opcodes_used_in_Bitcoin_Script#Flow_control|flow control]] opcodes to implement branching, conditional logic in scripts.

===Example===
The below script is a metanet node that attaches the Metanet data to a UTXO with funds. This can be used to ensure that metanet nodes are left in the UTXO set

{| class="wikitable"
|-
! colspan="2"| 𝑇𝑥𝐼𝐷𝑛𝑜𝑑𝑒
|-
| ''Inputs''
| ''Outputs''
|-
| <sigmetaParent> <pubKeymetaParent> <sigscript> <pubKeyscript>
| DUP HASH160 <pkhscript> EQUALVERIFY CHECKSIG RETURN <meta> <pkmetaNode> <txidmetaParent> <data>
|}

{{DISPLAYTITLE:OP_RETURN}}

Paymail

2020-02-07T10:44:25Z

Wei:

Paymail is a practical implementation of the family of related protocols collectively referred to as [[BSVAlias]].
In brief, it is an identity protocol that removes Bitcoin addresses from the user experience. Instead of addresses, Paymail uses human-readable names that look exactly the same as email addresses. Paymails are much easier to type into a device than Bitcoin addresses and can be used to identify an individual via the Paymail identifier.

The protocol describes a procedure where a wallet provider will be able to be discovered and contacted, and can respond to payments and payment requests in real time so that payment receivers don’t have to re-use their Bitcoin [[Address reuse|addresses]], thereby maintaining privacy.

As a simplified example, in order for Alice to send some Bitcoin to Bob, Alice sends the payment to Bob@paymail.com. The paymail protocol implemented by Bob's wallet will provide a Bitcoin address for the actual Bitcoin transaction creation, but this is done behind the user experience. Note that the security will rely on a public key infrastructure.

At the time of writing, the protocols cover:

*BRFC Specifications
*Service Discovery
*Public Key Infrastructure
*Payment Addressing

For more information visit the [https://bsvalias.org/ BSVAlias website].

Paymail is the name for the implementation of the following protocols:

*Service Discovery
*Public Key Infrastructure
*Basic Address Resolution from the Payment Addressing protocol group

The Paymail brand is reserved for products and services that, at a minimum, implement each of the above protocols.

[https://moneybutton.com Moneybutton] has published content describing Paymail and why it is needed [https://blog.moneybutton.com/2019/05/31/introducing-paymail-an-extensible-identity-protocol-for-bitcoin-bsv/ here]

Paymail

2020-02-07T10:43:10Z

Wei:

Paymail is a practical implementation of the family of related protocols collectively referred to as [[BSVAlias]].
In brief, it is an identity protocol that removes Bitcoin addresses from the user experience. Instead of addresses, Paymail uses human-readable names that look exactly the same as email addresses. Paymails are much easier to type into a device than Bitcoin addresses and can be used to identify an individual via the Paymail identifier.

The protocol describes a procedure where a wallet provider will be able to be discovered and contacted, and can respond to payments and payment requests in real time so that payment receivers don’t have to re-use their Bitcoin [[Address reuse|addresses]], thereby maintaining privacy.

As a simplified example, in order for Alice to send some Bitcoin to Bob, Alice sends the payment to Bob@paymail.com. The paymail protocol implemented by Bob's wallet will provide a Bitcoin address for the actual Bitcoin transaction creation. Note that the security will rely on a public key infrastructure.

At the time of writing, the protocols cover:

*BRFC Specifications
*Service Discovery
*Public Key Infrastructure
*Payment Addressing

For more information visit the [https://bsvalias.org/ BSVAlias website].

Paymail is the name for the implementation of the following protocols:

*Service Discovery
*Public Key Infrastructure
*Basic Address Resolution from the Payment Addressing protocol group

The Paymail brand is reserved for products and services that, at a minimum, implement each of the above protocols.

[https://moneybutton.com Moneybutton] has published content describing Paymail and why it is needed [https://blog.moneybutton.com/2019/05/31/introducing-paymail-an-extensible-identity-protocol-for-bitcoin-bsv/ here]

Genesis upgrade

2020-02-07T10:22:21Z

Wei:

Genesis was a major update to the BitcoinSV mining client used by the majority of miners on the BitcoinSV network at the time. Genesis went into effect at block height [https://whatsonchain.com/block-height/620538 620538] which was mined with a timestamp of 01:35:06 UTC on the 4th of February 2020.

The upgrade reverted many aspects of the Bitcoin protocol that had been modified in previous software updates including the removal of all limit based consensus rules, replacing them with miner configurable settings that give node operators the autonomy needed to set their own limits as they determine are practical.

The upgrade was validated when [https://whatsonchain.com/tx/4ec3b63d764558303eda720e8e51f69bbcfe81376075657313fb587306f8a9b0 this transaction] was mined at block height 620539. The transaction uses a script that would previously have been considered non-standard and rejected by network nodes running the BitcoinSV node client.

Further details on the changes made in the upgrade can be found [https://bitcoinsv.io/2020/01/15/changes-for-the-genesis-upgrade/ here] and the full specification is available [https://github.com/bitcoin-sv-specs/protocol/blob/master/updates/genesis-spec.md here].

==Block Consensus Rules==
These consensus rules apply to blocks that are produced after Genesis activation.

* Block Size - The consensus rule that restricts the maximum size of a block to a specific number of bytes has been converted into a configurable consensus rule. The size of a block is the size in bytes of the serialized form of the block including the block header and all of the transactions confirmed by the block. MINERS ARE EXPECTED TO REACH CONSENSUS ON THIS VALUE AND CONFIGURE IT MANUALLY.

* Number of CheckSig Operations per MB of Block Space - The consensus rule that limits the number of checksig operations per megabyte of block space has been removed.

==Transaction Consensus Rules==
These consensus rules apply to transactions that are confirmed in blocks after Genesis activation.

* Maximum Transaction Size - The size of a transaction is the size in bytes of the serialized form of the transaction. The maximum size of a transaction is 1GB (1,000,000,000 bytes). This limitation is expected to be lifted in the future.

* Maximum Number of CheckSig Operations per Transaction - The consensus rule that limits the number of checksig operations per transaction has been removed.

* nLockTime and nSequence - After Genesis activation, the functionality of the nLockTime field of a transaction and the nSequence fields of transaction inputs revert to their original purpose. The rules defined here only apply to transactions that are confirmed after Genesis activation.

==Script Language Rules==
This section contains changes to the Script Language Rules.
Bitcoin Script is the programming language that is used to lock and unlock transaction outputs. More can be found at: [https://wiki.bitcoinsv.io/index.php/Advanced_Bitcoin_Scripting Advanced Bitcoin Scripting]. The rules defined here apply to locking and unlocking scripts for transaction outputs that are created after the Genesis activation. The previous rules apply to transaction outputs created prior to Genesis activation.

===OP_RETURN Functionality===

The functionality of the OP_RETURN operation is being restored. OP_RETURN will cause termination of the script and the validity of the script is determined by the value of the top item on the stack. See [https://wiki.bitcoinsv.io/index.php/OP_RETURN OP_RETURN].

===Data Types===

All data items in Bitcoin Script as a byte sequence. Some operations interpret their parameters as numeric or boolean values and require the itme to fulfill the requirements of those types. Some operations produce items on the stack which are valid numeric or boolean values.

===Bitcoin Script Formal Grammar===

A formal grammar has been defined for Bitcoin Script. More can be found at: [https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_Script Opcodes used in Bitcoin Scripting].

* Validity of Script Consensus Rule - The locking and unlocking scripts for every input of a transaction must be grammatically valid, as defined by the formal grammar above.

* PUSHDATA Only in Unlocking Script Consensus Rule - After Genesis activation, the unlocking scripts used in transaction inputs may only contain PUSHDATA operations, as defined by the formal grammar. In contrast to all the other updates in this section, this consensus rule is activated for all inputs of transactions that are, or will be, confirmed in a block after Genesis activation, regardless of the height of the UTXO being spent. This rule is a subset of the Validity of Script Consensus Rule defined above but is included separately because the activation conditions are different.

===Consensus Rule Replacement===

Functionality provided by these consensus rules is now covered by the Stack Memory Usage Consensus Rule.

<table>
<tr><td>Consensus Rule</td><td>Description</td></tr>
<tr><td>Script Element Size</td><td>Limits the maximum size of a script element.</td></tr>
<tr><td>Stack Size</td><td>Limits the combined number of elements that can be placed on the stack and the altstack.</td></tr>
<tr><td>Script Size*</td><td>The maximum size of the script</td></tr>
<tr><td>Number of Non-Push Operations per Script</td><td>Limits the number
of non-push operations per script. Other capabilities manage the cost of execution.</td></tr>
</table>
*functionality also covered by the Maximum Transaction Size Consensus Rule.

===Consensus Rule Changes===

<table>
<tr><td>Consensus Rule</td><td>Description</td></tr>
<tr><td>Numeric Value Size</td><td>For a byte sequence to represent validly a numeric value, the length of the byte sequence must be less than or equal to 750,000 bytes. A byte sequence that is larger than this is a valid byte sequence but is not a valid numeric value.</td></tr>
<tr><td>Number of Public Keys per Multisig Consensus Rule</td><td>Limits the number of public keys per multisig has been changed to be 2^31-1 (INT32_MAX).</td></tr>
<tr><td>Stack Memory Usage</td><td>Limits the amount of memory that can be used on the stacks. This rule is evaluated against the sum of the memory used by the stack and the memory used by the altstack.</td></tr>
</table>

===Sunsetting===

* P2SH, OP_CHECKLOCKTIMEVERIFY, and OP_CHECKSEQUENCEVERIFY - The P2SH capability is being removed by the Genesis upgrade and the presence of a p2sh script template in an output will invalidate a transction. The opocde operations revert to NOPs, which have no effect.

* Disabling Operations Consensus Rule - OP_2MUL, OP_2DIV, OP_VERIF, OP_VERNOTIF . If they are present in un-executed script, the script execution may succeed.

==Standard Local Policies==

Policies are settings that are configured by software operators. These settings are generally required by software implementations.

Policies control which transactions the software will propagate across the P2P network or include in a block. However, policies are not Bitcoin Rules or Consensus Rules and are not used to determine the validity of blocks or the transactions confirmed by the block.

Standard Local Transaction Policies
* Maximum Acceptable Transaction Size Policy - The maximum acceptable transaction size is a standard policy that configures the largest transactions that the software will propagate across the P2P network or include in a block.
* Transaction Evaluation Timeout - The transaction evaluation timeout is a standard policy that defines the maximum amount of time that the software will allow for the evaluation of transaction before terminating the evaluation and rejecting the transaction. This setting is always defined with a time unit and the default value 1 second.

Standard Local Script Language Policies
* Numeric Value Length - the length of numeric value policy defines the maximum length of a byte sequence to be considered a valid numeric value. The default value for this value is 250,000 bytes.
* Stack Memory Usage - The stack memory usage policy limits the amount of memory that can be used on the stacks. This policy is evaluated against the sum of memory used by the stack and the memory used the altstack.

Standard Local P2P Network Policies
* Propagation of non-Standard Transactions - After Genesis activation, the default setting for this policy is that non-standard transactions will be propagated across the P2P network. Before Genesis activation, the default setting for this policy was non-standard transactions are not propagated the P2P Network. Policies such as Maximum Acceptable Transaction Size Policy still apply.

Bitcoin Transactions

2020-02-07T10:19:23Z

Wei:

A '''transaction''' is a serialised data item that authorises an exchange between inputs and outputs.

A transaction can be created and iterated inside a [[Payment Channels|Payment Channel]] using [[nLocktime and nSequence]] interlocks, or sent directly to [[the Core Network|The Bitcoin Network]] for inscription into a [[block]].
A transaction uses [[UTXO|unspent transaction outputs (UTXOs)]] as inputs and distributes their value to new outputs. UTXOs are the 'coins' in which all Bitcoins are stored.

Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block. Once transactions have been seen and validated by a majority of block creating nodes in the Bitcoin network, they can be considered settled. When they are eventually mined into a block, miners collaboratively agree on the order in which they were seen by the network.

Transactions are referenced using their [[TXID]] which is a double [[SHA-256]] hash of the fully serialised transaction.

Transaction outputs are puzzle scripts called ScriptPubKeys which are typically used to lock the contained Bitcoin value, sometimes also called locking script. Outputs are redeemed by making them inputs to new transactions and providing a ScriptSig (sometimes called unlocking script) which is a valid solution that unlocks the Bitcoin held in the ScriptPubKey. Outputs may have zero value in Bitcoin, but may carry value in another form such as data or tokens. Scripts can be complex and specialised and may have more than one way to be redeemed.

All transactions are captured on the ledger in [[Block|blocks]] on the [[blockchain]], and can be viewed with a [[block explorer]]. This can be useful for seeing the technical details of transactions in action and for verifying payments.

==General format of a Bitcoin transaction==
The following outlines the elements that are serialised to build a valid Bitcoin transaction.
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Version no
|currently 1
|4 bytes
|-
|In-counter
| positive integer [[ Protocol#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of inputs
|[[Bitcoin_Transactions#Format_of_a_Transaction_Input|Input Structure]]
|<in-counter> qty with variable length per input
|-
|Out-counter
| positive integer [[ Protocol#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of outputs
|[[Bitcoin_Transactions#General_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|Output Structure]]
|<out-counter> qty with variable length per output
|-
|[[NLocktime_and_nSequence#nLockTime|nLocktime]]
|if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final
|4 bytes
|}

==Transaction Inputs and Outputs==

Each Bitcoin transaction is comprised of Inputs and Outputs. Inputs provide the funds to be spent in the transaction, and Outputs define where those funds should be allocated.

=== Inputs ===
An '''input''' is a reference to an output from a previous transaction, and a transactions can include between 1 and 2<super>32</super>.

All of the new transaction's input values (that is, the total coin value of the previous outputs referenced by the new transaction's inputs) are added up, and the total (less any [[transaction_fees|transaction fee]]) is consumed by the outputs of the new transaction. '''Previous tx''' is a [[Wikipedia:Cryptographic_hash_function|hash]] of a previous transaction. '''Index''' is the specific output in the referenced transaction. '''ScriptSig''' is the first half of a [[Opcodes_used_in_Bitcoin_Script|script]] which is provided when a UTXO is spent as an input to a transaction.

An input ScriptSig may contain many components. In a P2PKH script the public key must match the hash given in the script of the redeemed output. The public key is used to verify the redeemer's signature, which is the second component. More precisely, the second component is an [[Elliptic Curve Digital Signature Algorithm|ECDSA]] signature. Dependent on the [[SIGHASH flags]] used, the signature may cover a hash representing part or all of the transaction. Combined with the public key, this proves the transaction was created by a person or process that controls the keys needed to spend the Bitcoin in the input.

=== Format of a Transaction Input ===
Otherwise known as a TXIN, the following table outlines the required elements of a valid transaction input.
{| class="wikitable"
|-
! Field
! Description
! Size
|-
| Previous Transaction hash
| [[TXID]] of the transaction the output was created in
| 32 bytes
|-
| Previous Txout-index
| Index of the output (Non negative integer)
| 4 bytes
|-
|Txin-script length
| Non negative integer [[ Protocol#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|Txin-script / scriptSig
| [[Opcodes_used_in_Bitcoin_Script|Script]]
| <in-script length>-many bytes
|-
| Sequence_no
| Used to iterate inputs inside a payment channel. Input is final when nSequence = 0xFFFFFFFF
| 4 bytes
|}

The input sufficiently describes where and how to get the bitcoin amount to be redeemed.
If it is the (only) input of the first transaction of a block, it is called the [[Coinbase]] message and includes information about which block it was mined in and a miner configurable data element.

== Outputs ==
An '''output''' contains a piece of [[Opcodes_used_in_Bitcoin_Script|Bitcoin Script]] which can be used to lock Bitcoins, requiring a certain set of keys or information to be provided to unlock them. Outputs can also be used to inscribe data onto the ledger.

This '''ScriptPubKey''' is the second half of a full script and is only completed when the output is spent. There can be more than one output, and they share the combined value of the inputs.
The '''Value''' of each output is the number of Satoshis that the script unlocks when solved.
Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire value of the combined inputs needs to be allocated to the transaction outputs. Any [[Satoshis]] left unallocated are considered to be paid in mining fees and are awarded to the miner whose node generates the block that the transaction is included in.

If a user's input is larger than the value they want to send, the transaction must create at least two outputs, one sending the required funds to the destination, and one sending the [[change]] back to the user.

Outputs can have a value of zero satoshis. Currently, these outputs are limited to [[False Return]] scripts and are typically used to carry other information or tokens for [[Application layer protocol|Application layer protocols]].

===Format of a Transaction Output===
Otherwise known as a TXOUT, the following table outlines the required elements of a valid transaction output.
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|value
|non negative integer giving the number of [[Satoshis]] to be transferred
|8 bytes
|-
|Txout-script length
|non negative integer
|1 - 9 bytes [[ Protocol#Variable_length_integer|VI = VarInt]]
|-
|Txout-script / scriptPubKey
|[[Opcodes_used_in_Bitcoin_Script|Script]]
|<out-script length>-many bytes
|}
The output's scriptPubKey sets the conditions to release this bitcoin amount later. The sum of the output values of the first transaction is the value of the mined bitcoins for the block plus possible transactions fees of the other transactions in the block.

== Transaction Validation ==
To verify that inputs are authorized to collect the values of referenced outputs, Bitcoin uses a [[wikipedia:Forth_(programming_language)|Forth]]-like [[Advanced Bitcoin Scripting|scripting]] system. The input's scriptSig and the referenced output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by the scriptSig. The input is authorized if scriptPubKey returns true. Through the scripting system, the sender can create very complex conditions that must be met in order to claim the output's value.

For example, it's possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys or be redeemable with a password instead of a key.

= Puzzles and Solutions =

The flexible scripting language enabled by the Bitcoin protocol allows a multitude of different transaction types to be created. Each scriptSig/scriptPubKey pair is validated by the network miners and mined into a block if the script returns true. Some commonly used Bitcoin puzzle types are described below:

== Pay to Public Key (P2PK) ==

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

When redeeming coins that have been sent to a Bitcoin public key the script validates that the provided signature was generated by the private key that also corresponds to the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig>
| <pubKey> OP_CHECKSIG
| Signature is added to the stack.
|-
|<sig> <pubKey>
| OP_CHECKSIG
| Pubkey is added to stack.
|-
|true
|Empty.
|Signature is checked.
|}

== Pay to Public Key Hash (P2PKH) ==

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

A Bitcoin [[address]] is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

== Pay to R-Puzzle Hash (P2RPH) ==

scriptPubKey: OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

Bitcoins locked in an [[R-Puzzles|R-Puzzle]] script require the spending party to sign using a known value for '[[R-Puzzles#k|k]]' rather than a random number. To redeem the script, the spending party provides both the signature and the public key.

The script verifies that the provided signature was signed using the correct k-value, then checks the signature against the public key. Because the public key is not checked as part of the script solution, it is possible to sign the transaction using any keypair.

This can be useful when dealing with tokens that are associated with a Bitcoin address as the pubkey that corresponds to that address can be used to sign the transaction without the requirement for there to be Bitcoin in the address. The technique is also relevant for Metanet node signing as the Metanet keys can be signed with an R-Puzzle without needing a separate signature.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <sig>
| OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| Second from top stack item is duplicated.
|-
|<sig> <pubKey> <3 bytes> <sig'>
| OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| First 3 bytes of signature are split
|-
|<sig> <pubKey> <sig'>
| OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| 3 byte data item is removed
|-
|<sig> <pubKey> <R Length> <sig">
| OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| 1 byte containing R length is split from sig'
|-
|<sig> <pubKey> <sig"> <R Length>
| OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R Length parameter is moved to top of stack
|-
|<sig> <pubKey> <R> <sig'">
| OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R is split from sig"
|-
|<sig> <pubKey> <R>
| OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| sig'"== is dropped from stack
|-
|<sig> <pubKey> <rHashA>
| <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R is double hashed (SHA256 followed by RIPEMD160) and result left on stack
|-
|<sig> <pubKey> <rHashA> <rHash>
| OP_EQUALVERIFY OP_CHECKSIG
| Previously defined R-Hash is pushed onto stack
|-
|<sig> <pubKey>
| OP_CHECKSIG
| Script checks if rHashA = rHash
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

== Pay to Multi Signature (P2MS) ==

scriptPubKey: OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
scriptSig: OP_1 <sig1> <sig2> <sig4>

OP_CHECKMULTISIG offers users the capability to lock coins with a requirement for multiple parties to sign the scriptSig before coins can be spent. OP_CHECKMULTISIG can check many signatures against many public keys as long as the signatures in the scriptSig are provided in an order that corresponds to the order in which the public keys are arrayed on the stack when it is executed. The first opcode in the ScriptPubKey defines how many signatures must be provided in order for the coin to be successfully spent. The last one before OP_CHECKMULTISIG indicates to the scripting engine how many public keys to evaluate those signatures against. There must be at least as many items on the stack as are required for the OP_CHECKMULTISIG opcode to process or the script will be invalid.

'''Note:'''
The current version of the scripting engine also includes a bug that requires an additional value to be placed on the stack before the signatures. In this example, OP_1 has been used to push a 1 to the top of the stack, but in theory any piece of data can be used. This value is consumed by the checking process but is not evaluated.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| OP_1 <sig1> <sig2> <sig4> OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
| scriptSig and scriptPubKey are combined.
|-
|1 <sig1> <sig2> <sig4>
| OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
| Constants from scriptSig are added to the stack.
|-
|1 <sig1> <sig2> <sig4> 3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5
| OP_CHECKMULTISIG
| Constants from scriptPubKey are added to the stack.
|-
|true
|Empty.
|Multisignature script evaluation is performed
|}

== Other Puzzle Types ==
Bitcoin's scripting language is rich and diverse and allows a user to create almost any kind of financial instrument that we have today, and many that we don't have. Puzzles do not need to conform to any particular standard or template however it is expected that the vast majority of transactions will be built using template scripts.

Examples of more complex script can be found [[Complex Script Examples| here]]

Pieces of script can be combined to make larger and more complex transactions, and scripts can be built inside conditional loops allowing a single transaction output to be redeemed in multiple different ways.

Prior to the Genesis upgrade, complex scripts that fell outside the 'isstandard' testing schema were required to be compressed into a transaction format called '[[P2SH|Pay to Script Hash (P2SH)]]' This format is now deprecated in favour of using the full, rich scripting language inside transactions.

=See Also=

* [[Opcodes used in Bitcoin Script]]
* [[Protocol#"tx" messages|Protocol rules - "tx" messages]]
* [[Protocol#Transaction Verification|Protocol documentation - Transaction Verification]]
* [[Transaction Malleability]]

History of Bitcoin

2020-02-06T17:12:13Z

Wei:

=DISCLAIMER=
This article is a an extract from the original https://en.bitcoin.it/wiki/Bitcoin and has not been checked for correctness or edited.
*Date: 25 September 2019
*Final reviews must be conducted by: 15 October 2019

Review:
May need to be completely dumped
Has anyone read Michael Hudson's new book? He's giving it away for free. Maybe we can incorporate it if it's well written.

Need to either remove references to or add in templates

History ends at 2012 (might need to copy more stuff across from 'what is bitcoin' page

==History==

In 2008, Satoshi Nakamoto published the [https://bitcoinsv.io/bitcoin.pdf the Bitcoin white paper] on The Cryptography Mailing List at metzdowd.com ([https://www.mail-archive.com/search?l=cryptography@metzdowd.com&q=from:%22Satoshi+Nakamoto%22 Satoshi's posts]) describing the Bitcoin protocol.

In 2009, the Bitcoin network came into existence on the 3rd of January with the release of the first Bitcoin client, wxBitcoin, and the issuance of the first Bitcoins. Satoshi included a message in the [https://whatsonchain.com/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f first block] via the coinbase transaction: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks".

In 2010, the initial exchange rates for Bitcoin were set by individuals on the bitcointalk forums. In May, Laszlo Hanyecz purchased two pizzas with 10,000 bitcoins.

In 2012, [https://www.americanbanker.com/news/bitpay-signs-1-000-merchants-to-accept-bitcoin-payments BitPay] reports of having over 1000 merchants accepting Bitcoin under its payment processing service.

In 2014, a criminal platform, “Silk Road”, which used Bitcoin was shut down completely. It showed that after all, Bitcoin is not a place for criminals.

In 2017, in order to be able to scale Bitcoin and avoid radical changes, Bitcoin is hard forked to Bitcoin Cash and Bitcoin Core. In December, the price of Bitcoin reached almost $20,000 per bitcoin. The pizzas purchased in 2010 would be valued at $200 millions.

In 2018, in order to scale further and avoid unnecessary changes to the Bitcoin original protocol, Bitcoin Cash is hard forked again to Bitcoin Cash ABC and Bitcoin SV (Satoshi Vision).

In 2020, Bitcoin SV delivered the Genesis upgrade that returned Bitcoin to its original protocol, and removed all the limits that were put on the protocol by developers. The power is handed over from developers to miners.

Digital signatures in Bitcoin

2020-01-31T12:15:30Z

Wei:

The [https://bitcoinsv.io/bitcoin.pdf Bitcoin whitepaper] describes an electronic coin as a chain of digital signatures. These digital signatures confer ownership rights over the coins held in any given script, and can be used as a record of ownership to trace ownership back through the history of the ledger.

[[File:Chain_of_Signatures.png|frame|centre|alt=Electronic coins are defined as a chain of digital signatures]]

A digital signature isn't merely a message signed using a given keypair, but is a link to an identity. The European Union legislation on Digital Signatures states that signatures correspond to “data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication”. For more information, see [https://craigwright.net/blog/law-regulation/how-digital-signatures-work/ this article] from Dr Craig Wright.

Bitcoin script allows users to lock/unlock their bitcoin in different ways.

==Elliptical Curve Digital Signature Algorithm (ECDSA) ==
[[Elliptic Curve Digital Signature Algorithm]] is the most commonly used signature type in Bitcoin. It makes use of the elliptic curve cryptography keypairs referenced in [[Address|Bitcoin addresses]] to generate secure signatures from a given message hash.

Using Bitcoin Script, it is possible to create novel systems that use elliptical curve digital signatures, including [[R-Puzzles]], [[multisignature scripts]] and [[Threshold Signatures]].

==Threshold Signatures==
There have also been practical implementations of [[Threshold Signatures]] in Bitcoin wallets and libraries which extend Elliptic Curve signatures to enable multiple parties to participate in the creation of a signature created from a private key that is never explicitly calculated or existed. When used in a transaction, a Threshold Signature is no different to a normal ECDSA signature and can be validated using [[OP_CHECKSIG]] and related signature check opcodes.

==Rabin Signatures==
To counter a push for the insertion of opcodes to evaluate data from outside the Bitcoin ledger, researchers at nChain have begun developing methods of validating [https://nchain.com/app/uploads/2018/09/Rabin-Signatures-in-Bitcoin-Cash-v2.pdf Rabin signatures] in Bitcoin script. These signatures could theoretically allow for data collected outside the BSV ledger to be evaluated and signed allowing oracle functionality within Bitcoin transactions.
Currently no practical implementation of a Rabin signature in Bitcoin Script exists.

P2SH

2020-01-31T12:12:00Z

Wei:

'''Pay to script hash''' (P2SH) was deprecated as part of the BitcoinSV [[Genesis upgrade]] in February 2020.

==History of P2SH==
P2SH transactions were designed to allow funds to be locked with a script hash. To spend bitcoins locked in a P2SH output, the recipient needed to possess a script matching the script hash and a corresponding set of data which could solve the puzzle. It was introduced as [https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki BIP-0016].

P2SH was created after limits and transaction standardisation requirements were introduced that limited the scope of Bitcoin transactions that could be propagated over the BTC networks to a specific set of templated designs.

P2SH enabled users to create a customised Bitcoin script and hash it into an ~34-character P2SH address. These were most commonly used to manage multisignature wallets that required more than 2 of 3 signature rights as was limited by the isStandard transaction test. Bitcoin P2SH addresses always started with <code>3</code>.

== Spending P2SH outputs ==
P2SH outputs remain spendable under network rules however any transactions generated post Genesis using a P2SH output script will not have their full script evaluated during the spend check.

VOUT

2020-01-31T12:02:09Z

Wei:

"vout" has two interpretations in a transaction.

When it appears in an input of a transaction, it is an index of 4 bytes. It is concatenated with a transaction ID (TxID || vout) to form an outpoint that is used to uniquely identify a particular output of a transaction. As the index is a 4 byte number, this gives users the effective ability to include a maximum of 232 outputs in a Bitcoin transaction.

When it is not part of the input, it refers to a vector of outputs of the transactions. That is, "vout" is the set of all outputs of the transaction, where each output contains output value (the amount of BSV) and scriptPubKey (a script that locks the output value). Note that the order within the set matters.

==Unspent Transaction Outputs==
If an outpoint has not been spent, it is referred to as an Unspent Transaction Output or [[UTXO]] and can be used in the creation of a new transaction. Once an outpoint has been used as an input to a [[Bitcoin Transactions|transaction]] that has been validated by the mining network it is considered spent and can no longer be used in a new transaction (see [[Double-spending]]).

==Zero value outputs==
Outputs that do not contain a value in [[Satoshis]] are often used to hold scripts that carry large data items or tokens. Provably unspendable zero-value [[False Return]] outputs are predominantly used as a means to attach data to bitcoin transactions. False return transaction outputs are not stored in the UTXO set derived by miners.

Non-[[False Return|false return]] zero value outputs are still valid UTXOs and can be used as inputs in a transaction, with locking conditions being applied as normal.

==See Also==
* - [[TXID]]
* - [[Bitcoin Transactions]]

==References==
[1] - https://github.com/bitcoin-sv/bitcoin-sv/blob/7fd177c7c443ff7723d88c5465fbf39285388e30/src/primitives/transaction.h

Transaction fees

2020-01-31T11:32:54Z

Wei:

'''Miner fees''' are a fee that spenders may include in any [[Bitcoin Transactions]]. The fees may be collected by the miner who includes the transaction in a [[Block]].

Transaction fees are a service charge paid to the miners who create the Bitcoin ledger. The services provided by miners are transaction validation, storage of the ledger and the construction and security of the Bitcoin network.

== Overview ==
Every Bitcoin transaction spends zero or more bitcoins to zero or more recipients. The difference between the amount being spent and the amount being received is the transaction fee (which must be zero or more).

Bitcoin's design makes it easy and efficient for the sending party to specify how much fee to pay however it is theoretically possible for a merchant to pay the mining fees on behalf of their customers as an incentive to use their service. Services that make this possible have been proposed.

When a miner creates a [[GetBlockTemplate interface|block template]], they are entitled to specify where the fees paid by the transactions in that block proposal should be sent. If the proposal results in a valid block that becomes a part of the [[Block chain]], the fee income will be sent to the specified recipient. Miners are forced to wait 100 blocks before they can move coins received in a [[Coinbase]] transaction.

==Loss of fees==

If a valid block awards its finder less than the available fees plus the [[Block subsidy]], the [[Satoshis]] which are not collected are permanently destroyed. This has happened on more than 1,000 occasions in Bitcoin's history reducing the token supply by over 50 Bitcoins.

==The Bitcoin Fee Market==

A default minimum fee is usually needed for a transaction to be propagated across the network and mined into a block however a market has arisen offering discounted transactions for bulk generators. The upcoming MinerAPI package will give miners a means by which to interface with regular users and to offer their own unique pricing on a per-node basis. User wallets will be able to make use of this service to present users with fee rates that present estimated 'time to confirmation' giving them flexibility to choose lower fees for larger or less important transactions, without having to worry about those transactions failing to propagate.

Digital signatures in Bitcoin

2020-01-29T14:23:36Z

Wei:

The [https://bitcoinsv.io/bitcoin.pdf Bitcoin whitepaper] describes an electronic coin as a chain of digital signatures. These digital signatures confer ownership rights over the coins held in any given script, and can be used as a record of ownership to trace ownership back through the history of the ledger.

[[File:Chain_of_Signatures.png|frame|centre|alt=Electronic coins are defined as a chain of digital signatures]]

A digital signature isn't merely a message signed using a given keypair, but is a link to an identity. The European Union legislation on Digital Signatures states that signatures correspond to “data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication”.

In this way, Bitcoins can be exchanged using many different signature types.

==Elliptical Curve Digital Signature Algorithm (ECDSA) ==
[[Elliptic Curve Digital Signature Algorithm]] is the most commonly used signature type in Bitcoin. It makes use of the elliptic curve cryptography keypairs referenced in [[Address|Bitcoin addresses]] to generate secure signatures from a given message hash.

Using Bitcoin Script, it is possible to create novel scripts using ECD signatures, including the use of [[R-Puzzles]].

There have also been practical implementations of [[Threshold Signatures]] in Bitcoin wallets and libraries which extend Elliptic Curve signatures to enable multiple parties to participate in the creation of a signature created from an ephemeral private key.

==Rabin Signatures==
To counter a push for the insertion of opcodes to evaluate data from outside the Bitcoin ledger, researchers at nChain developed a method of validating [https://nchain.com/app/uploads/2018/09/Rabin-Signatures-in-Bitcoin-Cash-v2.pdf Rabin signatures] in Bitcoin script. These signatures can allow for data collected outside the BSV ledger to be evaluated and signed allowing oracle functionality within Bitcoin transactions.

Confirmation

2020-01-29T11:27:22Z

Wei:

'''Bitcoin transaction confirmation''' is needed to guarantee that a payment is finalized. One of the main advantages of bitcoin is that it solves the problem of [[Double-spending|double-spending]][https://bitcoin.org/bitcoin.pdf], i.e. the risk that a digital currency token may be copied and spent more than once. In spite of having no central authority to verify that its tokens are not being duplicated, bitcoin successfully avoids double-spending through a system of decentralized transaction confirmation, based on the [[Consensus|consensus]] of a network of validators. Bitcoin SV transaction confirmation time cannot be precisely predicted. However, once a transaction has been relayed around the network it has a high probability of being included in the next mined [[block]].

==How to confirm bitcoin transaction? ==
A transaction is a transfer of value between Bitcoin wallets that gets included in the [[blockchain]]. Bitcoin SV are not immediate but very fast. When a user wishes to send bitcoins, information is broadcast from her wallet to the (validators/miners in the) network, who verify that she has enough coins, and that they have never been spent before. Once validated, [[Mining|miners]] will include this transaction – along with others – in a new [[Block|block]] in the blockchain. This is called a '''transaction confirmation'''. The transaction is now said to be confirmed. Each time a new block is added to the chain (every ten minutes), the transaction is said to be confirmed again.

== Bitcoin SV Confirmation Time ==
To answer the question "'''How long does it take to transfer bitcoins?'''" one needs to understand that bitcoin transaction confirmation time depends on many factors. The deeper a transaction is buried, the harder it will be to manipulate. Although 0/unconfirmed transactions could be reversed via Finney attack, race attack, or [[|Attacks|51% attack]], small amounts of money will not be worth the trouble. Larger sums are worth protecting under more bitcoin confirmations. The number six is just an arbitrary limit, beyond which the feasibility of an attacker being able to amass more than 10% of the network's hashrate for purposes of a transaction falsification becomes negligible (a risk lower than 0.1%).

Having understood how transactions occur, you should find out what affects the speed of processing and verification of information. To speed up the process, you need to know that it can slow down. Usually at the final time is affected by:

* network utilization;
* commission;
* variation in network hash rate.

The influence of the first factor is only noticeable when transaction throughput capacity is close to being reached. When the system needs to process many requests, users have to wait. However, as Bitcoin SV transaction volume rarely ever reaches block or network capacity and transactions are usually validated within a few seconds. Some transactions that pay ultra-low fees (<1 [[Satoshis|satoshi]]/byte) may not be relayed by a proportion of mining nodes on the network, reducing the likelihood of confirmation within 1 [[block]]. These transactions, however are rare as Bitcoin SV default minimum-fee settings are low.

==Number of Bitcoin SV Confirmations==
A regular bitcoin sv client will show the number of confirmations as part of the transaction metadata. In some older implementations of bitcoin the transactions were labelled "unconfirmed" until they had 6 confirmations. There is nothing special about the default, often-cited figure of 6 blocks. It was chosen based on the assumption that an attacker is unlikely to amass more than 10% of the hashrate, and that a negligible risk of less than 0.1% is acceptable.
Both these figures are arbitrary, however;
6 blocks are overkill for casual attackers, and at the same time powerless against more dedicated attackers with much more than 10% hashrate (see: [https://bitcoil.co.il/Doublespend.pdf Analysis of hashrate-based double-spending]).

Users and cryptocurrency exchanges that accept bitcoins as payment set their threshold in the number of required blocks until the payment is confirmed.

To find out how many checks are required to process the transaction and how long to wait for the receipt of funds, it is necessary to understand the features of cryptocurrency transfers. This process consists of several stages:
* addressee sends money;
* information about transactions is made in special blocks, each of which has a room and a hash (special data);
* the blocks are sent for scanning to different computers;
* if everything is done correctly, the received information replenishes various databases;
* checked blocks complete the chain;
* the money goes to the recipient.

Note that

* Unconfirmed transactions do not expire.
* Freshly-mined coins cannot be spent for 100 blocks.
* It is advisable to wait some additional time for a better chance that the transaction will be propagated by all nodes.

=See Also=

* [[block|Blocks]]
* [[Bitcoin Transactions|Transaction]]
* [[Merchant API]]

=References=
[1] Nakamoto, Satoshi. "Bitcoin: A Peer-to-Peer Electronic Cash System."

[[Category:Technical]]

NLocktime and nSequence

2020-01-28T16:06:50Z

Wei:

nLocktime and nSequence are interlocks that can be applied to [[Bitcoin Transactions]].

==nSequence==
'''nSequence''' is a parameter applied to each [[Bitcoin Transactions#input|input]] of a transaction. If a transaction's nLocktime interlock is active, a transaction which has inputs where nSequence is less than UINT_MAX (0xFFFFFFFF), then the transaction cannot be accepted into a [[block]].

==nLocktime==
'''nLockTime''' is a parameter applied to each transaction specified in either unix time or block height, before which the transaction cannot be accepted into a block. If all inputs in a transaction have nSequence equal to UINT_MAX, then nLockTime is ignored.

If nLockTime < 500,000,000, the integer is interpreted as the block height after which this transaction can be accepted. Otherwise the integer is interpreted as the UNIX timestamp after which this transaction can be included in a block.

==Use in Payment Channels==
In transactions where nLockTime is set in the future, and any inputs have nSequence number fields less than 0xFFFFFFFF they are considered non-final and held in a [[Transaction Pools|transaction pool]] until either nLockTime expires or all inputs have their nSequence finalised. Non-final transactions are replaceable with transactions that include the same inputs with a higher nSequence number. This function can be used to build payment channels allowing dynamic exchange of data between parties in a peer to peer manner.

Nakamoto Consensus

2020-01-28T15:36:57Z

Wei:

Nakamoto consensus is defined in the Bitcoin whitepaper as nodes voting to enforce rules.

It is a Byzantine fault tolerant consensus algorithm that utilises the concept of Proof of Work and economic incentives.

In short, it defines an honest node to be a node that adopts the longest chain to its knowledge and build the next block that extends the longest chain. In this context, the longest chain represents greatest proof-of-work effort. If the majority of nodes are honest, then the honest chain will grow with the greatest proof of work and outrun any other competing chains.

By choosing which chain to build upon, the node has effectively voted for the rules that is implied by the chain.

Given the consensus, the proof of work in the longest chain creates an economical and technical barrier for any attacker to overcome. At the same time, the block reward as an economic incentive drives the node to follow the consensus.

The security of the consensus has been studied by academia and tested in the real world since 2009.

Nakamoto Consensus

2020-01-28T15:31:06Z

Wei:

Nakamoto consensus is defined in the Bitcoin whitepaper as nodes voting to enforce rules.

It is a Byzantine fault tolerant consensus algorithm that utilises the concept of Proof of Work and economic incentives.

In short, it defines an honest node to be a node that adopts the longest chain to its knowledge and build the next block that extends the longest chain. By choosing which chain to build upon, the node has effectively voted for the rules that is implied by the chain.

Given the consensus, the proof of work in the longest chain creates an economical and technical barrier for any attacker to overcome. At the same time, the block reward as an economic incentive drives the node to follow the consensus.

The security of the consensus has been studied by academia and tested by the reality since 2009.

Simplified Payment Verification

2020-01-28T15:01:01Z

Wei:

Simplified Payment Verification (SPV) is described in section 8 of the [[Bitcoin whitepaper]]. It allows a user to prove or verify a payment to them without downloading the full [[Block chain]], by utilising the properties of [[Simplified_Payment_Verification #Merkle_Trees.2C_Merkle_Roots.2C_Merkle_Paths_and_Merkle_Proofs|Merkle proofs]].

SPV allows users to securely transact with each other, peer-to-peer, while nodes act to form the settlement layer.

===Advantages===
The advantages of using SPV are clear in terms of the volume of data required:

* a wallet can store '''all necessary block headers in around 50MB - this covers the entire block chain''' (as of January 2020, with 80 bytes per block and around 620,000 blocks in the chain). The total '''grows linearly''' at around 4MB per year (i.e. it increases by 80 bytes with each block mined, regardless of the size of that block).

* contrast this with the '''hundreds of gigabytes''' which would be required to store the entire chain, if SPV were not being used.

* The size of the data required for the '''merkle paths''' is of maximum <math>64log_{2}{n}</math> bytes, where <math>n</math> is the total number of transaction in one block.

As explained in Section 8 of the [[Bitcoin whitepaper]]:
{{quote|1=''" ... [An SPV client] only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in ... }}

And in Section 7:
{{quote|1=''" ... A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year ..."''}}

===Approach===
There have been a lot of previous misunderstandings around SPV and peer-to-peer transacting. Previously, the custom had been for the sender of the payment to just broadcast the payment to the bitcoin network nodes. The receiver of the payment would then need to somehow filter through all of the transactions coming onto the blockchain for specific tranasactions relating to them (an extremely diffficult task in of itself). Even if the sender sent the transaction to the receiver as well as the network nodes, the custom had been for the receiver to always wait for the transaction to be burried into the blockchain at least 6 blocks deep whatever the transaction type or amount or situation.

The better approach is that transactions between SPV clients are negotiated peer-to-peer and settled on the blockchain through the network nodes. An analogy for this is a transaction done using cheque at a much faster speed. The customer hands the the signed cheque (transaction) to the merchant, who then banks or cashes the cheque (settles the transaction on chain). When/if the merchant is satisfied according to the situational risk of the transaction, then they can hand over the goods or services.

There is no such thing as absolute security, there is always a risk against the cost of being defrauded (which decreases exponentially as time goes by). If the transaction is only for a cup of coffee, then the merchant will be exposed to less risk than if the transaction is to buy a car for example, and they would behave differently. If selling a cup of coffee, they can satisfy themselves that the transaction they have received appears to be valid using the SPV process detailed above, and submit the transaction themselves to the network (or even to a trusted miner if using a [[Merchant API]]). They will not want to maintain a copy of the entire blockchain to check against, because the risk they face by no means justifies the cost. SPV is adequate. Likewise, they will not want to detain their customer while they wait for 6 confirmations - it simply is not necessary - they have received a transaction which appears to be valid, and it has been accepted by the network without a double spend alert. This will probably be enough for them to risk the cost of the coffee.

===Merkle Trees, Merkle Roots, Merkle Paths and Merkle Proofs===
A '''Merkle Tree''' is a structure used in computer science to validate data - see [https://en.wikipedia.org/wiki/Merkle_tree wikipedia definition] for more information.

The '''Merkle Root''' in a Bitcoin block is the hash contained in the [[Block_hashing_algorithm#Block_Header|block header]], which is derived from the hashes of all other transactions in the block.

A '''Merkle Path''' in SPV represents the information which the user needs to calculate the expected value for the Merkle root for a block, from their own transaction hash contained in that block. The Merkle path is used as part of of the Merkle Proof.

A '''Merkle Proof''' in SPV proves the existence of a specific transaction in a specific block (without the user needing to examine all the transactions in the Block). It includes the Merkle Root and the Merkle Path.

* To '''create''' a Merkle proof, a user or (or their wallet) simply needs the Merkle path of the transaction as well as the [[Block_hashing_algorithm#Block_Header|block header]] for a given block (80 bytes).

* To '''validate''' a proof, a user (or their wallet) only needs the chain of block headers (as opposed to the whole blockchain). I.e. they need their own copy of the [[Block_hashing_algorithm#Block_Header|block headers]] for all blocks, that they know to be accurate. Using their own block header chain, together with the transaction (or its hash/id) they want to verify, as well as its Merkle proof (also sometimes referred to as an inclusion proof), a user can verify the transaction appears in the block chain in a specific block, without examining every transaction in that block.

An article in March 2019 entitled [https://craigwright.net/blog/bitcoin-blockchain-tech/merkle-trees-and-spv Merkle Trees and SPV] (Craig Wright, 2019) clarified some previous misunderstandings around SPV and transaction verification. The article included the following diagram which shows how transaction hashes can be related to the Merkle root in a block header:

[[File: Merkle_tree2.png|frameless|1000px|alt=Three transactions and the Merkle paths which can be used to relate them to blocks]]

===SPV Wallet===
An SPV wallet is a lightweight wallet that uses the mechanism of SPV to construct bitcoin transactions and payments.

To spend a UTXO, a user of a SPV wallet will pass on the following information to the receiver:
# <math>Transaction_0</math> - the transaction that contains the UTXO as an output,
# The Merkle path of <math>Transaction_0</math>
# The block header that contains the Merkle root derived from the Merkle path (or its identifier, e.g., block height)
# <math>Transaction_1</math> - the transaction that spends the UTXO

To validate the information, a user computes the Merkle root from the Merkle path of <math>Transaction_0</math>. The user then compares it with the Merkle root specified in the block header. If they are the same, the user accepts that <math>Transaction_0</math> is in the chain.

=== Offline Payment ===
Note that by storing <math>Transaction_0</math> locally, a user will be able to sign <math>Transaction_1</math> offline, as any signature on <math>Transaction_1</math> requires the scriptPubKey (locking script) part from <math>Transaction_0</math>.

Transaction Pools

2020-01-21T10:45:03Z

Wei:

A ''transaction pool'' or ''mempool'' is a set of transactions that are unconfirmed but validated prior to inclusion in a block.

==Transaction Pools in Bitcoin SV==

A bitcoin [[Node| node]] stores bitcoin transactions that have been validated but not mined. It can be thought of as a staging area for transactions prior to their inclusion in a [[block chain|block]]. When creating a new block to mine, miners will gather transactions from their transaction pool using the rpc command ''getblocktemplate'' to construct a candidate block. Similarly, when receiving a block, a validator can speed-up the validation process if the [[TXID|transactions IDs]] match the transaction IDs in the validator's transaction pool. The transaction pool data is used extensively by block explorers, wallet servers and other Bitcoin SV related web services [https://jochen-hoenicke.de/queue/#3,24h].

==See Also==

* [[Confirmation]]

==References==

* [1] https://jochen-hoenicke.de/queue/#3,24h

Deterministic wallet

2020-01-21T10:25:02Z

Wei:

A deterministic wallet is a system of deriving keys from a single starting point known as a seed. The seed allows a user to easily back up and restore a wallet without needing any other information and can in some cases allow the creation of public addresses without the knowledge of the [[Private Keys|private key]]. Seeds are typically serialised into human-readable words in a [[Seed phrase]]. The [https://github.com/bitcoin/bips/tree/master/bip-0032 BIP 0032] standard for Hierarchical Deterministic Wallets is used by most wallets as of 2019.

== Benefits ==
Early clients such as the Satoshi client generate a buffer of fresh random private keys to be used as receiving and [[change|change addresses]] in the future. This has the effect of invalidating backups after a short period when the keypool buffer (typically 100 addresses) is exhausted. Deterministic wallets can generate an unlimited number of addresses on the fly and as such don't suffer from this issue. As the addresses are generated in a known fashion rather than randomly some clients can be used on multiple devices without the risk of losing funds. Users can conveniently create a single backup of the seed in a human readable format that will last the life of the wallet, without the worry of this backup becoming stale.

=== Master public key ===
Some deterministic wallets allow for the complete separation of private and public key creation for greater security and convenience. In this model a server can be set up to only know the Master Public Key (MPK) of a particular deterministic wallet. This allows the server to create as many public keys as is necessary for receiving funds, but a compromise of the MPK will not allow an attacker to spend from the wallet. They can alternatively be used to enable completely offline storage and spending. In this case an offline computer knows the private key and an online one knows only the MPK. Transactions spending coins are ferried between the two computers using methods such as visual transfer (QR code) or USB storage which avoids exposing the offline computer to a network-based attack.

Deterministic wallets implemented by hardware wallets keep the generated private keys offline and do not expose them to the computer even when spending coins.

==Types==

===Type 1 deterministic wallet===
A type 1 deterministic wallet is a simple method of generating addresses from a known starting string, as such it does not allow advanced features such as a Master Public Key. To generate a private key take SHA256(string + n), where n is an ASCII-coded number that starts from 1 and increments as additional keys are needed.

===Type 2 hierarchical deterministic wallet===
This wallet type is described in [https://github.com/bitcoin/bips/tree/master/bip-0032 BIP 0032] and is the most common wallet type. The seed is a random value presented to the user as a 12 or 24 word [[Seed phrase]] using common English words. The seed goes through 100,000 rounds of SHA256 before any keys are created to slow down attacks against weak user-chosen strings.

===Wallets using Diffie Hellman secret sharing===
In order to leverage the techniques showcased in [[WP0042|nCrypt whitepaper 42]], wallets must be configured to manage the handshaking and Elliptic Curve mathematics needed to support the generation of shared secrets. Currently, no wallets support this type of deterministic addressing.

== See Also ==

* [[Seed phrase]]

False Return

2020-01-21T10:13:22Z

Wei:

False Return outputs are [[VOUT|transaction outpoints]] which begin with the script "OP_FALSE OP_RETURN". This script always returns a false when evaluated making the output unspendable and locking any funds attached to that endpoint. When attempting to spend the False Return outpoint, OP_FALSE will push "false" to the stack, after which OP_RETURN is executed. OP_RETURN terminates the execution immediately. The result of the execution is then read from the top of the stack. In this case, "false" is read, therefore the script fails regardless what else is on the stack.

False Return outputs can be used to store arbitrary information such as records, tokens, files and more. False Return outputs are commonly used as vehicles to carry data for [[Application layer protocol|application layer protocols]] inside Bitcoin transactions.

==OP_RETURN Outputs==
Due to changes made by Satoshi in 2010 to prevent people exploiting a bug in the Bitcoin software, the OP_RETURN opcode was changed to force scripts to terminate in failure. This led to the widespread use of so-called 'Op_Return outputs' which start with an OP_RETURN instruction and then store data for application layer protocols. Bitcoin Core rules stipulated that to use an OP_RETURN instruction in an output, it had to be both the only opcode in the output and the first opcode in the output.
The Quasar Update in early 2019, removed these requirements meaning that transactions requiring attached data items such as tokens and other information no longer needed to be stored in these outputs.
Many second layer protocols were build using the OP_RETURN framework prior to being migrated to False Return outputs.

Bitcoin Transactions

2020-01-20T15:24:26Z

Wei:

A '''transaction''' is a serialised data item that authorises the transfer of Bitcoin value from inputs to outputs. A transaction can be ephemeral if it is created inside a Payment Channel, or it can be sent to the Bitcoin [[network|Network]] and collected into a [[block]]. A transaction typically references previous transaction outputs as new transaction inputs and dedicates all input Bitcoin values to new outputs. [[VOUT#Unspent Transaction Outputs|Unspent Transaction Outputs (UTXOs)]] are the 'coins' in which all Bitcoins are stored. Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block. Once transactions have been seen and validated by a majority of block creating nodes in the Bitcoin network, they can be considered immutable. When they are eventually mined into a block, miners collaboratively agree on the order in which they were seen by the network.

Transactions are referenced using their [[TXID]] which is a double SHA256 hash of the fully serialised transaction.

Transaction outputs are puzzle scripts called ScriptPubKeys which are typically used to lock the contained Bitcoin value. Outputs are redeemed by making them inputs to new transactions and providing a ScriptSig which is a valid solution to the puzzle that locks the Bitcoin. Some outputs may have zero Bitcoin, but carry value in another form such as data or tokens. Scripts can be complex and specialised and may have more than one way to be redeemed.

All transactions are visible in the [[block chain]], and can be viewed with a hex editor. A [[block explorer]] is a website where every transaction included within the block chain can be viewed in human-readable terms. This is useful for seeing the technical details of transactions in action and for verifying payments.

See also: [[Payment Channels]]

= General format of a Bitcoin transaction =
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Version no
|currently 1
|4 bytes
|-
|In-counter
| positive integer [[ Protocol#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of inputs
|[[Bitcoin_Transactions#General_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|Input Structure]]
|<in-counter> qty with variable length per input
|-
|Out-counter
| positive integer [[ Protocol#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of outputs
|[[Bitcoin_Transactions#General_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|Output Structure]]
|<out-counter> qty with variable length per output
|-
|nLocktime
|if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final
|4 bytes
|}

=== Example of a Bitcoin transaction with 1 input and 1 output only ===

==== Data ====

<pre>Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG</pre>

==== Explanation ====

The input in this transaction spends 50 BSV from output #0 in transaction f5d8... Then the output sends 50 BSV to a P2PKH puzzle. When the recipient wants to spend this money, he will reference output #0 of this transaction in an input of his own transaction and provide the solution to the P2PKH.

=Transaction Inputs and Outputs=

Each Bitcoin transaction is comprised of Inputs and Outputs. Inputs provide the funds to be spent in the transaction, and Outputs define where those funds should be allocated.

== Inputs ==

An '''input''' is a reference to an output from a previous transaction. Multiple inputs are often listed in a transaction. All of the new transaction's input values (that is, the total coin value of the previous outputs referenced by the new transaction's inputs) are added up, and the total (less any [[transaction_fees|transaction fee]]) is completely used by the outputs of the new transaction. '''Previous tx''' is a [[Wikipedia:Cryptographic_hash_function|hash]] of a previous transaction. '''Index''' is the specific output in the referenced transaction. '''ScriptSig''' is the first half of a [[Opcodes_used_in_Bitcoin_Script|script]] which is provided when a UTXO is spent as an input to a transaction.

An input scriptSig may contain many components. In the above example two items are needed to solve the script, being a signature and a public key. In a P2PKH script The public key must match the hash given in the script of the redeemed output. The public key is used to verify the redeemers signature, which is the second component. More precisely, the second component is an [[Digital_Signatures_(ECDSA)|ECDSA]] signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by someone who controls the keys needed to spend the Bitcoin in the input. Various [[SIGHASH flags]] define how the transaction is simplified and can be used to create different types of payment.

=== General format of each input of a transaction - Txin ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Previous Transaction hash
| doubled [[Wikipedia:SHA-256|SHA256]]-[[Wikipedia:Cryptographic_hash_function|hashed]] of a (previous) to-be-used transaction
|32 bytes
|-
|Previous Txout-index
| non negative integer indexing an output of the to-be-used transaction
|4 bytes
|-
|Txin-script length
|non negative integer [[ Protocol#Variable_length_integer|VI = VarInt]]
|1 - 9 bytes
|-
|Txin-script / scriptSig
|[[Opcodes_used_in_Bitcoin_Script|Script]]
|<in-script length>-many bytes
|-
|sequence_no
|normally 0xFFFFFFFF; irrelevant unless transaction's lock_time is > 0
|4 bytes
|}

The input sufficiently describes where and how to get the bitcoin amount to be redeemed.
If it is the (only) input of the first transaction of a block, it is called the generation transaction input and its content completely ignored. (Historically the Previous Transaction hash is 0 and the Previous Txout-index is -1.)

== Outputs ==

An '''output''' contains a piece of [[Opcodes_used_in_Bitcoin_Script|Bitcoin Script]] which can be used to lock Bitcoins to a certain set of keys and/or inscribe data onto the ledger. The '''Value''' of an output is the number of Satoshis that this output will be worth when claimed. This '''ScriptPubKey''' is the second half of a a full script and is only completed when the output is spent. There can be more than one output, and they share the combined value of the inputs. Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire value of the combined inputs needs to be allocated to the transaction outputs. Any remaining fees If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "[[change]]", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a [[transaction_fees|transaction fee]], which is awarded to whoever generates the block that the transaction is mined in.

Outputs don't necessarily contain value as Bitcoins, and can carry zero satoshis. These outputs are typically used to carry other information or tokens for second layer applications or data handling.

=== General format of each output of a transaction - Txout ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|value
|non negative integer giving the number of [[Satoshis]] to be transferred
|8 bytes
|-
|Txout-script length
|non negative integer
|1 - 9 bytes [[ Protocol#Variable_length_integer|VI = VarInt]]
|-
|Txout-script / scriptPubKey
|[[Opcodes_used_in_Bitcoin_Script|Script]]
|<out-script length>-many bytes
|}
The output sets the conditions to release this bitcoin amount later. The sum of the output values of the first transaction is the value of the mined bitcoins for the block plus possible transactions fees of the other transactions in the block.

=== Transaction Verification ===

To verify that inputs are authorized to collect the values of referenced outputs, Bitcoin uses a Forth-like [[Opcodes_used_in_Bitcoin_Script|scripting]] system. The input's scriptSig and the ''referenced'' output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by scriptSig. The input is authorized if scriptPubKey returns true. Through the scripting system, the sender can create very complex conditions that people have to meet in order to claim the output's value. For example, it's possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys, or be redeemable with a password instead of a key.

= Puzzles and Solutions =

The flexible scripting language enabled by the Bitcoin protocol allows a multitude of different transaction types to be created. Each scriptSig/scriptPubKey pair is validated by the network miners and mined into a block if found to be valid. Some commonly used Bitcoin puzzle types are described below:

== Pay to Public Key (P2PK) ==

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

When redeeming coins that have been sent to a Bitcoin public key the script verifies that the provided signature was generated by the private key that also corresponds to the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig>
| <pubKey> OP_CHECKSIG
| Signature is added to the stack.
|-
|<sig> <pubKey>
| OP_CHECKSIG
| Pubkey is added to stack.
|-
|true
|Empty.
|Signature is checked.
|}

== Pay to Public Key Hash (P2PKH) ==

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

A Bitcoin [[address]] is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

== Pay to R-Puzzle Hash (P2RPH) ==

scriptPubKey: OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

Bitcoins are locked in an R-Puzzle script requiring the spending party to sign using a known value for k rather than a random number. To redeem the script, the spending party provides both the signature and the public key. The script verifies that the provided signature was signed using the correct k-value, then checks the signature against the public key. Because the public key is not checked as part of the script solution, it is possible to sign the transaction using any keypair. This can be useful when dealing with tokens that are associated with a Bitcoin address as the pubkey that corresponds to that address can be used to sign the transaction without the requirement for there to be Bitcoin in the address. The technique is also relevant for Metanet node signing as the Metanet keys can be signed with an R-Puzzle without needing a separate signature.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <sig>
| OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| Second from top stack item is duplicated.
|-
|<sig> <pubKey> <3 bytes> <sig'>
| OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| First 3 bytes of signature are split
|-
|<sig> <pubKey> <sig'>
| OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| 3 byte data item is removed
|-
|<sig> <pubKey> <R Length> <sig">
| OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| 1 byte containing R length is split from sig'
|-
|<sig> <pubKey> <sig"> <R Length>
| OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R Length parameter is moved to top of stack
|-
|<sig> <pubKey> <R> <sig'">
| OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R is split from sig"
|-
|<sig> <pubKey> <R>
| OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| sig'"== is dropped from stack
|-
|<sig> <pubKey> <rHashA>
| <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R is double hashed (SHA256 followed by RIPEMD160) and result left on stack
|-
|<sig> <pubKey> <rHashA> <rHash>
| OP_EQUALVERIFY OP_CHECKSIG
| Previously defined R-Hash is pushed onto stack
|-
|<sig> <pubKey>
| OP_CHECKSIG
| Script checks if rHashA = rHash
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

== Pay to Multi Signature (P2MS) ==

scriptPubKey: OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
scriptSig: OP_1 <sig1> <sig2> <sig4>

OP_CHECKMULTISIG offers users the capability to lock coins with a requirement for multiple parties to sign the scriptSig before coins can be spent. OP_CHECKMULTISIG can check many signatures against many public keys as long as the signatures in the scriptSig are provided in an order that corresponds to the order in which the public keys are placed in the scriptPubKey. The first opcode in the ScriptPubKey defines how many signatures must be provided in order for the coin to be successfully spent. The last one before OP_CHECKMULTISIG tells the scripting engine how many public keys to evaluate those signatures against. There must be at least as many items on the stack as are required for the OP_CHECKMULTISIG opcode to process or the script will be invalid.

'''Note:'''
The current version of the scripting engine also includes a bug that requires an additional value to be placed on the stack before the signatures. In this example, OP_1 has been used to push a 1 to the top of the stack, but in theory any piece of data can be used. This value is consumed by the checking process but is not evaluated.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| OP_1 <sig1> <sig2> <sig4> OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
| scriptSig and scriptPubKey are combined.
|-
|1 <sig1> <sig2> <sig4>
| OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
| Constants from scriptSig are added to the stack.
|-
|1 <sig1> <sig2> <sig4> 3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5
| OP_CHECKMULTISIG
| Constants from scriptPubKey are added to the stack.
|-
|true
|Empty.
|Multisignature script evaluation is performed
|}

== Generation ==

Generations have a single input, and this input has a "[[Coinbase |coinbase]]" parameter instead of a scriptSig. The data in "coinbase" can be anything; it isn't used. Bitcoin puts the current compact-format [[target]] and the arbitrary-precision "extraNonce" number there, which increments every time the Nonce field in the [[block_hashing_algorithm|block header]] overflows. Outputs can be anything, but Bitcoin creates one exactly like an IP address transaction.
The extranonce contributes to enlarge the domain for the proof of work function. Miners can easily modify nonce (4byte), timestamp and extranonce (2 to 100bytes).

== Other Puzzle Types ==
Bitcoin's scripting language is rich and diverse and allows a user to create almost any kind of financial instrument that we have today, and many that we don't have. Puzzles do not need to conform to any particular standard or template however it is expected that the vast majority of transactions will be built using template scripts.

Pieces of script can be combined to make larger and more complex transactions, and scripts can be built inside conditional loops allowing a single transaction output to be redeemed in multiple different ways.

Prior to the Genesis upgrade, complex scripts that fell outside the 'isstandard' testing schema were required to be compressed into a transaction format called '[[P2SH|Pay to Script Hash (P2SH)]]' This format is now deprecated in favour of using the full, rich scripting language inside transactions.

=See Also=

* [[Opcodes used in Bitcoin Script]]
* [[Protocol#"tx" messages|Protocol rules - "tx" messages]]
* [[Protocol#Transaction Verification|Protocol documentation - Transaction Verification]]
* [[Raw Transactions]]
* [[Coin analogy]]
* [[Transaction Malleability]]

Bitcoin Transactions

2020-01-20T15:23:55Z

Wei:

A '''transaction''' is a serialised data item that authorises the transfer of Bitcoin value from inputs to outputs. A transaction can be ephemeral if it is created inside a Payment Channel, or it can be sent to the Bitcoin [[network|Network]] and collected into a [[block]]. A transaction typically references previous transaction outputs as new transaction inputs and dedicates all input Bitcoin values to new outputs. [[VOUT#Unspent Transaction Outputs|Unspent Transaction Outputs (UTXOs)]] are the 'coins' in which all Bitcoins are stored. Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block. Once transactions have been seen and validated by a majority of block creating nodes in the Bitcoin network, they can be considered immutable. When they are eventually mined into a block, miners collaboratively agree on the order in which they were seen by the network.

Transactions are referenced using their [[TXID]] which is a double SHA256 hash of the fully serialised transaction.

Transaction outputs are puzzle scripts called ScriptPubKeys which are typically used to lock the contained Bitcoin value. Outputs are redeemed by making them inputs to new transactions and providing a ScriptSig which is a valid solution to the puzzle that locks the Bitcoin. Some outputs may have zero Bitcoin, but carry value in another form such as data or tokens. Scripts can be complex and specialised and may have more than one way to be redeemed.

All transactions are visible in the [[block chain]], and can be viewed with a hex editor. A [[block explorer]] is a website where every transaction included within the block chain can be viewed in human-readable terms. This is useful for seeing the technical details of transactions in action and for verifying payments.

See also: [[Payment Channels]]

= General format of a Bitcoin transaction =
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Version no
|currently 1
|4 bytes
|-
|In-counter
| positive integer [[ Protocol#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of inputs
|[[Bitcoin_Transactions#General_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|Input Structure]]
|<in-counter> qty with variable length per input
|-
|Out-counter
| positive integer [[ Protocol#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of outputs
|[[Bitcoin_Transactions#General_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|Output Structure]]
|<out-counter> qty with variable length per output
|-
|nLocktime
|if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final
|4 bytes
|}

=== Example of a Bitcoin transaction with 1 input and 1 output only ===

==== Data ====

<pre>Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG</pre>

==== Explanation ====

The input in this transaction spends 50 BSV from output #0 in transaction f5d8... Then the output sends 50 BTC to a P2PKH puzzle. When the recipient wants to spend this money, he will reference output #0 of this transaction in an input of his own transaction and provide the solution to the P2PKH.

=Transaction Inputs and Outputs=

Each Bitcoin transaction is comprised of Inputs and Outputs. Inputs provide the funds to be spent in the transaction, and Outputs define where those funds should be allocated.

== Inputs ==

An '''input''' is a reference to an output from a previous transaction. Multiple inputs are often listed in a transaction. All of the new transaction's input values (that is, the total coin value of the previous outputs referenced by the new transaction's inputs) are added up, and the total (less any [[transaction_fees|transaction fee]]) is completely used by the outputs of the new transaction. '''Previous tx''' is a [[Wikipedia:Cryptographic_hash_function|hash]] of a previous transaction. '''Index''' is the specific output in the referenced transaction. '''ScriptSig''' is the first half of a [[Opcodes_used_in_Bitcoin_Script|script]] which is provided when a UTXO is spent as an input to a transaction.

An input scriptSig may contain many components. In the above example two items are needed to solve the script, being a signature and a public key. In a P2PKH script The public key must match the hash given in the script of the redeemed output. The public key is used to verify the redeemers signature, which is the second component. More precisely, the second component is an [[Digital_Signatures_(ECDSA)|ECDSA]] signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by someone who controls the keys needed to spend the Bitcoin in the input. Various [[SIGHASH flags]] define how the transaction is simplified and can be used to create different types of payment.

=== General format of each input of a transaction - Txin ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Previous Transaction hash
| doubled [[Wikipedia:SHA-256|SHA256]]-[[Wikipedia:Cryptographic_hash_function|hashed]] of a (previous) to-be-used transaction
|32 bytes
|-
|Previous Txout-index
| non negative integer indexing an output of the to-be-used transaction
|4 bytes
|-
|Txin-script length
|non negative integer [[ Protocol#Variable_length_integer|VI = VarInt]]
|1 - 9 bytes
|-
|Txin-script / scriptSig
|[[Opcodes_used_in_Bitcoin_Script|Script]]
|<in-script length>-many bytes
|-
|sequence_no
|normally 0xFFFFFFFF; irrelevant unless transaction's lock_time is > 0
|4 bytes
|}

The input sufficiently describes where and how to get the bitcoin amount to be redeemed.
If it is the (only) input of the first transaction of a block, it is called the generation transaction input and its content completely ignored. (Historically the Previous Transaction hash is 0 and the Previous Txout-index is -1.)

== Outputs ==

An '''output''' contains a piece of [[Opcodes_used_in_Bitcoin_Script|Bitcoin Script]] which can be used to lock Bitcoins to a certain set of keys and/or inscribe data onto the ledger. The '''Value''' of an output is the number of Satoshis that this output will be worth when claimed. This '''ScriptPubKey''' is the second half of a a full script and is only completed when the output is spent. There can be more than one output, and they share the combined value of the inputs. Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire value of the combined inputs needs to be allocated to the transaction outputs. Any remaining fees If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "[[change]]", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a [[transaction_fees|transaction fee]], which is awarded to whoever generates the block that the transaction is mined in.

Outputs don't necessarily contain value as Bitcoins, and can carry zero satoshis. These outputs are typically used to carry other information or tokens for second layer applications or data handling.

=== General format of each output of a transaction - Txout ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|value
|non negative integer giving the number of [[Satoshis]] to be transferred
|8 bytes
|-
|Txout-script length
|non negative integer
|1 - 9 bytes [[ Protocol#Variable_length_integer|VI = VarInt]]
|-
|Txout-script / scriptPubKey
|[[Opcodes_used_in_Bitcoin_Script|Script]]
|<out-script length>-many bytes
|}
The output sets the conditions to release this bitcoin amount later. The sum of the output values of the first transaction is the value of the mined bitcoins for the block plus possible transactions fees of the other transactions in the block.

=== Transaction Verification ===

To verify that inputs are authorized to collect the values of referenced outputs, Bitcoin uses a Forth-like [[Opcodes_used_in_Bitcoin_Script|scripting]] system. The input's scriptSig and the ''referenced'' output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by scriptSig. The input is authorized if scriptPubKey returns true. Through the scripting system, the sender can create very complex conditions that people have to meet in order to claim the output's value. For example, it's possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys, or be redeemable with a password instead of a key.

= Puzzles and Solutions =

The flexible scripting language enabled by the Bitcoin protocol allows a multitude of different transaction types to be created. Each scriptSig/scriptPubKey pair is validated by the network miners and mined into a block if found to be valid. Some commonly used Bitcoin puzzle types are described below:

== Pay to Public Key (P2PK) ==

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

When redeeming coins that have been sent to a Bitcoin public key the script verifies that the provided signature was generated by the private key that also corresponds to the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig>
| <pubKey> OP_CHECKSIG
| Signature is added to the stack.
|-
|<sig> <pubKey>
| OP_CHECKSIG
| Pubkey is added to stack.
|-
|true
|Empty.
|Signature is checked.
|}

== Pay to Public Key Hash (P2PKH) ==

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

A Bitcoin [[address]] is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

== Pay to R-Puzzle Hash (P2RPH) ==

scriptPubKey: OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

Bitcoins are locked in an R-Puzzle script requiring the spending party to sign using a known value for k rather than a random number. To redeem the script, the spending party provides both the signature and the public key. The script verifies that the provided signature was signed using the correct k-value, then checks the signature against the public key. Because the public key is not checked as part of the script solution, it is possible to sign the transaction using any keypair. This can be useful when dealing with tokens that are associated with a Bitcoin address as the pubkey that corresponds to that address can be used to sign the transaction without the requirement for there to be Bitcoin in the address. The technique is also relevant for Metanet node signing as the Metanet keys can be signed with an R-Puzzle without needing a separate signature.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <sig>
| OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| Second from top stack item is duplicated.
|-
|<sig> <pubKey> <3 bytes> <sig'>
| OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| First 3 bytes of signature are split
|-
|<sig> <pubKey> <sig'>
| OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| 3 byte data item is removed
|-
|<sig> <pubKey> <R Length> <sig">
| OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| 1 byte containing R length is split from sig'
|-
|<sig> <pubKey> <sig"> <R Length>
| OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R Length parameter is moved to top of stack
|-
|<sig> <pubKey> <R> <sig'">
| OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R is split from sig"
|-
|<sig> <pubKey> <R>
| OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| sig'"== is dropped from stack
|-
|<sig> <pubKey> <rHashA>
| <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R is double hashed (SHA256 followed by RIPEMD160) and result left on stack
|-
|<sig> <pubKey> <rHashA> <rHash>
| OP_EQUALVERIFY OP_CHECKSIG
| Previously defined R-Hash is pushed onto stack
|-
|<sig> <pubKey>
| OP_CHECKSIG
| Script checks if rHashA = rHash
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

== Pay to Multi Signature (P2MS) ==

scriptPubKey: OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
scriptSig: OP_1 <sig1> <sig2> <sig4>

OP_CHECKMULTISIG offers users the capability to lock coins with a requirement for multiple parties to sign the scriptSig before coins can be spent. OP_CHECKMULTISIG can check many signatures against many public keys as long as the signatures in the scriptSig are provided in an order that corresponds to the order in which the public keys are placed in the scriptPubKey. The first opcode in the ScriptPubKey defines how many signatures must be provided in order for the coin to be successfully spent. The last one before OP_CHECKMULTISIG tells the scripting engine how many public keys to evaluate those signatures against. There must be at least as many items on the stack as are required for the OP_CHECKMULTISIG opcode to process or the script will be invalid.

'''Note:'''
The current version of the scripting engine also includes a bug that requires an additional value to be placed on the stack before the signatures. In this example, OP_1 has been used to push a 1 to the top of the stack, but in theory any piece of data can be used. This value is consumed by the checking process but is not evaluated.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| OP_1 <sig1> <sig2> <sig4> OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
| scriptSig and scriptPubKey are combined.
|-
|1 <sig1> <sig2> <sig4>
| OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
| Constants from scriptSig are added to the stack.
|-
|1 <sig1> <sig2> <sig4> 3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5
| OP_CHECKMULTISIG
| Constants from scriptPubKey are added to the stack.
|-
|true
|Empty.
|Multisignature script evaluation is performed
|}

== Generation ==

Generations have a single input, and this input has a "[[Coinbase |coinbase]]" parameter instead of a scriptSig. The data in "coinbase" can be anything; it isn't used. Bitcoin puts the current compact-format [[target]] and the arbitrary-precision "extraNonce" number there, which increments every time the Nonce field in the [[block_hashing_algorithm|block header]] overflows. Outputs can be anything, but Bitcoin creates one exactly like an IP address transaction.
The extranonce contributes to enlarge the domain for the proof of work function. Miners can easily modify nonce (4byte), timestamp and extranonce (2 to 100bytes).

== Other Puzzle Types ==
Bitcoin's scripting language is rich and diverse and allows a user to create almost any kind of financial instrument that we have today, and many that we don't have. Puzzles do not need to conform to any particular standard or template however it is expected that the vast majority of transactions will be built using template scripts.

Pieces of script can be combined to make larger and more complex transactions, and scripts can be built inside conditional loops allowing a single transaction output to be redeemed in multiple different ways.

Prior to the Genesis upgrade, complex scripts that fell outside the 'isstandard' testing schema were required to be compressed into a transaction format called '[[P2SH|Pay to Script Hash (P2SH)]]' This format is now deprecated in favour of using the full, rich scripting language inside transactions.

=See Also=

* [[Opcodes used in Bitcoin Script]]
* [[Protocol#"tx" messages|Protocol rules - "tx" messages]]
* [[Protocol#Transaction Verification|Protocol documentation - Transaction Verification]]
* [[Raw Transactions]]
* [[Coin analogy]]
* [[Transaction Malleability]]

Bitcoin Transactions

2020-01-20T15:22:51Z

Wei:

A '''transaction''' is a serialised data item that authorises the transfer of Bitcoin value from inputs to outputs. A transaction can be ephemeral if it is created inside a Payment Channel, or it can be sent to the Bitcoin [[network|Network]] and collected into a [[block]]. A transaction typically references previous transaction outputs as new transaction inputs and dedicates all input Bitcoin values to new outputs. [[VOUT#Unspent Transaction Outputs|Unspent Transaction Outputs (UTXOs)]] are the 'coins' in which all Bitcoins are stored. Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block. Once transactions have been seen and validated by a majority of block creating nodes in the Bitcoin network, they can be considered immutable. When they are eventually mined into a block, miners collaboratively agree on the order in which they were seen by the network.

Transactions are referenced using their [[TXID]] which is a double SHA256 hash of the fully serialised transaction.

Transaction outputs are puzzle scripts called ScriptPubKeys which are typically used to lock the contained Bitcoin value. Outputs are redeemed by making them inputs to new transactions and providing a ScriptSig which is a valid solution to the puzzle that locks the Bitcoin. Some outputs may have zero Bitcoin, but carry value in another form such as data or tokens. Scripts can be complex and specialised and may have more than one way to be redeemed.

All transactions are visible in the [[block chain]], and can be viewed with a hex editor. A [[block explorer]] is a website where every transaction included within the block chain can be viewed in human-readable terms. This is useful for seeing the technical details of transactions in action and for verifying payments.

See also: [[Payment Channels]]

= General format of a Bitcoin transaction =
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Version no
|currently 1
|4 bytes
|-
|In-counter
| positive integer [[ Protocol#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of inputs
|[[Bitcoin_Transactions#General_format_.28inside_a_block.29_of_each_input_of_a_transaction_-_Txin|Input Structure]]
|<in-counter> qty with variable length per input
|-
|Out-counter
| positive integer [[ Protocol#Variable_length_integer|VI = VarInt]]
| 1 - 9 bytes
|-
|list of outputs
|[[Bitcoin_Transactions#General_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|Output Structure]]
|<out-counter> qty with variable length per output
|-
|nLocktime
|if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final
|4 bytes
|}

=== Example of a Bitcoin transaction with 1 input and 1 output only ===

==== Data ====

<pre>Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG</pre>

==== Explanation ====

The input in this transaction spends 50 BTC from output #0 in transaction f5d8... Then the output sends 50 BTC to a P2PKH puzzle. When the recipient wants to spend this money, he will reference output #0 of this transaction in an input of his own transaction and provide the solution to the P2PKH.

=Transaction Inputs and Outputs=

Each Bitcoin transaction is comprised of Inputs and Outputs. Inputs provide the funds to be spent in the transaction, and Outputs define where those funds should be allocated.

== Inputs ==

An '''input''' is a reference to an output from a previous transaction. Multiple inputs are often listed in a transaction. All of the new transaction's input values (that is, the total coin value of the previous outputs referenced by the new transaction's inputs) are added up, and the total (less any [[transaction_fees|transaction fee]]) is completely used by the outputs of the new transaction. '''Previous tx''' is a [[Wikipedia:Cryptographic_hash_function|hash]] of a previous transaction. '''Index''' is the specific output in the referenced transaction. '''ScriptSig''' is the first half of a [[Opcodes_used_in_Bitcoin_Script|script]] which is provided when a UTXO is spent as an input to a transaction.

An input scriptSig may contain many components. In the above example two items are needed to solve the script, being a signature and a public key. In a P2PKH script The public key must match the hash given in the script of the redeemed output. The public key is used to verify the redeemers signature, which is the second component. More precisely, the second component is an [[Digital_Signatures_(ECDSA)|ECDSA]] signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by someone who controls the keys needed to spend the Bitcoin in the input. Various [[SIGHASH flags]] define how the transaction is simplified and can be used to create different types of payment.

=== General format of each input of a transaction - Txin ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|Previous Transaction hash
| doubled [[Wikipedia:SHA-256|SHA256]]-[[Wikipedia:Cryptographic_hash_function|hashed]] of a (previous) to-be-used transaction
|32 bytes
|-
|Previous Txout-index
| non negative integer indexing an output of the to-be-used transaction
|4 bytes
|-
|Txin-script length
|non negative integer [[ Protocol#Variable_length_integer|VI = VarInt]]
|1 - 9 bytes
|-
|Txin-script / scriptSig
|[[Opcodes_used_in_Bitcoin_Script|Script]]
|<in-script length>-many bytes
|-
|sequence_no
|normally 0xFFFFFFFF; irrelevant unless transaction's lock_time is > 0
|4 bytes
|}

The input sufficiently describes where and how to get the bitcoin amount to be redeemed.
If it is the (only) input of the first transaction of a block, it is called the generation transaction input and its content completely ignored. (Historically the Previous Transaction hash is 0 and the Previous Txout-index is -1.)

== Outputs ==

An '''output''' contains a piece of [[Opcodes_used_in_Bitcoin_Script|Bitcoin Script]] which can be used to lock Bitcoins to a certain set of keys and/or inscribe data onto the ledger. The '''Value''' of an output is the number of Satoshis that this output will be worth when claimed. This '''ScriptPubKey''' is the second half of a a full script and is only completed when the output is spent. There can be more than one output, and they share the combined value of the inputs. Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire value of the combined inputs needs to be allocated to the transaction outputs. Any remaining fees If the input is worth 50 BTC but you only want to send 25 BTC, Bitcoin will create two outputs worth 25 BTC: one to the destination, and one back to you (known as "[[change]]", though you send it to yourself). Any input bitcoins not redeemed in an output is considered a [[transaction_fees|transaction fee]], which is awarded to whoever generates the block that the transaction is mined in.

Outputs don't necessarily contain value as Bitcoins, and can carry zero satoshis. These outputs are typically used to carry other information or tokens for second layer applications or data handling.

=== General format of each output of a transaction - Txout ===
{| class="wikitable"
|-
! Field
! Description
! Size
|-
|value
|non negative integer giving the number of [[Satoshis]] to be transferred
|8 bytes
|-
|Txout-script length
|non negative integer
|1 - 9 bytes [[ Protocol#Variable_length_integer|VI = VarInt]]
|-
|Txout-script / scriptPubKey
|[[Opcodes_used_in_Bitcoin_Script|Script]]
|<out-script length>-many bytes
|}
The output sets the conditions to release this bitcoin amount later. The sum of the output values of the first transaction is the value of the mined bitcoins for the block plus possible transactions fees of the other transactions in the block.

=== Transaction Verification ===

To verify that inputs are authorized to collect the values of referenced outputs, Bitcoin uses a Forth-like [[Opcodes_used_in_Bitcoin_Script|scripting]] system. The input's scriptSig and the ''referenced'' output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by scriptSig. The input is authorized if scriptPubKey returns true. Through the scripting system, the sender can create very complex conditions that people have to meet in order to claim the output's value. For example, it's possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys, or be redeemable with a password instead of a key.

= Puzzles and Solutions =

The flexible scripting language enabled by the Bitcoin protocol allows a multitude of different transaction types to be created. Each scriptSig/scriptPubKey pair is validated by the network miners and mined into a block if found to be valid. Some commonly used Bitcoin puzzle types are described below:

== Pay to Public Key (P2PK) ==

scriptPubKey: <pubKey> OP_CHECKSIG
scriptSig: <sig>

When redeeming coins that have been sent to a Bitcoin public key the script verifies that the provided signature was generated by the private key that also corresponds to the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig>
| <pubKey> OP_CHECKSIG
| Signature is added to the stack.
|-
|<sig> <pubKey>
| OP_CHECKSIG
| Pubkey is added to stack.
|-
|true
|Empty.
|Signature is checked.
|}

== Pay to Public Key Hash (P2PKH) ==

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

A Bitcoin [[address]] is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <pubKey>
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is duplicated.
|-
|<sig> <pubKey> <pubHashA>
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
| Top stack item is hashed.
|-
|<sig> <pubKey> <pubHashA> <pubKeyHash>
|OP_EQUALVERIFY OP_CHECKSIG
| Constant added.
|-
|<sig> <pubKey>
|OP_CHECKSIG
| Equality is checked between the top two stack items.
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

== Pay to R-Puzzle Hash (P2RPH) ==

scriptPubKey: OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

Bitcoins are locked in an R-Puzzle script requiring the spending party to sign using a known value for k rather than a random number. To redeem the script, the spending party provides both the signature and the public key. The script verifies that the provided signature was signed using the correct k-value, then checks the signature against the public key. Because the public key is not checked as part of the script solution, it is possible to sign the transaction using any keypair. This can be useful when dealing with tokens that are associated with a Bitcoin address as the pubkey that corresponds to that address can be used to sign the transaction without the requirement for there to be Bitcoin in the address. The technique is also relevant for Metanet node signing as the Metanet keys can be signed with an R-Puzzle without needing a separate signature.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| <sig> <pubKey> OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| scriptSig and scriptPubKey are combined.
|-
|<sig> <pubKey>
| OP_OVER OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| Constants are added to the stack.
|-
|<sig> <pubKey> <sig>
| OP_3 OP_SPLIT OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| Second from top stack item is duplicated.
|-
|<sig> <pubKey> <3 bytes> <sig'>
| OP_NIP OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| First 3 bytes of signature are split
|-
|<sig> <pubKey> <sig'>
| OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| 3 byte data item is removed
|-
|<sig> <pubKey> <R Length> <sig">
| OP_SWAP OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| 1 byte containing R length is split from sig'
|-
|<sig> <pubKey> <sig"> <R Length>
| OP_SPLIT OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R Length parameter is moved to top of stack
|-
|<sig> <pubKey> <R> <sig'">
| OP_DROP OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R is split from sig"
|-
|<sig> <pubKey> <R>
| OP_HASH160 <rHash> OP_EQUALVERIFY OP_CHECKSIG
| sig'"== is dropped from stack
|-
|<sig> <pubKey> <rHashA>
| <rHash> OP_EQUALVERIFY OP_CHECKSIG
| R is double hashed (SHA256 followed by RIPEMD160) and result left on stack
|-
|<sig> <pubKey> <rHashA> <rHash>
| OP_EQUALVERIFY OP_CHECKSIG
| Previously defined R-Hash is pushed onto stack
|-
|<sig> <pubKey>
| OP_CHECKSIG
| Script checks if rHashA = rHash
|-
|true
|Empty.
|Signature is checked for top two stack items.
|}

== Pay to Multi Signature (P2MS) ==

scriptPubKey: OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
scriptSig: OP_1 <sig1> <sig2> <sig4>

OP_CHECKMULTISIG offers users the capability to lock coins with a requirement for multiple parties to sign the scriptSig before coins can be spent. OP_CHECKMULTISIG can check many signatures against many public keys as long as the signatures in the scriptSig are provided in an order that corresponds to the order in which the public keys are placed in the scriptPubKey. The first opcode in the ScriptPubKey defines how many signatures must be provided in order for the coin to be successfully spent. The last one before OP_CHECKMULTISIG tells the scripting engine how many public keys to evaluate those signatures against. There must be at least as many items on the stack as are required for the OP_CHECKMULTISIG opcode to process or the script will be invalid.

'''Note:'''
The current version of the scripting engine also includes a bug that requires an additional value to be placed on the stack before the signatures. In this example, OP_1 has been used to push a 1 to the top of the stack, but in theory any piece of data can be used. This value is consumed by the checking process but is not evaluated.

Checking process:
{| class="wikitable"
|-
! Stack
! Script
! Description
|-
|Empty.
| OP_1 <sig1> <sig2> <sig4> OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
| scriptSig and scriptPubKey are combined.
|-
|1 <sig1> <sig2> <sig4>
| OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG
| Constants from scriptSig are added to the stack.
|-
|1 <sig1> <sig2> <sig4> 3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> 5
| OP_CHECKMULTISIG
| Constants from scriptPubKey are added to the stack.
|-
|true
|Empty.
|Multisignature script evaluation is performed
|}

== Generation ==

Generations have a single input, and this input has a "[[Coinbase |coinbase]]" parameter instead of a scriptSig. The data in "coinbase" can be anything; it isn't used. Bitcoin puts the current compact-format [[target]] and the arbitrary-precision "extraNonce" number there, which increments every time the Nonce field in the [[block_hashing_algorithm|block header]] overflows. Outputs can be anything, but Bitcoin creates one exactly like an IP address transaction.
The extranonce contributes to enlarge the domain for the proof of work function. Miners can easily modify nonce (4byte), timestamp and extranonce (2 to 100bytes).

== Other Puzzle Types ==
Bitcoin's scripting language is rich and diverse and allows a user to create almost any kind of financial instrument that we have today, and many that we don't have. Puzzles do not need to conform to any particular standard or template however it is expected that the vast majority of transactions will be built using template scripts.

Pieces of script can be combined to make larger and more complex transactions, and scripts can be built inside conditional loops allowing a single transaction output to be redeemed in multiple different ways.

Prior to the Genesis upgrade, complex scripts that fell outside the 'isstandard' testing schema were required to be compressed into a transaction format called '[[P2SH|Pay to Script Hash (P2SH)]]' This format is now deprecated in favour of using the full, rich scripting language inside transactions.

=See Also=

* [[Opcodes used in Bitcoin Script]]
* [[Protocol#"tx" messages|Protocol rules - "tx" messages]]
* [[Protocol#Transaction Verification|Protocol documentation - Transaction Verification]]
* [[Raw Transactions]]
* [[Coin analogy]]
* [[Transaction Malleability]]

Simplified Payment Verification

2020-01-20T14:55:14Z

Wei:

Simplified Payment Verification (SPV) is described in section 8 of the [[Bitcoin whitepaper]]. It allows a user to prove or verify that a transaction is in the chain without downloading the full chain.

To provide a proof, a user simply download the block headers and the Merkle paths of interested transactions. By showing the Merkle path of a transaction, and its corresponding Merkle root in the block header, it confirms that the transaction is in the chain at that block height.

To validate a such proof, a user only needs to download the block headers. By computing the hash of the transaction and the Merkle root, the user can compare it with the Merkle root in the block header. If it matches, then the validation is successful.

As block headers are of constant size of 80 bytes, the size of the data grows linearly, and is independent of the size of the blocks. The size of a Merkle path is of maximum <math>64log_{2}{n}</math> bytes, where <math>n</math> is the total number of transaction in one block.

[[File:Longest_proof_of_work_chain.png|frame|centre|alt=Longest proof of work chain]]

== SPV Wallet ==
SPV wallet is a lightweight wallet that uses the mechanism of SPV to construct bitcoin transactions and payments.

To spend a UTXO, a user of a SPV wallet will pass on the following information to the receiver:
# <math>Transaction_0</math> - the transaction that contains the UTXO as an output,
# The Merkle path of <math>Transaction_0</math>
# The block header that contains the Merkle root derived from the Merkle path (or its identifier, e.g., block height)
# <math>Transaction_1</math> - the transaction that spends the UTXO

To validate the information, a user computes the Merkle root from the Merkle path of <math>Transaction_0</math>. The user then compares it with the Merkle root specified in the block header. If they are the same, the user accepts that <math>Transaction_0</math> is in the chain.

=== Offline Payment ===
Note that by storing <math>Transaction_0</math> locally, a user will be able to sign <math>Transaction_1</math> offline, as any signature on <math>Transaction_1</math> requires the scriptPubKey (locking script) part from <math>Transaction_0</math>.

Simplified Payment Verification

2020-01-20T14:53:00Z

Wei:

Simplified Payment Verification (SPV) is described in section 8 of the [[Bitcoin whitepaper]]. It allows a user to prove or verify that a transaction is in the chain without downloading the full chain.

To provide a proof, a user simply download the block headers and the Merkle paths of interested transactions. By showing the Merkle path of a transaction, and its corresponding Merkle root in the block header, it confirms that the transaction is in the chain at that block height.

To validate a such proof, a user only needs to download the block headers. By computing the hash of the transaction and the Merkle root, the user can compare it with the Merkle root in the block header. If it matches, then the validation is successful.

As block headers are of constant size of 80 bytes, the size of the data grows linearly, and is independent of the size of the blocks. The size of a Merkle path is of maximum <math>32 * 2 * log_{2}{n}</math> bytes, where <math>n</math> is the total number of transaction in one block.

[[File:Longest_proof_of_work_chain.png|frame|centre|alt=Longest proof of work chain]]

== SPV Wallet ==
SPV wallet is a lightweight wallet that uses the mechanism of SPV to construct bitcoin transactions and payments.

To spend a UTXO, a user of a SPV wallet will pass on the following information to the receiver:
# <math>Transaction_0</math> - the transaction that contains the UTXO as an output,
# The Merkle path of <math>Transaction_0</math>
# The block header that contains the Merkle root derived from the Merkle path (or its identifier, e.g., block height)
# <math>Transaction_1</math> - the transaction that spends the UTXO

To validate the information, a user computes the Merkle root from the Merkle path of <math>Transaction_0</math>. The user then compares it with the Merkle root specified in the block header. If they are the same, the user accepts that <math>Transaction_0</math> is in the chain.

=== Offline Payment ===
Note that by storing <math>Transaction_0</math> locally, a user will be able to sign <math>Transaction_1</math> offline, as any signature on <math>Transaction_1</math> requires the scriptPubKey (locking script) part from <math>Transaction_0</math>.

Simplified Payment Verification

2020-01-20T14:46:23Z

Wei:

Simplified Payment Verification

2020-01-20T14:36:46Z

Wei:

Simplified Payment Verification (SPV) is described in section 8 of the [[Bitcoin whitepaper]]. It allows a user to prove or verify that a transaction is in the chain without downloading the full chain.

To provide a proof, a user simply download the block headers and the Merkle paths of interested transactions. By showing the Merkle path of a transaction, and its corresponding Merkle root in the block header, it confirms that the transaction is in the chain at that block height.

To validate a such proof, a user only needs to download the block headers. By computing the hash of the transaction and the Merkle root, the user can compare it with the Merkle root in the block header. If it matches, then the validation is successful.

As block headers are of constant size of 80 bytes, the size of the data grows linearly, and is independent of the size of the blocks. The size of a Merkle path is of maximum <math>32 * 2 * log_{2}{n}</math> bytes, where <math>n</math> is the total number of transaction in one block.

and describes a means by which a user can receive a proof of confirmation for any [[UTXO]] on the network. This proof consists of a Merkle path that links the transaction to the Merkle root of a block in the longest proof of work chain. By linking the transaction to a place in the chain, it can be confirmed as a valid Bitcoin transaction that the network has built upon.

[[File:Longest_proof_of_work_chain.png|frame|centre|alt=Longest proof of work chain]]

Using this technique, it becomes possible to build a Bitcoin wallet or utility that does not need to witness or verify everything taking place on the network, but which can instead receive block headers from the network and validate the Merkle branch of any coin being received against the block's proof of work.

In Simplified Payment Verification, clients connect to Bitcoin nodes and download only the block headers in the longest proof of work chain. This data grows linearly over time at a rate of around 4.2MB per year. From this data, they can easily and quickly verify the chain headers connect together correctly and that the difficulty is correct. Using typical connection methods, clients then request transactions matching particular patterns from the network (ie, payments with known addresses in their redeem scripts), and receive copies of those transactions along with a Merkle branch linking them to the block in which they were mined. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block.

Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.

OP CHECKSIG

2020-01-20T12:43:25Z

Wei:

'''OP_CHECKSIG''' is an opcode that verifies an [[Digital Signatures (ECDSA) | ECDSA signature]]. It takes two inputs from the stack, a public key (on top of the stack) and an ECDSA signature in its DER_CANONISED format concatenated with sighash flags. It outputs true or false on the stack based on whether the signature check passes or fails.

== Parameters ==

In addition to the stack parameters, OP_CHECKSIG needs to have
# the current transaction <math>TX_{current}</math>,
# the index of the transaction input in which the signature is checked <math>i</math>,
# the scriptPubKey in which this OP_CHECKSIG belongs <math>previousScriptPubKey</math>, and
# the value in satoshi that the outpoint represents <math>amount</math>.

Note that <math>previousScriptPubKey</math> is from previous transaction, in which the output is spent in current transaction.

== How it works ==
In short, OP_CHECKSIG calls a function called "sighash" which produces a hash value of the serialised transaction. The hash value is the message on which the signature is verified. The signature and the public key involved in the verification are obtained from the stack.

In detail,

# Check the stack size is not less than 2.
# the public key and the signature are popped as the top 2 items of the stack.
# Check the signature encoding is of the correct format [<DER signature><hashtype>]. An example: 47304402205a2b556c71ee1c12d8e0b460c3446aeca0e3ee71b7bc11c6ddd3da8beeec99c60220783a1f0c0158674df8904022ec30fab5154c4fc4c7e8467086f0204cc8e16cbb01, where 47 indicates number of bytes in hex (71 in decimal) of the signature including 1 byte of sighash flag at the end, the next 46 bytes (70 in decimal) are the ECDSA signature (r,s), the last byte is the sighash flag "ALL".
# Check the public key encoding is of the correct format. Both compressed public key and uncompressed public key can be acceptable. An example: 210220798b9772a8ae06d13027e6f501d09ea07f6dfc4b7afc3db3a6d6c57bf24239, where 21 indicates the number of bytes in hex of the public key, 02 indicates this is a compressed public and the y-coordinate is an even number, the rest is the value of the x-coordinate of the public key. Note that if the second byte is 04, then it indicates that the public key is given in its uncompressed form.
# A new subScript is created from the <math>previousScriptPubKey</math>. The subScript starts from the most recent OP_CODESEPARATOR (the one just before the OP_CHECKSIG that is executed here) to the end of the <math>previousScriptPubKey</math>. If there is no OP_CODESEPARATOR, the entire <math>previousScriptPubKey</math> becomes the subScript.
# Any remaining OP_CODESEPARATORS are removed from the subScript.
# A serialisation algorithm is called to produce an input to double SHA256 depending on sighash type:
## nVersion in <math>TX_{current}</math> (4-byte little endian)
## double SHA256 of the serialisation of all input outpoints (32-byte hash)
### if ANYONECANPAY flag is set, then this should be a 32-byte zero.
## double SHA256 of the serialisation of nSequence of all inputs (32-byte hash)
### if ANYONECANPAY flag is set, then this should be a 32-byte zero.
## the outpoint being spent (32-byte for transaction ID + 4-byte little endian for index)
## length in bytes of the subScript (big endian)
## the subScript
## <math>amount</math> (8-byte little endia)
## nSequence of this outpoint (4-byte little endian)
## double SHA256 of the serialization of all output amount (8-byte little endian) with scriptPubKey (These are the outputs in <math>TX_{current}</math>.)
### If SINGLE flag is set and the input index is smaller than the number of outputs, then this should be the double SHA256 of the output with scriptPubKey of the same index as the input
### If NONE flag is set, then this should be a 32-byte zero.
## nLocktime of the transaction <math>TX_{current}</math> (4-byte little endian)
## sighash type of the signature (4-byte little endian)
# The serialisation in bytes from the step above will be fed to double SHA256 to produce the 32-byte message. This message is used to check the ECDSA signature, together with the public key and the signature obtained from the stack. Note that the [[secp256k1]] elliptic curve is used for the verification with the given public key.

== Return values ==

OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
OP_CHECKSIGVERIFY leaves nothing on the stack but will cause the script validation to fail immediately if the check does not pass.

==References==
https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/interpreter.cpp

See [[SIGHASH flags]] for more detail on the effect of combinations of flags.

OP CHECKSIG

2020-01-20T10:53:49Z

Wei:

'''OP_CHECKSIG''' is an opcode that verifies an [[Digital Signatures (ECDSA) | ECDSA signature]]. It takes two inputs from the stack, a public key (on top of the stack) and an ECDSA signature in its DER_CANONISED format concatenated with sighash flags. It outputs true or false on the stack based on whether the signature check passes or fails.

== Parameters ==

In addition to the stack parameters, OP_CHECKSIG needs to have
# the current transaction <math>TX_{current}</math>,
# the index of the transaction input in which the signature is checked <math>i</math>,
# the scriptPubKey in which this OP_CHECKSIG belongs <math>previousScriptPubKey</math>, and
# the value in satoshi that the outpoint represents <math>amount</math>.

Note that <math>previousScriptPubKey</math> is from previous transaction, in which the output is spent in current transaction.

== How it works ==
In short, OP_CHECKSIG calls a function called "sighash" which produces a hash value of the serialised transaction. The hash value is the message on which the signature is verified. The signature and the public key involved in the verification are obtained from the stack.

In detail,

# Check the stack size is not less than 2.
# the public key and the signature are popped as the top 2 items of the stack.
# Check the signature encoding is of the correct format [<DER signature><hashtype>]. An example to be given here.
# Check the public key encoding is of the correct format. Both compressed public key and uncompressed public key can be acceptable. Two examples to be given here.
# A new subScript is created from the <math>previousScriptPubKey</math>. The subScript starts from the most recent OP_CODESEPARATOR (the one just before the OP_CHECKSIG that is executed here) to the end of the <math>previousScriptPubKey</math>. If there is no OP_CODESEPARATOR, the entire <math>previousScriptPubKey</math> becomes the subScript.
# Any remaining OP_CODESEPARATORS are removed from the subScript.
# A serialisation algorithm is called to produce an input to double SHA256 depending on sighash type:
## nVersion in <math>TX_{current}</math> (4-byte little endian)
## double SHA256 of the serialisation of all input outpoints (32-byte hash)
### if ANYONECANPAY flag is set, then this should be a 32-byte zero.
## double SHA256 of the serialisation of nSequence of all inputs (32-byte hash)
### if ANYONECANPAY flag is set, then this should be a 32-byte zero.
## the outpoint being spent (32-byte for transaction ID + 4-byte little endian for index)
## length in bytes of the subScript (big endian)
## the subScript
## <math>amount</math> (8-byte little endia)
## nSequence of this outpoint (4-byte little endian)
## double SHA256 of the serialization of all output amount (8-byte little endian) with scriptPubKey (These are the outputs in <math>TX_{current}</math>.)
### If SINGLE flag is set and the input index is smaller than the number of outputs, then this should be the double SHA256 of the output with scriptPubKey of the same index as the input
### If NONE flag is set, then this should be a 32-byte zero.
## nLocktime of the transaction <math>TX_{current}</math> (4-byte little endian)
## sighash type of the signature (4-byte little endian)
# The serialisation in bytes from the step above will be fed to double SHA256 to produce the 32-byte message. This message is used to check the ECDSA signature, together with the public key and the signature obtained from the stack. Note that the [[secp256k1]] elliptic curve is used for the verification with the given public key.

== Return values ==

OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
OP_CHECKSIGVERIFY leaves nothing on the stack but will cause the script validation to fail immediately if the check does not pass.

==References==
https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/interpreter.cpp

See [[SIGHASH flags]] for more detail on the effect of combinations of flags.

OP CHECKSIG

2020-01-15T17:35:36Z

Wei:

'''OP_CHECKSIG''' is an opcode that verifies an [[Digital Signatures (ECDSA) | ECDSA signature]]. It takes two inputs from the stack, a public key (on top of the stack) and an ECDSA signature in its DER_CANONISED format concatenated with sighash flags. It outputs true or false on the stack based on whether the signature check passes or fails.

== Parameters ==

In addition to the stack parameters, OP_CHECKSIG needs to have
# the current transaction <math>TX_{current}</math>,
# the index of the transaction input in which the signature is checked <math>i</math>,
# the scriptPubKey in which this OP_CHECKSIG belongs <math>previousScriptPubKey</math>, and
# the value in satoshi that the outpoint represents <math>amount</math>.

Note that <math>previousScriptPubKey</math> is from previous transaction, in which the output is spent in current transaction.

== How it works ==
In short, OP_CHECKSIG calls a function called "sighash" which produces a hash value of the serialised transaction. The hash value is the message on which the signature is verified. The signature and the public key involved in the verification are obtained from the stack.

In detail,

# Check the stack size is not less than 2.
# the public key and the signature are popped as the top 2 items of the stack.
# Check the signature encoding is of the correct format [<DER signature><hashtype>]. An example to be given here.
# Check the public key encoding is of the correct format. Both compressed public key and uncompressed public key can be acceptable. Two examples to be given here.
# A new subScript is created from the <math>previousScriptPubKey</math>. The subScript starts from the most recent OP_CODESEPARATOR (the one just before the OP_CHECKSIG that is executed here) to the end of the <math>previousScriptPubKey</math>. If there is no OP_CODESEPARATOR, the entire <math>previousScriptPubKey</math> becomes the subScript.
# Any remaining OP_CODESEPARATORS are removed from the subScript.
# A serialisation algorithm is called to produce an input to double SHA256 depending on sighash type. We will describe the SIGHASH_ALL case first:
## nVersion in <math>TX_{current}</math> (4-byte little endian)
## double SHA256 of the serialisation of all input outpoints (32-byte hash)
*** if ANYONECANPAY flag is set, than this should be a 32-byte zero.
## double SHA256 of the serialisation of nSequence of all inputs (32-byte hash)
## the outpoint being spent (32-byte + 4-byte little endian)
## length in bytes of the subScript (big endian)
## the subScript
## <math>amount</math> (8-byte little endia)
## nSequence of this outpoint (4-byte little endian)
## double SHA256 of the serialization of all output amount (8-byte little endian) with scriptPubKey (These are the outputs in <math>TX_{current}</math>.)
## nLocktime of the transaction <math>TX_{current}</math> (4-byte little endian)
## sighash type of the signature (4-byte little endian)

A function called SIGHASH
Now depending on the hashtype various things can happen to txCopy, these will be discussed individually. See [[SIGHASH flags]] for more detail.

====SIGHASH_ALL====
This SIGHASH flag indicates that the signature will sign all the inputs and all the outputs.

===Final signature check===

An array of bytes is constructed from the serialized txCopy appended by four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to check the supplied signature against the hash.
The secp256k1 elliptic curve is used for the verification with the given public key.

== Return values ==

OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
OP_CHECKSIGVERIFY leaves nothing on the stack but will cause the script eval to fail immediately if the check does not pass.

==References==
https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/interpreter.cpp

OP CHECKSIG

2020-01-15T17:33:46Z

Wei:

'''OP_CHECKSIG''' is an opcode that verifies an [[Digital Signatures (ECDSA) | ECDSA signature]]. It takes two inputs from the stack, a public key (on top of the stack) and an ECDSA signature in its DER_CANONISED format concatenated with sighash flags. It outputs true or false on the stack based on whether the signature check passes or fails.

== Parameters ==

In addition to the stack parameters, OP_CHECKSIG needs to have
# the current transaction <math>TX_{current}</math>,
# the index of the transaction input in which the signature is checked <math>i</math>,
# the scriptPubKey in which this OP_CHECKSIG belongs <math>previousScriptPubKey</math>, and
# the value in satoshi that the outpoint represents <math>amount</math>.

Note that <math>previousScriptPubKey</math> is from previous transaction, in which the output is spent in current transaction.

== How it works ==
In short, OP_CHECKSIG calls a function called "sighash" which produces a hash value of the serialised transaction. The hash value is the message on which the signature is verified. The signature and the public key involved in the verification are obtained from the stack.

In detail,

# Check the stack size is not less than 2.
# the public key and the signature are popped as the top 2 items of the stack.
# Check the signature encoding is of the correct format [<DER signature><hashtype>]. An example to be given here.
# Check the public key encoding is of the correct format. Both compressed public key and uncompressed public key can be acceptable. Two examples to be given here.
# A new subScript is created from the <math>previousScriptPubKey</math>. The subScript starts from the most recent OP_CODESEPARATOR (the one just before the OP_CHECKSIG that is executed here) to the end of the <math>previousScriptPubKey</math>. If there is no OP_CODESEPARATOR, the entire <math>previousScriptPubKey</math> becomes the subScript.
# Any remaining OP_CODESEPARATORS are removed from the subScript.
# A serialisation algorithm is called to produce an input to double SHA256 depending on sighash type. We will describe the SIGHASH_ALL case first:
## nVersion in <math>TX_{current}</math> (4-byte little endian)
## double SHA256 of the serialisation of all input outpoints (32-byte hash)
### if ANYONECANPAY flag is set, than this should be a 32-byte zero.
## double SHA256 of the serialisation of nSequence of all inputs (32-byte hash)
## the outpoint being spent (32-byte + 4-byte little endian)
## length in bytes of the subScript (big endian)
## the subScript
## <math>amount</math> (8-byte little endia)
## nSequence of this outpoint (4-byte little endian)
## double SHA256 of the serialization of all output amount (8-byte little endian) with scriptPubKey (These are the outputs in <math>TX_{current}</math>.)
## nLocktime of the transaction <math>TX_{current}</math> (4-byte little endian)
## sighash type of the signature (4-byte little endian)

A function called SIGHASH
Now depending on the hashtype various things can happen to txCopy, these will be discussed individually. See [[SIGHASH flags]] for more detail.

====SIGHASH_ALL====
This SIGHASH flag indicates that the signature will sign all the inputs and all the outputs.

===Final signature check===

An array of bytes is constructed from the serialized txCopy appended by four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to check the supplied signature against the hash.
The secp256k1 elliptic curve is used for the verification with the given public key.

== Return values ==

OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
OP_CHECKSIGVERIFY leaves nothing on the stack but will cause the script eval to fail immediately if the check does not pass.

==References==
https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/interpreter.cpp

OP CHECKSIG

2020-01-15T17:33:28Z

Wei:

'''OP_CHECKSIG''' is an opcode that verifies an [[Digital Signatures (ECDSA) | ECDSA signature]]. It takes two inputs from the stack, a public key (on top of the stack) and an ECDSA signature in its DER_CANONISED format concatenated with sighash flags. It outputs true or false on the stack based on whether the signature check passes or fails.

== Parameters ==

In addition to the stack parameters, OP_CHECKSIG needs to have
# the current transaction <math>TX_{current}</math>,
# the index of the transaction input in which the signature is checked <math>i</math>,
# the scriptPubKey in which this OP_CHECKSIG belongs <math>previousScriptPubKey</math>, and
# the value in satoshi that the outpoint represents <math>amount</math>.

Note that <math>previousScriptPubKey</math> is from previous transaction, in which the output is spent in current transaction.

== How it works ==
In short, OP_CHECKSIG calls a function called "sighash" which produces a hash value of the serialised transaction. The hash value is the message on which the signature is verified. The signature and the public key involved in the verification are obtained from the stack.

In detail,

# Check the stack size is not less than 2.
# the public key and the signature are popped as the top 2 items of the stack.
# Check the signature encoding is of the correct format [<DER signature><hashtype>]. An example to be given here.
# Check the public key encoding is of the correct format. Both compressed public key and uncompressed public key can be acceptable. Two examples to be given here.
# A new subScript is created from the <math>previousScriptPubKey</math>. The subScript starts from the most recent OP_CODESEPARATOR (the one just before the OP_CHECKSIG that is executed here) to the end of the <math>previousScriptPubKey</math>. If there is no OP_CODESEPARATOR, the entire <math>previousScriptPubKey</math> becomes the subScript.
# Any remaining OP_CODESEPARATORS are removed from the subScript.
# A serialisation algorithm is called to produce an input to double SHA256 depending on sighash type. We will describe the SIGHASH_ALL case first:
## nVersion in <math>TX_{current}</math> (4-byte little endian)
## double SHA256 of the serialisation of all input outpoints (32-byte hash)
#### if ANYONECANPAY flag is set, than this should be a 32-byte zero.
## double SHA256 of the serialisation of nSequence of all inputs (32-byte hash)
## the outpoint being spent (32-byte + 4-byte little endian)
## length in bytes of the subScript (big endian)
## the subScript
## <math>amount</math> (8-byte little endia)
## nSequence of this outpoint (4-byte little endian)
## double SHA256 of the serialization of all output amount (8-byte little endian) with scriptPubKey (These are the outputs in <math>TX_{current}</math>.)
## nLocktime of the transaction <math>TX_{current}</math> (4-byte little endian)
## sighash type of the signature (4-byte little endian)

A function called SIGHASH
Now depending on the hashtype various things can happen to txCopy, these will be discussed individually. See [[SIGHASH flags]] for more detail.

====SIGHASH_ALL====
This SIGHASH flag indicates that the signature will sign all the inputs and all the outputs.

===Final signature check===

An array of bytes is constructed from the serialized txCopy appended by four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to check the supplied signature against the hash.
The secp256k1 elliptic curve is used for the verification with the given public key.

== Return values ==

OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
OP_CHECKSIGVERIFY leaves nothing on the stack but will cause the script eval to fail immediately if the check does not pass.

==References==
https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/interpreter.cpp

OP CHECKSIG

2020-01-15T17:25:52Z

Wei:

'''OP_CHECKSIG''' is an opcode that verifies an [[Digital Signatures (ECDSA) | ECDSA signature]]. It takes two inputs from the stack, a public key (on top of the stack) and an ECDSA signature in its DER_CANONISED format concatenated with sighash flags. It outputs true or false on the stack based on whether the signature check passes or fails.

== Parameters ==

In addition to the stack parameters, OP_CHECKSIG needs to have
# the current transaction <math>TX_{current}</math>,
# the index of the transaction input in which the signature is checked <math>i</math>,
# the scriptPubKey in which this OP_CHECKSIG belongs <math>previousScriptPubKey</math>, and
# the value in satoshi that the outpoint represents <math>amount</math>.

Note that <math>previousScriptPubKey</math> is from previous transaction, in which the output is spent in current transaction.

== How it works ==
In short, OP_CHECKSIG calls a function called "sighash" which produces a hash value of the serialised transaction. The hash value is the message on which the signature is verified. The signature and the public key involved in the verification are obtained from the stack.

In detail,

# Check the stack size is not less than 2.
# the public key and the signature are popped as the top 2 items of the stack.
# Check the signature encoding is of the correct format [<DER signature><hashtype>]. An example to be given here.
# Check the public key encoding is of the correct format. Both compressed public key and uncompressed public key can be acceptable. Two examples to be given here.
# A new subScript is created from the <math>previousScriptPubKey</math>. The subScript starts from the most recent OP_CODESEPARATOR (the one just before the OP_CHECKSIG that is executed here) to the end of the <math>previousScriptPubKey</math>. If there is no OP_CODESEPARATOR, the entire <math>previousScriptPubKey</math> becomes the subScript.
# Any remaining OP_CODESEPARATORS are removed from the subScript.
# A serialisation algorithm is called to produce an input to double SHA256:
## nVersion in <math>TX_{current}</math> (4-byte little endian)
## double SHA256 of the serialisation of all input outpoints (32-byte hash)
## double SHA256 of the serialisation of nSequence of all inputs (32-byte hash)
## the outpoint being spent (32-byte + 4-byte little endian)
## length in bytes of the subScript (big endian)
## the subScript
## <math>amount</math> (8-byte little endia)
## nSequence of this outpoint (4-byte little endian)
## double SHA256 of the serialization of all output amount (8-byte little endian) with scriptPubKey (These are the outputs in <math>TX_{current}</math>.)
## nLocktime of the transaction <math>TX_{current}</math> (4-byte little endian)
## sighash type of the signature (4-byte little endian)

A function called SIGHASH
Now depending on the hashtype various things can happen to txCopy, these will be discussed individually. See [[SIGHASH flags]] for more detail.

====SIGHASH_ALL====
This SIGHASH flag indicates that the signature will sign all the inputs and all the outputs.

===Final signature check===

An array of bytes is constructed from the serialized txCopy appended by four bytes for the hash type. This array is sha256 hashed twice, then the public key is used to check the supplied signature against the hash.
The secp256k1 elliptic curve is used for the verification with the given public key.

== Return values ==

OP_CHECKSIG will push true to the stack if the check passed, false otherwise.
OP_CHECKSIGVERIFY leaves nothing on the stack but will cause the script eval to fail immediately if the check does not pass.

==References==
https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/interpreter.cpp

OP CHECKSIG

2020-01-15T17:16:49Z

Wei:

SIGHASH flags

2019-11-21T15:57:03Z

Wei:

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 in a transaction.

{| class="wikitable"
|-
! 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 <nowiki>|</nowiki> ANYONECANPAY
| 0x00000081
| Sign its own input and all outputs
|-
| SIGHASH_NONE <nowiki>|</nowiki> ANYONECANPAY
| 0x00000082
| Sign its own input and no output
|-
| SIGHASH_SINGLE <nowiki>|</nowiki> ANYONECANPAY
| 0x00000083
| Sign its own input and the output with the same index
|}

The table below illustrates what is signed and what is not signed in a more granulated detail by an ECDSA siganture in the Input 1 in a transaction.

{| class="wikitable"
|-
|
| ALL
| NONE
| SINGLE
| ALL <nowiki>|</nowiki> ANYONECANPAY
| NONE <nowiki>|</nowiki> ANYONECANPAY
| SINGLE <nowiki>|</nowiki> ANYONECANPAY
|-
| Version
| Yes
| Yes
| Yes
| Yes
| Yes
| Yes
|-
| Locktime
| Yes
| Yes
| Yes
| Yes
| Yes
| Yes
|-
| Input 1 outpoint
| Yes
| Yes
| Yes
| Yes
| Yes
| Yes
|-
| Input 1 scriptSig
| No
| No
| No
| No
| No
| No
|-
| Input 1 sequence number
| Yes
| Yes
| Yes
| Yes
| Yes
| Yes
|-
| Input 2 outpoint
| Yes
| Yes
| Yes
| No
| No
| No
|-
| Input 2 scriptSig
| No
| No
| No
| No
| No
| No
|-
| Input 2 sequence number
| Yes
| Yes
| Yes
| No
| No
| No
|-
| Output 1
| Yes
| No
| Yes
| Yes
| No
| Yes
|-
| Output 2
| Yes
| No
| No
| Yes
| No
| No
|}

Note that the version number and locktime are always signed, and the scriptSigs are never signed.

SIGHASH flags are handy when constructing smart contracts and negotiable transactions in payment channels.

Use Case 1 - Crowdfunding

Using ALL <nowiki>|</nowiki> ANYONECANPAY allows a transaction to have a fixed output or fixed outputs while keep the input list open. That is, anyone can add their input with their signature to the transaction without invalidating all existing signatures.

Use Case 2 - Blank Check

Using NONE allows any miner to add their desired outputs to the transaction to claim the fund in the input.

Use Case 3 - Modular Transaction

Using SINGLE <nowiki>|</nowiki> ANYONECANPAY modularises a transaction. Any number of these transactions can be combined into one transaction.

==References==
https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/script/sighashtype.h