Bitcoin Wiki - User contributions [en]

Scripts with Flow Control (Conditional Clauses)

2020-02-19T11:08:20Z

Steve:

Conditional clauses are implemented in Bitcoin script using IF/NOTIF statements. There are several varieties of these clauses that can be used to build if statements in Bitcoin.
Conditional clauses use the third stack in the Script validation engine to manage nested conditions making sure that OP_ELSE or OP_ENDIF statements which are nested inside OP_ELSE conditional outcomes do not terminate the parent loop.

==OP_IF, OP_NOTIF==
OP_IF will execute the set of subsequent opcodes up-to the following OP_ELSE or OP_ENDIF if the value on top of the stack is True, or NON-ZERO.
Similarly, OP_NOTIF will execute the set of subsequent opcodes up-to the following OP_ELSE or OP_ENDIF if the value on top of the stack is FALSE, or ZERO.
If an OP_ELSE is the subsequent conditional clause and the first conditional clause was successful, the script will jump forward to the OP_ENDIF at the conditional-stack height of the original clause. the script will jump to the subsequent opcode following the else on a failure of the conditional entry.
The loop concludes after an OP_ENDIF is processed.

==OP_VERIF, OP_VERNOTIF==
'''NOTE: OP_VERIF and OP_VERNOTIF are currently disabled in the BitcoinSV mining client and transactions that use them in executed script will fail'''

OP_VERIF will execute the set of subsequent opcodes up-to the following OP_ELSE or OP_ENDIF if the value on top of the stack matches the protocol VERSION. Some, or all network nodes may refuse to evaluate certain protocol versions meaning transactions using these parameters must be careful.
Similarly, OP_VERNOTIF will execute the set of subsequent opcodes up-to the following OP_ELSE or OP_ENDIF if the value on top of the stack does not match the protocol VERSION indicated in the transaction serialisation string.
Similarly to OP_IF/OP_NOTIF, ifan OP_ELSE is the subsequent conditional clause and the first conditional clause was successful, the script will jump forward to the OP_ENDIF at the conditional-stack height of the original clause. the script will jump to the subsequent opcode following the else on a failure of the conditional entry.
The loop concludes after an OP_ENDIF is processed.

==Example 1==
The following example uses IF, ELSE and ENDIF statements to manage four possible ScriptSigs which can unlock this output.

ScriptSig1: <sig1> <pk1> 1
ScriptSig2: <sig2> <pk2> 2
ScriptSig3: <sig3> <pk3> 3
ScriptSig4: <sigRP> <pkRP>

The first three are PKH signatures with a numeric signal to show which conditional loop to enter for evaluation. Depending on which numeric signal is present, the script will enter the relevant height conditional clause. Each subsequent conditional IF statement is nested inside the else statement of the preceding level. If no numeric signal is present, the script goes into the third level else statement where the ScriptSig is tested against an R-Puzzle Hash and the script exits the loops.

DUP 1 EQUAL IF
DROP DUP HASH160 <PKH1> EQUALVERIFY CHECKSIG
ELSE
DUP 2 EQUAL IF
DROP DUP HASH160 <PKH2> EQUALVERIFY CHECKSIG
ELSE
DUP 3 EQUAL IF
DROP DUP HASH160 <PKH3> EQUALVERIFY CHECKSIG
ELSE
OVER 3 SPLIT SWAP DROP 1 SPLIT SWAP SPLIT DROP HASH160 <RPH> EQUALVERIFY CHECKSIG
ENDIF
ENDIF
ENDIF

==Example 2==
In this example, three possible ScriptSigs are accomodated. The entry to the conditional clauses is based on the depth of the stack subsequent to the processing of the ScriptSig.

ScriptSig1: <SIG> <PK>
ScriptSig2: 1 <SIG1> <SIG3> <SIG4>
ScriptSig3: <PASSWORD> <SIG6> <PK6>

Either of the first two ScriptSigs are evaluated in their own separate IF loops which exit using RETURN statements. If the ScriptSig has a stack depth that doesn't match either of the requirements, it passes through to a final evaluation which must have a different signature and a backup password.

DEPTH 2 EQUAL IF
DUP HASH160 EQUALVERIFY CHECKSIG RETURN
ENDIF
DEPTH 4 EQUAL IF
<PK1> <PK2> <PK3> <PK4> <PK5> 5 CHECKMULTISIG RETURN
ENDIF
DUP HASH160 <PKH6> EQUALVERIFY CHECKSIGVERIFY SHA256 <PASSWORDHASH> EQUAL RETURN

Opcodes used in Bitcoin Script

2020-02-19T11:06:45Z

Steve:

This is a list of all Script words, also known as opcodes, commands, or functions.

OP_NOP1-OP_NOP10 were originally set aside to be used when HASH and other security functions become insecure due to improvements in computing.

False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.

=== Constants ===
When talking about scripts, these value-pushing words are usually omitted.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_0, OP_FALSE
|0
|0x00
|Nothing.
|(empty value)
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
|-
|[[Pushdata Opcodes|Pushdata Bytelength]]
|1-75
|0x01-0x4b
|(special)
|data
|The next ''opcode'' bytes is data to be pushed onto the stack
|-
|[[Pushdata Opcodes|OP_PUSHDATA1]]
|76
|0x4c
|(special)
|data
|The next byte contains the number of bytes to be pushed onto the stack.
|-
|[[Pushdata Opcodes|OP_PUSHDATA2]]
|77
|0x4d
|(special)
|data
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|[[Pushdata Opcodes|OP_PUSHDATA4]]
|78
|0x4e
|(special)
|data
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|OP_1NEGATE
|79
|0x4f
|Nothing.
| -1
|The number -1 is pushed onto the stack.
|-
|OP_1, OP_TRUE
|81
|0x51
|Nothing.
|1
|The number 1 is pushed onto the stack.
|-
|OP_2-OP_16
|82-96
|0x52-0x60
|Nothing.
|2-16
|The number in the word name (2-16) is pushed onto the stack.
|}

=== Flow control ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_NOP
|97
|0x61
|Nothing
|Nothing
|Does nothing.
|-
|OP_VER '''DISABLED'''
|98
|0x62
|Nothing
|Protocol version
|Puts the version of the protocol under which this transaction will be evaluated onto the stack
|-
|OP_IF
|99
|0x63
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is not False, the statements are executed. The top stack value is removed.
|-
|OP_NOTIF
|100
|0x64
| colspan="2"|<expression> notif [statements] [else [statements]]* endif
|If the top stack value is False, the statements are executed. The top stack value is removed.
|-
|OP_VERIF '''DISABLED'''
|101
|0x65
|Version
|<version> verif [statements] [else [statements]]* endif
|If the top stack value is EQUAL to the version of the protocol under which this transaction will be evaluated, the statements are executed. The top stack value is removed.
|-
|OP_VERNOTIF '''DISABLED'''
|102
|0x66
|Version
|<version> vernotif [statements] [else [statements]]* endif
|If the top stack value is NOT EQUAL to the version of the protocol under which this transaction will be evaluated, the statements are executed. The top stack value is removed.
|-
|OP_ELSE
|103
|0x67
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not.
|-
|OP_ENDIF
|104
|0x68
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without a prior matching OP_IF or OP_NOTIF is also '''invalid'''.
|-
|OP_VERIFY
|105
|0x69
|True / false
|Nothing / ''fail''
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.
|-
|[[OP_RETURN]]
|106
|0x6a
|Nothing
|''Ends script with top value on stack as final result''
| OP_RETURN can also be used to create "False Return" outputs with a scriptPubKey consisting of OP_FALSE OP_RETURN followed by data. Such outputs are provably unspendable and should be given a value of zero Satoshis. These outputs can be pruned from storage in the UTXO set, reducing its size. Currently the BitcoinSV network supports multiple FALSE RETURN outputs in a given transaction with each one capable of holding up to 100kB of data. After the Genesis upgrade in 2020 miners will be free to mine transactions containing FALSE RETURN outputs of any size.
|}

=== Stack ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_TOALTSTACK
|107
|0x6b
|x1
|(alt)x1
|Puts the input onto the top of the alt stack. Removes it from the main stack.
|-
|OP_FROMALTSTACK
|108
|0x6c
|(alt)x1
|x1
|Puts the input onto the top of the main stack. Removes it from the alt stack.
|-
|OP_2DROP
|109
|0x6d
|x1 x2
|Nothing
|Removes the top two stack items.
|-
|OP_2DUP
|110
|0x6e
|x1 x2
|x1 x2 x1 x2
|Duplicates the top two stack items.
|-
|OP_3DUP
|111
|0x6f
|x1 x2 x3
|x1 x2 x3 x1 x2 x3
|Duplicates the top three stack items.
|-
|OP_2OVER
|112
|0x70
|x1 x2 x3 x4
|x1 x2 x3 x4 x1 x2
|Copies the pair of items two spaces back in the stack to the front.
|-
|OP_2ROT
|113
|0x71
|x1 x2 x3 x4 x5 x6
|x3 x4 x5 x6 x1 x2
|The fifth and sixth items back are moved to the top of the stack.
|-
|OP_2SWAP
|114
|0x72
|x1 x2 x3 x4
|x3 x4 x1 x2
|Swaps the top two pairs of items.
|-
|OP_IFDUP
|115
|0x73
|x
|x / x x
|If the top stack value is not 0, duplicate it.
|-
|OP_DEPTH
|116
|0x74
|Nothing
|<Stack size>
|Counts the number of stack items onto the stack and places the value on the top
|-
|OP_DROP
|117
|0x75
|x
|Nothing
|Removes the top stack item.
|-
|OP_DUP
|118
|0x76
|x
|x x
|Duplicates the top stack item.
|-
|OP_NIP
|119
|0x77
|x1 x2
|x2
|Removes the second-to-top stack item.
|-
|OP_OVER
|120
|0x78
|x1 x2
|x1 x2 x1
|Copies the second-to-top stack item to the top.
|-
|OP_PICK
|121
|0x79
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 xn
|The item ''n'' back in the stack is copied to the top.
|-
|OP_ROLL
|122
|0x7a
|xn ... x2 x1 x0 <n>
|... x2 x1 x0 xn
|The item ''n'' back in the stack is moved to the top.
|-
|OP_ROT
|123
|0x7b
|x1 x2 x3
|x2 x3 x1
|The top three items on the stack are rotated to the left.
|-
|OP_SWAP
|124
|0x7c
|x1 x2
|x2 x1
|The top two items on the stack are swapped.
|-
|OP_TUCK
|125
|0x7d
|x1 x2
|x2 x1 x2
|The item at the top of the stack is copied and inserted before the second-to-top item.
|}

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CAT
|126
|0x7e
|x1 x2
|out
|Concatenates two strings.
|-
|OP_SPLIT
|127
|0x7f
|x n
|x1 x2
|Splits byte sequence x at position n.
|-
|OP_NUM2BIN
|128
|0x80
|a b
| out
|Converts numeric value a into byte sequence of length b.
|-
|OP_BIN2NUM
|129
|0x81
| x
| out
|Converts byte sequence x into a numeric value.
|-
|OP_SIZE
|130
|0x82
|in
|in size
|Pushes the string length of the top element of the stack (without popping it).
|}

=== Bitwise logic ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_INVERT
|131
|0x83
|in
|out
|Flips all of the bits in the input.
|-
|OP_AND
|132
|0x84
|x1 x2
|out
|Boolean ''and'' between each bit in the inputs.
|-
|OP_OR
|133
|0x85
|x1 x2
|out
|Boolean ''or'' between each bit in the inputs.
|-
|OP_XOR
|134
|0x86
|x1 x2
|out
|Boolean ''exclusive or'' between each bit in the inputs.
|-
|OP_EQUAL
|135
|0x87
|x1 x2
|True / false
|Returns 1 if the inputs are exactly equal, 0 otherwise.
|-
|OP_EQUALVERIFY
|136
|0x88
|x1 x2
|Nothing / ''fail''
|Same as OP_EQUAL, but runs OP_VERIFY afterward.
|}

=== Arithmetic ===

Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.

If any input value for any of these commands is longer than 4 bytes, the script must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_1ADD
|139
|0x8b
|in
|out
|1 is added to the input.
|-
|OP_1SUB
|140
|0x8c
|in
|out
|1 is subtracted from the input.
|-
|OP_2MUL '''DISABLED'''
|141
|0x8d
|in
|out
|The input is multiplied by 2.
|-
|OP_2DIV '''DISABLED'''
|142
|0x8e
|in
|out
|The input is divided by 2.
|-
|OP_NEGATE
|143
|0x8f
|in
|out
|The sign of the input is flipped.
|-
|OP_ABS
|144
|0x90
|in
|out
|The input is made positive.
|-
|OP_NOT
|145
|0x91
|in
|out
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.
|-
|OP_0NOTEQUAL
|146
|0x92
|in
|out
|Returns 0 if the input is 0. 1 otherwise.
|-
|OP_ADD
|147
|0x93
|a b
|out
|a is added to b.
|-
|OP_SUB
|148
|0x94
|a b
|out
|b is subtracted from a.
|-
|OP_MUL
|149
|0x95
|a b
|out
|a is multiplied by b.
|-
|OP_DIV
|150
|0x96
|a b
|out
|a is divided by b.
|-
|OP_MOD
|151
|0x97
|a b
|out
|Returns the remainder after dividing a by b.
|-
|OP_LSHIFT
|152
|0x98
|a b
|out
|Shifts a left b bits, preserving sign.
|-
|OP_RSHIFT
|153
|0x99
|a b
|out
|Shifts a right b bits, preserving sign.
|-
|OP_BOOLAND
|154
|0x9a
|a b
|out
|If both a and b are not 0, the output is 1. Otherwise 0.
|-
|OP_BOOLOR
|155
|0x9b
|a b
|out
|If a or b is not 0, the output is 1. Otherwise 0.
|-
|OP_NUMEQUAL
|156
|0x9c
|a b
|out
|Returns 1 if the numbers are equal, 0 otherwise.
|-
|OP_NUMEQUALVERIFY
|157
|0x9d
|a b
|Nothing / ''fail''
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
|-
|OP_NUMNOTEQUAL
|158
|0x9e
|a b
|out
|Returns 1 if the numbers are not equal, 0 otherwise.
|-
|OP_LESSTHAN
|159
|0x9f
|a b
|out
|Returns 1 if a is less than b, 0 otherwise.
|-
|OP_GREATERTHAN
|160
|0xa0
|a b
|out
|Returns 1 if a is greater than b, 0 otherwise.
|-
|OP_LESSTHANOREQUAL
|161
|0xa1
|a b
|out
|Returns 1 if a is less than or equal to b, 0 otherwise.
|-
|OP_GREATERTHANOREQUAL
|162
|0xa2
|a b
|out
|Returns 1 if a is greater than or equal to b, 0 otherwise.
|-
|OP_MIN
|163
|0xa3
|a b
|out
|Returns the smaller of a and b.
|-
|OP_MAX
|164
|0xa4
|a b
|out
|Returns the larger of a and b.
|-
|OP_WITHIN
|165
|0xa5
|x min max
|out
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.
|}

=== Cryptography ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_RIPEMD160
|166
|0xa6
|in
|hash
|The input is hashed using RIPEMD-160.
|-
|OP_SHA1
|167
|0xa7
|in
|hash
|The input is hashed using SHA-1.
|-
|OP_SHA256
|168
|0xa8
|in
|hash
|The input is hashed using SHA-256.
|-
|OP_HASH160
|169
|0xa9
|in
|hash
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
|-
|OP_HASH256
|170
|0xaa
|in
|hash
|The input is hashed two times with SHA-256.
|-
|[[OP_CODESEPARATOR]]
|171
|0xab
|Nothing
|Nothing
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
|-
|[[OP_CHECKSIG]]
|172
|0xac
|sig pubkey
|True / false
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.
|-
|OP_CHECKSIGVERIFY
|173
|0xad
|sig pubkey
|Nothing / ''fail''
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
|-
|OP_CHECKMULTISIG
|174
|0xae
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
|True / False
|Compares the first signature against each public key until it finds an ECDSA match. Starting with the subsequent public key, it compares the second signature against each remaining public key until it finds an ECDSA match. The process is repeated until all signatures have been checked or not enough public keys remain to produce a successful result. All signatures need to match a public key. Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the scriptSig using the same order as their corresponding public keys were placed in the scriptPubKey or redeemScript. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.
|-
|OP_CHECKMULTISIGVERIFY
|175
|0xaf
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>
|Nothing / ''fail''
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
|}

=== Locktime ===
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)
|177
|0xb1
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 0065]. '''This opcode will be deprecated post activation of the Genesis upgrade. Any UTXOs that incorporate it into their locking script will remain spendable however if it appears in new transactions it will be treated as OP_NOP2'''
|-
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)
|178
|0xb2
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the relative lock time of the input (enforced by [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 0068] with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 0112]. '''This opcode will be deprecated post activation of the Genesis upgrade. Any UTXOs that incorporate it into their locking script will remain spendable however if it appears in new transactions it will be treated as OP_NOP3'''
|}

===Pseudo-words===
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Description
|-
|OP_PUBKEYHASH
|253
|0xfd
|Represents a public key hashed with OP_HASH160.
|-
|OP_PUBKEY
|254
|0xfe
|Represents a public key compatible with OP_CHECKSIG.
|-
|OP_INVALIDOPCODE
|255
|0xff
|Matches any opcode that is not yet assigned.
|}

=== Reserved words ===
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!When used...
|-
|OP_RESERVED
|80
|0x50
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED1
|137
|0x89
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED2
|138
|0x8a
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_NOP1, OP_NOP4-OP_NOP10
|176, 179-185
|0xb0, 0xb3-0xb9
|The word is ignored. Does not mark transaction as invalid.
|}

==Examples==

For examples of common Bitcoin transaction scripts please see [[Bitcoin Transactions]]

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/Script 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.

Script

2020-02-19T11:04:55Z

Steve:

Bitcoin uses a scripting system for [[Bitcoin_Transactions|transactions]]. [[Wikipedia:FORTH|Forth]]-like, '''Script''' is simple, stack-based, and processed from left to right. The script inside transaction outputs is intentionally not [https://en.wikipedia.org/wiki/Turing_completeness Turing-complete] and has no jump instructions to prevent the formation of loops, however with the use of an off-chain agent turing-complete processes can be built using the ledger as a ticker tape to store computational results.

A transaction output script is a predicate formed by a list of instructions that describe how the next person wanting to transfer the tokens locked in the script must unlock them. The script for a typical P2PKH script to Bitcoin address D simply encumbers future spending of the bitcoins with the provision of two things:
# a public key that, when hashed, yields destination address D embedded in the script, and
# a signature to prove ownership of the private key corresponding to the public key just provided.

Scripting provides the flexibility to change the parameters of what's needed to spend transferred bitcoins. For example, the scripting system could be used to require two private keys, or a combination of several keys, or even no keys at all. The tokens are unlocked if the solution provided by the spending party leaves a non-zero value on the top of the stack when the script terminates.

De facto, Bitcoin script is defined by the code run by the nodes building the [[Block chain]]. Nodes collectively agree on the opcode set that is available for use, and how to process those opcodes. Throughout the history of Bitcoin there have been numerous changes to the way script is processed including the addition of new opcodes and disablement or outright removal of opcodes from the set.

The nodes checking Bitcoin script process transaction inputs in a script evaluation engine. The engine is comprised of three stacks which are:
* The main stack
* The alt stack

In addition, the system also uses a subscript management system to track the depth of nested [[Scripts with Flow Control (Conditional Clauses)|If-Loops]]

The main and alt stacks hold byte vectors which can be used by Bitcoin opcodes to process script outcomes.
When used as numbers, byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer.
Thus 0x81 represents -1.
0x80 is another representation of zero (so called negative 0).
Positive 0 is represented by a null-length vector.
Byte vectors are interpreted as Booleans where False is represented by any representation of zero and True is represented by any representation of non-zero.

Before the Genesis upgrade, byte vectors on the stack are not allowed to be more than 520 bytes long however in the unbounded Bitcoin protocol while pushdata opcodes are limited to pushing 4.3GB onto the stack it is theoretically possible to concatenate multiple objects on the stack to form larger singular data items for processing.

Before Genesis, Opcodes which take integers and bools off the stack require that they be no more than 4 bytes long, but addition and subtraction can overflow and result in a 5 byte integer being put on the stack. After the Genesis upgrade in early 2020, miners are now free to mine transactions with data items of any size possible within protocol rules. These will be usable with mathematical functions within script. At this time, Miners will collectively agree on appropriate data limits rather than allowing a centralised committee to form a set of default constraints.

==More on Bitcoin Script==
#[[Opcodes used in Bitcoin Script]]
#[[Number Encoding in Bitcoin Script]]
#[[Scripts with Flow Control (Conditional Clauses)]]
#[[Data passing in inputs]]
#[[OP_CODESEPARATOR]]
#[[OP_RETURN]]
#[[OP_VER]]
#[[Complex Script Examples]]

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/Script 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.

Bitcoin Transactions

2020-02-18T22:40:29Z

Steve:

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 custody 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 [[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 (locking script). 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 2
|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<sup>32</sup> inputs.

All of the new transaction's input value (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]]) is consumed by the outputs of the new transaction.

'''Previous tx''' is the [[TXID]] 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. To redeem a P2PKH script the input must provide a public key and an [[Elliptic Curve Digital Signature Algorithm|ECDSA]] signature. The Public key is doubled hashed (First [[SHA-256]] then [[RIPEMD-160]]) and the resultant hash must match the hash embedded in the ScriptPubKey of the output being redeemed.

The public key is then used to verify the redeemer's 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]]

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/Transaction 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.

Protocol

2020-02-18T12:29:15Z

Steve:

==Bitcoin Protocol Rules==
The rules of the Bitcoin protocol are the rules that precisely define the Bitcoin system.

There are different classes of rule in the Bitcoin system including:
*Immutable rules
*Mutable rules
**Local Policies
**Standard Policies
*Communication rules

== Immutable Rules ==
The immutable rules are codified into Bitcoin node clients and must be strictly adhered to in order to implement the Bitcoin specification in software [1]. They are a set of rules that define the format and constraints that transactions and blocks must follow. Changes to these rules require a hard fork to the network which can result in a ledger duplication in cases where miners try to enforce changes that change the nature of Bitcoin. As Bitcoin is defined by these rules a forked chain that alters them might share the history of the ledger but cannot be considered to be Bitcoin, rather it is a new block chain.

These include:

*The sum of the value of the inputs of a transaction must be greater than or equal to the sum of the values of the outputs
*The [[Block subsidy|block subsidy]] will drop by half at a scheduled rate of every 210,000 blocks, starting with a subsidy of 5,000,000,000 [[satoshis]] from the genesis block
*The network will adjust the [[target]] for the [[difficulty]] of the [[Proof of Work]] needed for a valid block to maintain an approximate 10 minute block discovery rate
*Only blocks that add to the [[block chain]] formed by building upon the [[Genesis block]] are valid
*The structure of the Bitcoin database as a timestamp server validating chains of transaction outputs
*Transactions data formatting, including sizes of certain fields and their encoding schema
*Block structure and header information including sizes of certain fields and their encoding schema
* The [[Advanced Bitcoin Scripting|Bitcoin scripting language]] and its specification including:
**Lists of opcodes that are usable in script and the exact outcome of their execution

Forced changes to these protocol rules in the past have resulted in hostile duplications of the Bitcoin database, creating BTC which removed the requirement for Bitcoin to be a chain of digital signatures, and BCH which modified the timestamping aspect of the system as well as modifying the scripting language to add op codes not part of the original design.

The Bitcoin SV philosophy is that where aspects of these rules have been changed in the past they should be returned to be as close to the original rules as possible and then “set in stone”, with only changes needed to protect the security of the network such as the migration to a new hash function should SHA256 be broken be allowed, with this rule being enforced through [[Nakamoto Consensus]].

== Mutable Rules ==
Mutable rules are consensus rules that mining clients implement but which are not hard coded into the BitcoinSV node client. Miners can change these at any time provided there is enough agreement among miners to do so under [[Nakamoto Consensus]]. Miners who do not maintain these settings in-line with the rest of the network risk having their blocks invalidated.
Examples of these include:
*The maximum script memory usage rule which governs how much memory a transaction can consume during the execution of its script
*The maximum block-size rule
*Transaction script rules such as the rule preventing the use of opcodes other than pushdata in ScriptSig
It is important to note that these rules can be violated in special cases by miners through a negotiation process that ends with a transaction or block that violates these rules being accepted and built upon. This can only be achieved through Nakamoto consensus. No examples of this happening have yet been encountered.

When modifying these rules, miners tend to act as a collective, changing a particular rule all at once (e.g. maximum transaction memory limits and maximum block size). Since the [[Genesis upgrade]], these changes no longer require hard forks or scheduled network upgrades, and the settings that govern these changes available to miners through node client configuration tools. All that is required is a loose agreement between miners to change the settings across the network at a particular date and time.

This means that miners must be aware of the actions being taken by the rest of the network lest they find themselves rejecting transactions or blocks that a majority of the network is accepting and become stuck on a non-productive chain-tip while the remainder of the network move forward.

===Local rules===
These rules are “local” by definition. They apply to the instance of software that is running, they do not apply to the validation of blocks, or the transactions within a block. A block accepted from another miner may contain transactions that do not conform to local rules.
Local rules include:
*The “minimum fee” rule, which specifies that the node will only accept and/or relay unconfirmed transactions that pay above a certain fee
*Dust rules which specify the smallest value output a transaction can contain that the node will accept and/or relay
*Rules relating to inbound and outbound connections on the network such as RPC responses, specific IP addresses to connect to and more.

===Standard Policies===
Standard policies are local rules that are used by a significant proportion of network nodes. They are defined as a "Standard" to facilitate common application across independent software implementations but it is important to note that it is not required that software implement or adhere to these policies.

Bitcoin users who transact within the guidelines of standard policy will face the least issues with their transactions on the network. Some miners can enact local rules outside of the standard policies however this can cause issues for the miner, who may be attempting to mine blocks that carry large numbers of transactions which other miners have rejected. This can lead to [[Orphan Block|orphan blocks]] due to slow propagation.

==Communication Rules==
The communication rules govern how transaction and block data is propagated across the Bitcoin network. Commonly referred to as the Bitcoin [[Peer-To-Peer Protocol|Peer-To-Peer (P2P) Protocol]], this current version is well defined method and used by the majority of Bitcoin nodes in the network to communicate. The P2P Protocol can be changed and there are plans among miners to modify the implementation in future. It is conceivable that at a certain point, several different inter-node communications protocols may be in-use to propagate block and transaction information between miners, and optimising this aspect of the network is strongly incentivised by the economics of Bitcoin mining. A large amount of the innovation that scales Bitcoin SV has been, and will in future be done by improving the P2P protocol.

==See Also==
* [[The Bitcoin Network]]
* [[Nakamoto Consensus]]
* [[P2P Network]]

==References==
[1] - https://github.com/bitcoin-sv-specs/protocol/blob/master/updates/genesis-spec.md

Protocol

2020-02-18T12:20:28Z

Steve:

==Bitcoin Protocol Rules==
The rules of the Bitcoin protocol are the rules that precisely define the Bitcoin system.

There are different classes of rule in the Bitcoin system including:
*Immutable rules
*Mutable rules
**Local Policies
**Standard Policies
*Communication rules

== Immutable Rules ==
The immutable rules are codified into Bitcoin node clients and must be strictly adhered to in order to implement the Bitcoin specification in software [1]. They are a set of rules that define the format and constraints that transactions and blocks must follow. Changes to these rules require a hard fork to the network which can result in a ledger duplication in cases where miners try to enforce changes that change the nature of Bitcoin. As Bitcoin is defined by these rules a forked chain that alters them might share the history of the ledger but cannot be considered to be Bitcoin, rather it is a new block chain.

These include:

*The sum of the value of the inputs of a transaction must be greater than or equal to the sum of the values of the outputs
*The [[Block subsidy|block subsidy]] will drop by half at a scheduled rate of every 210,000 blocks, starting with a subsidy of 5,000,000,000 [[satoshis]] from the genesis block
*The network will adjust the [[target]] for the [[difficulty]] of the [[Proof of Work]] needed for a valid block to maintain an approximate 10 minute block discovery rate
*Only blocks that add to the [[block chain]] formed by building upon the [[Genesis block]] are valid
*The structure of the Bitcoin database as a timestamp server validating chains of digital signatures
*Transactions data formatting, including sizes of certain fields and their encoding schema
*Block structure and header information including sizes of certain fields and their encoding schema
* The [[Advanced Bitcoin Scripting|Bitcoin scripting language]] and its specification including:
**Lists of opcodes that are usable in script and the exact outcome of their execution

Forced changes to these protocol rules in the past have resulted in hostile duplications of the Bitcoin database, creating BTC which removed the requirement for Bitcoin to be a chain of digital signatures, and BCH which modified the timestamping aspect of the system.

The Bitcoin SV philosophy is that where aspects of these rules have been changed in the past they should be returned to be as close to the original rules as possible and then “set in stone”, with only changes needed to protect the security of the network such as the migration to a new hash function should SHA256 be broken be allowed, with this rule being enforced through [[Nakamoto Consensus]].

== Mutable Rules ==
Mutable rules are consensus rules that mining clients implement but which are not hard coded into the BitcoinSV node client. Miners can change these at any time provided there is enough agreement among miners to do so under [[Nakamoto Consensus]]. Miners who do not maintain these settings in-line with the rest of the network risk having their blocks invalidated.
Examples of these include:
*The maximum transaction memory usage rule which governs how much memory a transaction can consume during the execution of its script
*The maximum block-size rule
*Transaction script rules such as the rule preventing the use of opcodes other than pushdata in ScriptSig
It is important to note that these rules can be violated in special cases by miners through a negotiation process that ends with a transaction or block that violates these rules being accepted and built upon. This can only be achieved through Nakamoto consensus. No examples of this happening have yet been encountered.

When modifying these rules, miners tend to act as a collective, changing a particular rule all at once (e.g. maximum transaction memory limits and maximum block size). Since the [[Genesis upgrade]], these changes no longer require hard forks or scheduled network upgrades, and the settings that govern these changes available to miners through node client configuration tools. All that is required is a loose agreement between miners to change the settings across the network at a particular date and time.

This means that miners must be aware of the actions being taken by the rest of the network lest they find themselves rejecting transactions or blocks that a majority of the network is accepting and become stuck on a non-productive chain-tip while the remainder of the network move forward.

===Local rules===
These rules are “local” by definition. They apply to the instance of software that is running, they do not apply to the validation of blocks, or the transactions within a block. A block accepted from another miner may contain transactions that do not conform to local rules.
Local rules include:
*The “minimum fee” rule, which specifies that the node will only accept and/or relay unconfirmed transactions that pay above a certain fee
*Dust rules which specify the smallest value output a transaction can contain that the node will accept and/or relay
*Rules relating to inbound and outbound connections on the network such as RPC responses, specific IP addresses to connect to and more.

===Standard Policies===
Standard policies are local rules that are used by a significant proportion of network nodes. They are defined as a "Standard" to facilitate common application across independent software implementations but it is important to note that it is not required that software implement or adhere to these policies.

Bitcoin users who transact within the guidelines of standard policy will face the least issues with their transactions on the network. Some miners can enact local rules outside of the standard policies however this can cause issues for the miner, who may be attempting to mine blocks that carry large numbers of transactions which other miners have rejected. This can lead to [[Orphan Block|orphan blocks]] due to slow propagation.

==Communication Rules==
The communication rules govern how transaction and block data is propagates across the Bitcoin core network. Commonly referred to as the Bitcoin [[Peer-To-Peer Protocol|Peer-To-Peer (P2P) Protocol]], this current version is well defined method and used by the majority of Bitcoin nodes in the core network to communicate. The P2P Protocol can be changes and there are plans among miners to modify the implementation in future. It is conceivable that at a certain point, several different inter-node communications protocols may be in-use to propagate block and transaction information between miners, and optimising this aspect of the network is strongly incentivised by the economics of Bitcoin mining. A large amount of the innovation that scales Bitcoin SV has been, and will in future be done by improving the P2P protocol.

==See Also==
* [[The Bitcoin Network]]
* [[Nakamoto Consensus]]
* [[P2P Network]]

==References==
[1] - https://github.com/bitcoin-sv-specs/protocol/blob/master/updates/genesis-spec.md

MinerID

2020-02-18T12:05:31Z

Steve:

MinerId is a protocol that allows a miner to embed information inside the [[Coinbase|coinbase transaction]] of each block won by a particular node to allow all blocks it wins to be associated with an pseudonymous identity which the miner can optionally associate with a real world identity.

==Description==

Currently, Bitcoin miners can embed identity data in the blockchain by using space in the malleable input fields of the [[Coinbase|coinbase]] transaction in the blocks that they mine. However, this data is not always accurate and can be
trivially forged/spoofed.

The MinerId protocol provides a way of ''cryptographically'' associating a block a specific miner's pseudo identity. A minerId is simply a public key from an ECDSA keypair. These keys are used to sign minerID metadata contained in the [[OP RETURN|OP_RETURN]] output of the coinbase transaction in a block.

Use of ECDSA cryptography to sign minerId metadata (as opposed to generating unsigned arbitrary data) provides data non-repudiation, linking miner identity to mined blocks in a reliable way.

Whilst the minerId protocol is a useful infrastructure tool for the Bitcoin SV network, '''it is not mandatory'''. It is a voluntary protocol providing a public key infrastructure for Bitcoin SV that miners can use to secure additional blockchain-based services.

===Definitions===

* '''MinerId''' - An ECDSA public key (based on [[secp256k1]] parameters) used by the miner to identify themselves.
* '''VcTx''' - (Validity check transaction) A transaction that determines the validity of the minerId based on whether it is unspent (valid) or spent (invalid/revoked). The VcTx is a feature that allows a miner to instantly revoke their minerId (if the private key is compromised for example). Naively, the miner could add a field in the coinbase document specifying if the minerId is still valid or not. However, by doing that, the miner would have to wait until they mine a block to revoke their minerId key. Using the VcTx, the miner can at any time revoke the validity of their minerId key without needing to generate [[Proof of Work|proof of work]].
* '''Coinbase document''' - A formatted data packet in the OP_RETURN (provably unspendable) output in the miner’s [[Coinbase| coinbase transaction]]. All miner identity information is stored in this document.

===Security===

Ideally, the minerId (by extension the coinbase transaction) should be specific to the block it is in. However, if this were enforced it would create a causality dilemma (chicken/egg scenario) since the header cannot be finalised and signed by the minerId key without the hash of the coinbase transaction which, in turn, cannot be created until the minerId key is finalised.

By making the minerId specific to the block it’s mined in, we effectively bind the signature to the block it’s contained in. Without this binding, a malicious miner could take the entire coinbase document and replay it in another block, potentially in a block that damages reputation e.g. an empty block that reduces network throughput. Because the block height is included in the coinbase document, the cost of replaying coinbase document data becomes as difficult as successfully forking the network (see [[Re-org]]), which is very expensive. This cost should be enough to drastically reduce the likelihood of this attack.

==Examples==

The minerId protocol has been supported by TAAL mining ltd. since 20th December 2019.

* https://whatsonchain.com/tx/17a8b9994f1e89855b34660ea1d17061ae65833f1ded395c4c6a72d2d98832a6

* https://whatsonchain.com/tx/d898e7f3c198cefccf99e6ec982786f25af62aa86d6bc56c66a611660bf04942

==See Also==

* Medium.com blog post - https://medium.com/@jadwahab/6578046ac88?

Orphan Block

2020-02-18T12:00:27Z

Steve:

An "orphan block" is a well-formed block with valid proof of work which has been rejected by miners and does not form part of the longest [[Block chain]]. As the block in question has not been accepted, the block reward and the [[transaction fees]] are no longer spendable on the difficulty wise-longest and well-formed blockchain. This phenomenon must be taken into account by mining pools that use any payout strategy other than "proportional".

An orphan block often originates when two [[Mining|miners]] produce a block around the same point in time. The time delay in propagating and accepting a block leads to Bitcoin SV nodes encountering scenarios where they need to select which of multiple blocks to accept as the most legitimate to include next in the chain. After a block is selected by the network, then the other block is considered an orphaned block. Transactions in the orphaned block that were not included in the successful block are re-included into the mempool as membership candidates for future blocks. In most cases the vast majority of transactions will be included in both as propagation of transactions across the network is very efficient and both miners are likely to have seen the same set.

In other instances, orphan blocks may be generated when malicious nodes seek to reverse transactions by generating alternative desired blocks. This they hope to accomplish through the utilization of large amounts of hash power (see [[Attacks on Bitcoin| 51% attack]]). However, attacks intended to cause the deliberate orphaning of blocks are extremely resource-intensive and are largely infeasible. The blocks they generate generally end up being orphaned themselves.

==See Also==
* [[Miner subsidy]]

Orphan Block

2020-02-18T11:59:57Z

Steve:

Orphan Block

2020-02-18T11:53:35Z

Steve:

An "orphan block" is a well-formed block with valid proof of work which has been rejected by miners and does not form part of the longest [[Block chain]]. As the block in question has not been accepted, the block reward and the [[transaction fees]] are no longer spendable on the difficulty wise-longest and well-formed blockchain. This phenomenon must be taken into account by mining pools that use any payout strategy other than "proportional".

An orphan block often originates when two [[Mining|miners]] produce a block around the same point in time. The time delay in propagating and accepting a block leads to Bitcoin SV nodes encountering scenarios where they need to select which of multiple blocks to accept as the most legitimate to include next in the chain. After a block is selected by the network, then the other block is considered an orphaned block. Transactions in the orphaned block that were not included in the successful block are re-included into the mempool as membership candidates for future blocks.

In other instances, orphan blocks may be generated when malicious nodes seek to reverse transactions by generating alternative desired blocks. This they hope to accomplish through the utilization of large amounts of hash power (see [[Attacks on Bitcoin| 51% attack]]). However, attacks intended to cause the deliberate orphaning of blocks are extremely resource-intensive and are largely infeasible. The blocks they generate generally end up being orphaned.

==See Also==
* [[Miner subsidy]]

Main Page

2020-02-18T11:50:27Z

Steve:

Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality.

===Bitcoin===

'''Bitcoin''' is a peer to peer electronic cash system created by [https://craigwright.net/ Dr. Craig Wright] under the pseudonym [[Satoshi Nakamoto]]. It was first detailed in the [[Bitcoin whitepaper|Bitcoin white paper]] in October 2008, and the source code was [https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html released] in January 2009. The [[Genesis block|first block]] was mined on the 3rd of January 2009.

Bitcoin allows online payments to be sent directly from one party to another, without requiring a central institution or server to process transactions and/or store funds.

The leaderless structure of the network is viewed as a resolution to [[The Byzantine Generals Problem]] allowing disconnected entities to follow a common direction without centralised instruction. This solves several issues previously seen as unsolvable in distributed networks, including the problem of preventing [[Double-spending]] of coins on the network

===Applications===
Bitcoin is primarily a [[Payments in Bitcoin|payment system]] which supports peer to peer connection and [[Instant Transactions]]. Early in the [[History of Bitcoin]] payments required users to understand complicated technical details of Bitcoin's technological underpinnings to make transactions however developments such as [[Paymail]] and [[Simplified Payment Verification]] are changing the landscape and making it much easier for users to connect.

Bitcoin also supports the development of [[Application layer protocol|application layer protocols]] which make use of [[Bitcoin Transactions]] as a transport layer for information exchange. Several Application layer protocols already exist for BitcoinSV - for more detail see [[Building on Bitcoin]]. [[The Metanet]] fuses Bitcoin's highly secure and instant [[Transaction fees|sub-cent transactions]] with onchain data storage and transferability enabling efficient and secure web usage. This will bring forth an Internet of Value where Micropayments become a means to both access and monetize data.

Applications which make use of the immutable nature of the [[Block_chain|Bitcoin Ledger]] to store and retrieve data are increasingly emerging. [[False Return]] scripts and other scripts that use [[Pushdata Opcodes]] to push data into Bitcoin transactions are creating new ways of recording data for public consumption. Bitcoin acts as a [[Timechain|timestamp server]] allowing data to be validated and referenced using transactions.

===The Ledger===
The Bitcoin ledger is a record of all transactions that have ever been timestamped on the network. The ledger is formed as a [[wikipedia:Directed Acyclic Graph|Directed acyclic graph]] (DAG) where each transaction is a node. The graph starts at the [[Coinbase]] transaction of the [[Genesis block|first block ever found]] and via chains of [[Digital Signatures in Bitcoin|digital signatures]] maps out the entire history of valid exchange actions, allowing the tracing of all bitcoins back to their creation.

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

Valid transactions that are broadcast on [[The Bitcoin Network]] are committed to the ledger by miners in [[Block|Blocks]]. A block consists of an ordered list of [[TXID|transaction hashes]] and a [[Block hashing algorithm#Block_Header|header]] which includes the root generated by hashing the listed transactions into a [[wikipedia:Merkle tree|Merkle tree]], a timestamp, a reference to the block it builds upon and the means to validate the [[Proof of Work]] needed for other miners to accept the block as valid.

Blocks form a second layer DAG called the [[Block chain]] which is built by [[Mining|network miners]] in a competitive process. Each block forms a node in the graph with a single incoming edge from the block it is built upon. A block may have more than one outgoing edge in a case where multiple blocks were built upon it, but only one of those edges can becomes part of the longest chain of proof of work. A block without an edge to the longest chain of proof of work is called an [[Orphan Block]].

[[File:Block_Chain.png|frame|centre|alt=A chain of blocks]]

The structure of the block chain DAG means that there is a clearly traceable path back to the [[Genesis block|first block mined]]. Blocks are discovered just under every 10 minutes on average, with miners using a predefined mathematical algorithm to control the [[difficulty]] of the proof of work process to maintain that time frame.

Transactions can be exchanged peer to peer using [[Simplified Payment Verification]] (SPV) to manage trust. SPV involves sending accompanying information with a transaction input that proves it is from a transaction that has been timestamped on the ledger.

[[File:Simplified_Payment_Verification.png|frame|centre|alt=Simplified payment verification]]

Users can exchange unfinalised transactions without sending them to the network to be mined creating what are called [[Payment Channels]].
Payment channels allow users to conduct information exchange within valid Bitcoin transactions, only broadcasting a finalised transaction including the full value exchange to the mining network once the information transfer is complete.

Once a transactions is sent to the network, global consensus can be reached on the validity in less than 2 seconds. If a transaction is not accepted by any miners and added to a block, it does not become part of the ledger.

===Transactions===
All [[Bitcoin Transactions]] are [[Payments in Bitcoin|payments]] of some kind. Transactions are written in a flexible [[Advanced_Bitcoin_Scripting|scripting language]] that is used to assign custodial control to each transaction output via the creation of arbitrary spending conditions defined by scripts.

Each transaction uses '[[UTXO|coins]]' as inputs and spends them into a new set of coins as [[VOUT|outputs]]. When coins are spent in a transaction they are destroyed.

[[File:Transaction.png|frame|centre|alt=Transaction inputs and outputs]]

The Bitcoin scripting language can be used in a way that is [[wikipedia:Turing_completeness|Turing complete]], creating a [[wikipedia:Turing_machine|Turing machine]] that uses the Bitcoin ledger as a tape, reading to and writing from the transaction graph as needed.

The script also includes opcodes that allow users to embed arbitrary data in transactions, providing for the creation of [[Application layer protocol|application layer protocols]] that use Bitcoin transactions as a [[wikipedia:Transport layer|transport layer]].

Rewards paid to miners for the creation of a block are inscribed in what is called a [[Coinbase]] transaction. This transaction has a specific format and is always the last transaction in the block's [[wikipedia:Merkle tree|Merkle tree]].

===Nodes and Mining===
The ledger is held on a [https://en.wikipedia.org/wiki/Distributed_networking distributed network] of nodes who use hash based [[Proof of Work]] to compete for the right to extend it and as a means to vote on [[Network|network rules]]. The proof of work of each block in the longest chain of work is incorporated into its subsequent block to form the chain structure.

[[File:Proof_of_Work.png|frame|centre|alt=A chain of hash based proof of work]]

During the mining process, a node gather transactions from the network and evaluates whether they are profitable to mine before putting them into a block template. Block templates are created by calculating the root of a [https://en.wikipedia.org/wiki/Merkle_tree Merkle tree] containing all of the transactions being mined. The order of transactions in the Merkle tree is not related to their position in the transaction DAG. As new transactions arrive, they are added to the tree, creating a new, updated template. A block is found when a miner successfully discovers a value that generates a hash less than the [[difficulty]] [[target]]. The miner must then propagate the new block to the rest of the network who must then build an additional 100 blocks on top of it before the winner can claim the block reward.

[[File:Merkle tree.png|frame|centre|alt=The structure of a Merkle Tree]]

Nodes are operated by the [[Mining|Bitcoin mining enterprises]] who build the network. Bitcoin's economic incentives are structured such that for the nodes to be most profitable at building the ledger they must be as closely connected to other well performing nodes as possible. This leads to miners forming a [[Small World Network]] which trends towards a [[Nearly Complete Graph]] where all miners are connected to all other miners. Miners gather transactions from users who connect in a layered network over the nodes at the core forming a [[Mandala Network]]. In this shell network, peers use [[Simplified Payment Verification]] to form a much less densely packed structure where information is exchanged in [[Payment Channels]].

As Bitcoin scales, the nodes who comprise the network will be variously compartmentalised into specialised hardware. These clustered systems will be distributed globally, each being placed in a location optimised for its task.

As enterprise organisations, Bitcoin miners must operate as legal entities within a given jurisdiction and as such are bound to the laws and legal processes that exist in that jurisdiction. Through this, miners can be compelled to enact certain rules or perform certain actions in order to comply with the law. This can include the freezing or transferring of bitcoins stored on the ledger, or the rejection of transactions or blocks that try to spend bitcoins identified as proceeds of crime.

===Unit of account===
[[Satoshis]] are the ledger's native unit of account and 100,000,000 satoshis is abstracted to one bitcoin. Satoshis are held in script puzzles called [[UTXO|Unspent Transaction Outputs or UTXOs]]. These are [[VOUT|transaction outputs]] which are held by miners in a quick access database called the UTXO set. During the spending process, UTXOs being used in a transaction are consumed and the solution to their puzzle script is recorded in the transaction.

Satoshis are issued by miners to themselves as a [[Block subsidy|subsidy payment]] during the network establishment phase. As the network matures, the the subsidy dissipates forcing the miners to find alternate revenue streams. The payment allows miners to finance their operations through the payment of goods and services in bitcoin, spreading it through the economy.

===Network rules===
Bitcoin operates on a fixed ruleset. So-called consensus rules include things such as the operation of the [[Opcodes used in Bitcoin Script|opcodes]] in Bitcoin Script, the rate at which new bitcoins are issued, the mathematical function used to calculate the [[target]] for the [[Difficulty]] algorithm and more. The protocol is agreed upon by the miners who control network operation.

There are no limits in the [[Protocol|Bitcoin protocol]]. Any limits imposed are are put in place by miners who are incentivised to catch the largest profitable pools of transactions they can. Miners compete to offer better service to fee paying users by scaling their own capabilities.

===History===
[[Bitcoin until today|Bitcoin has a rich history]] and has been [[Attacks on Bitcoin|attacked]] in many ways since its inception. For example, at the time of writing, certain other groups are wrongly using the 'Bitcoin' name to refer to their own projects. The most famous of these uses a software implementation known as 'Bitcoin core' with tokens from the ledger traded as 'BTC' [[Bitcoin until today|(more information)]].

===Tools and Building on Bitcoin===
Bitcoin has a rich and diverse [[Building on Bitcoin|set of tools]] which are being added to all the time.

Nakamoto Consensus

2020-02-16T20:44:18Z

Steve:

Nakamoto consensus is consensus as it is defined in the [https://bitcoinsv.io/bitcoin.pdf Bitcoin whitepaper] where nodes vote to enforce the rules used to build the blocks that make up the Bitcoin public ledger.

It is a [[The Byzantine Generals Problem|Byzantine fault tolerant]] consensus algorithm that utilises the concept of [[Proof of Work]] and economic incentives to manage decision making rights.

Nakamoto Consensus defines an honest node as a node that seeks out the longest valid chain of blocks and applies proof of work to extend that chain. In this context, the longest chain represents greatest proof-of-work effort on the valid chain. 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 nodes vote to enforce the rules that govern the protocol and use of the [[Block chain]] as a global financial ledger with legal and regulatory oversight.

Through Nakamoto consensus, proof of work on the longest chain becomes an economic 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 encouraging honesty and cooperation between competing enterprise miners.

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

Miner subsidy

2020-02-16T20:42:37Z

Steve:

The miner subsidy is the means by which all [[Satoshis|Bitcoins]] on the network are initially distributed. The subsidy is paid to compensate early miners for the lack of [[Transaction fees]] being paid by users of the [[The Bitcoin Network|network]].

For the first 210,000 [[Block|blocks]] successful miners can claim a subsidy of 50 Bitcoins, however after each subsequent 210,000 blocks, the subsidy drops by half, eventually falling to zero after 32 'Halvening' cycles.

The miner subsidy was never intended to be the primary income mechanism for miners, but instead was a means to both bootstrap investment in the network and to broadly distribute the currency units in a fair and transparent manner.

Proof of Work

2020-02-16T20:38:31Z

Steve:

A '''proof of work''' is a piece of data which is difficult (costly and/or time-consuming) to produce but easy for others to verify. Proof of work production usually involves a computational task that includes a random process with low probability of success so that a lot of trial and error is required ''on average'' before a valid proof of work is generated. In Bitcoin the proof of work scheme is based on the [[SHA-256]] hashing algorithm.

== Proof of Work in Bitcoin ==

Bitcoin uses a proof of work system in the process of [[mining]]. In order for a [[block]] to be accepted, the broadcasting node must demonstrate proof of valid work which covers all of the data in the block. The [[difficulty]] of discovering valid work outcomes is adjusted to limit the average growth rate of the [[block chain]] to one block every 10 minutes.

For a block to be valid a nonce must be discovered that results in the double SHA-256 hash of the [[Block_hashing_algorithm#Block_Header|block header]] to a value less than the current [[target]]. This indicates that the node which discovered this block is an active participant in the network. Each block header contains the hash of the block being built upon, thus creating the chain of blocks that comprise the ledger. Changing a block can only be done by making a new block containing the same predecessor and requires regenerating all subsequent blocks by redoing the work they contain. This protects the block chain from tampering.

=== Summary ===

1. Proof of work is part of the Bitcoin consensus mechanism.

2. The Bitcoin proof of work algorithm attempts to solve a puzzle with a low probability of success per trial.

3. A miner uses a candidate block header as the input, hashes it to check whether the hash value is below a [[target]]. If not, the miner changes the nonce in the block header and tries again. Once the hash value is below the target, the block has been successfully mined.

4. In order for a block to be accepted by the Bitcoin network, miners must complete a proof of work which covers all of the data in the block. The difficulty of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes on average. Due to the very low probability of successful generation, it is impossible to predict which worker computer will generate the next block.

5. The low probability of successfully finding valid proof of work solutions reduces the likelihood that two or more miners generate a block around the same time.

Proof of Work

2020-02-16T20:07:40Z

Steve:

A '''proof of work''' is a piece of data which is difficult (costly and/or time-consuming) to produce but easy for others to verify. Proof of work production usually involves a computational task that includes a random process with low probability of success so that a lot of trial and error is required ''on average'' before a valid proof of work is generated. In Bitcoin the proof of work scheme is based on the [[SHA-256]] hashing algorithm.

== Proof of Work in Bitcoin ==

Bitcoin uses a derivative of the [[Hashcash]] proof of work system in the process of [[mining]]. In order for a [[block]] to be accepted, the broadcasting node must demonstrate proof of valid work which covers all of the data in the block. The [[difficulty]] of discovering valid work outcomes is adjusted to limit the average growth rate of the [[block chain]] to one block every 10 minutes.

For a block to be valid a nonce must be discovered that results in the double SHA-256 hash of the [[Block_hashing_algorithm#Block_Header|block header]] to a value less than the current [[target]]. This indicates that the node which discovered this block is an active participant in the network. Each block header contains the hash of the block being built upon, thus creating the chain of blocks that comprise the ledger. Changing a block can only be done by making a new block containing the same predecessor and requires regenerating all subsequent blocks by redoing the work they contain. This protects the block chain from tampering.

=== Summary ===

1. Proof of work is part of the Bitcoin consensus mechanism.

2. The Bitcoin proof of work algorithm attempts to solve a puzzle with a low probability of success per trial.

3. A miner uses a candidate block header as the input, hashes it to check whether the hash value is below a [[target]]. If not, the miner changes the nonce in the block header and tries again. Once the hash value is below the target, the block has been successfully mined.

4. In order for a block to be accepted by the Bitcoin network, miners must complete a proof of work which covers all of the data in the block. The difficulty of this work is adjusted so as to limit the rate at which new blocks can be generated by the network to one every 10 minutes on average. Due to the very low probability of successful generation, it is impossible to predict which worker computer will generate the next block.

5. The low probability of successfully finding valid proof of work solutions reduces the likelihood that two or more miners generate a block around the same time.

OP CHECKSIG

2020-02-16T20:04:04Z

Steve:

'''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. 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 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.

UTXO

2020-02-16T19:59:03Z

Steve:

UTXO is an acronym for unspent transaction output. Every [[Bitcoin Transactions|Bitcoin transaction]] in every [[block]] contains at least one [[VOUT|output]], which details how many Bitcoins are owned by the given public key(s). Outputs are then spent by inputs of later transactions and typically must be unlocked with a [[Digital Signatures in Bitcoin|digital signature]] (most commonly ECDSA in Bitcoin). Until an output is used as input in another transaction, this output is called a UTXO.

All UTXOs at a given time can be collected into a set, called the UTXO set.
The UTXO set represents the current state of ownership of all Bitcoin in existence. The inputs of transactions that are to be added to the [[blockchain]] are checked against this set. If an input to a transaction is an output in the UTXO set, the input can be validated. The UTXO set is deterministic for every Bitcoin block, that is, every node who has validated the history of the Bitcoin ledger up to a particular block should have an identical UTXO set. This is required in order for nodes to reach consensus on the validity of inputs in new transactions.

Confusingly the term UTXO is also often used as shorthand to refer to the set. Generally it is differentiated by the preceeding word. When referring to the set it is common to call it "the UTXO".

When a node receives a new transaction, one of the checks on the transaction is if the input is spending a UTXO in the set. If this check is passed, the output that is being spent is taken out of the UTXO set, and temporarily stored in a buffer. If the transaction is accepted into a block, the corresponding UTXO is deleted from this temporary storage. On the other hand, if the transaction that spends the UTXO is not included in a block, the UTXO is returned to the UTXO set as the output is still unspent. As soon as an output is spent, it is no longer in the UTXO set. This process prevents an output from being [[Double-spending|double-spent]].

==Provably unspendable outputs==

There is a subset of outputs which are provably unspendable. These outputs, whilst ‘unspent’, are not included in the UTXO set, as they are provably unspendable and will never be needed to validate a future transaction. Prior to the [[Genesis upgrade]] in February 2020, one form of these outputs start with the [[OP_RETURN]] [[Opcodes used in Bitcoin Script|opcode]] in the ScriptPubKey field of a transaction. Prior to this upgrade, The OP_RETURN opcode ended the script execution and returned a failure. After the Genesis upgrade, this provably unspendable output will be unlocking scripts beginning with the opcodes [[False Return|OP_FALSE OP_RETURN]].

VOUT

2020-02-16T19:51:28Z

Steve:

"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 2<sup>32</sup> 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 by a user that is able to satisfy the spending conditions defined by the output script. 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 have been 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. It should be noted that this is not the only mechanism for data storage, it is just the one that was easiest to use prior to the Genesis protocol restoration.

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

P2SH

2020-02-16T19:45:10Z

Steve:

'''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 be considered invalid by consensus.

Paymail

2020-02-16T19:41:24Z

Steve:

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 script to pay to for the actual Bitcoin transaction creation rather than relying on the concept of the Bitcoin address which is actually just a compact encoding of a script but limits the form of the script to one particular type. 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]

Transaction fees

2020-02-16T19:37:03Z

Steve:

'''Transaction fees''' are fees that Bitcoin users 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 record 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 transfers one or more satoshis to one or more recipients. The difference between the amount being spent from previous outputs and the amount being sent to new outputs 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 full block reward including the transaction fees and the [[block subsidy]] will be sent to the specified recipient. Miners are forced to wait 100 blocks before they can use 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.

An example of this can be seen in [https://whatsonchain.com/block-height/164246 block 164246] where the miner lost 1.76 Bitcoins by not claiming the fees.

==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 [[Merchant API]] 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.

Genesis upgrade

2020-02-16T19:22:46Z

Steve:

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 restored many aspects of the Bitcoin protocol that had been modified in previous software updates including the removal of most 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 locked in 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 to violate the protocol rules 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.

History of OP RETURN

2020-02-16T19:12:54Z

Steve:

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.

{{DISPLAYTITLE:History of OP_RETURN}}

False Return

2020-02-16T19:02:44Z

Steve:

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, relaxed these requirements to allow OP_FALSE OP_RETURN in preparation for the Genesis update in February 2020 where the original OP_RETURN functionality was restored. The use of the OP_FALSE replicated the provably unspendable property of OP_RETURN than many use cases have come to rely on.
Many second layer protocols were build using the OP_RETURN framework prior to being migrated to False Return outputs.

Nonce

2020-02-16T18:58:02Z

Steve:

The "nonce" in a bitcoin [[block]] is a 32-bit (4-byte) field whose value is adjusted by miners during the [[Proof of Work]] process in an effort to generate a block hash less than or equal to the current [[target]] of the network. The rest of the fields, with the exception of the timestamp, may not be changed, as they have a defined meaning.

Any change to the block data (such as the nonce) will make the block hash completely different. Since it is [[wikipedia:Cryptographic hash function|believed infeasible]] to predict which combination of bits will result in the right hash, many different nonce values are tried, and the hash is recomputed for each value until a hash less than or equal to the current [[target]] of the network is found. The target required is also represented as the [[difficulty]], where a higher difficulty represents a lower target. As this iterative calculation requires time and resources, the presentation of a block with a valid nonce value constitutes proof of work.

TXID

2020-02-16T18:34:26Z

Steve:

A Transaction ID or TXID is the '''double SHA256 hash''' or '''SHA256d''' of a serialized bitcoin [[Bitcoin Transactions|transaction]]. TXIDs are not part of the the transaction, as the hash cannot be generated until the transaction is complete. A TXID and VOUT (or ''prevout_n'') index are used to reference [[UTXO|UTXOs]] when they are added to a transaction as an input.

==Data==

<pre>
transaction:
{
"inputs": [
{
"prevout_hash": "b8ed28aa87b92328e26a20553ac49fcb21e1f68daeb6cf7bcf4536e40503ffa8",
"prevout_n": 0,
"scriptSig": "4830450221008824eee04a2fbe62d2c3ee330eb2523b2c0188240714bb1d893aced1c454fa9a02202d32dbccc2af1c4b
830795f2fa8cd569a06ee70cb9d836bbd510f0b45a47711b4121028580686976c0e6a7e44a78387913e2d7508ff2344d
5f48669ba111dcd04170a8",
"sequence": 4294967294,
}
],
"lockTime": 598793,
"outputs": [
{
"scriptPubKey": "76a9146b0a9ed05da7223a1fe57e1a4d307556f7d6200788ac",
"value": 1800
},
{
"scriptPubKey": "76a914b993e512cb186f3f1c3f556a09716a1580eb99a188ac",
"value": 90000
}
],
}

serialized transaction: "0100000001a8ff0305e43645cf7bcfb6ae8df6e121cb9fc43a55206ae22823b987aa28edb8000000006b4830450221008824
eee04a2fbe62d2c3ee330eb2523b2c0188240714bb1d893aced1c454fa9a02202d32dbccc2af1c4b830795f2fa8cd569a06e
e70cb9d836bbd510f0b45a47711b4121028580686976c0e6a7e44a78387913e2d7508ff2344d5f48669ba111dcd04170a8fe
ffffff0208070000000000001976a9146b0a9ed05da7223a1fe57e1a4d307556f7d6200788ac905f0100000000001976a914
b993e512cb186f3f1c3f556a09716a1580eb99a188ac09230900"

transaction id: "d8c5c42cbd1df7e48acab76fe05f2c9e612a20996fd37f4ffd4dc251385b6ba3" </pre>

===Explanation===

The double SHA256 hash enables network participants to identify and communicate transactions efficiently. They are used at all levels of the ecosystem, including [[Simplified Payment Verification|wallets]] and [[Block explorer|block explorers]].

Transaction ids are used extensively in the [[Protocol|peer-to-peer protocol]]. For example, peers on the network synchronize their transaction database using a 3 message sequence. A node will send out an ''inv'' message containing one or more transaction ids. In the case that the receiving node/peer does not have a copy of the full transaction, he can respond with a ''gettransaction'' message containing the transaction id. This is responded to with a ''tx'' message containing the full serialized transaction. Using transaction ids to broadcast transaction database information greatly reduces the volume of data that has to be sent over the network.

The double hash property can be used in another interesting way. The user can know that a corresponding party has a copy of the full TX by requesting the intermediate hash, which can only be generated by hashing the full transaction. This 'proof of possession' is present across Bitcoin and enables complex functionality and checking of resources when Bitcoin is being used in a fully peer to peer environment.

==See Also==

* [[Bitcoin Transactions]]
* [[Transaction Malleability]]
* [[Transaction Pools]]

SIGHASH flags

2020-02-16T18:27:18Z

Steve:

A SIGHASH flag is used to indicate which part of the transaction is signed by the [[Elliptic Curve Digital Signature Algorithm| ECDSA signature]]. The mechanism provides a flexibility in constructing transactions. There are in total 6 different flag combinations that can be added to a digital signature in a transaction. Note that different inputs can use different SIGHASH flags enabling complex compositions of spending conditions.

{| 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 tables below illustrate what is signed and what is not signed in an ECDSA siganture depending on the SIGHASH type used.

==Items that are ''always'' signed==

The signature on any input always signs the [[TXID]] and [[VOUT]] that comprise the Outpoint being spent as well as the [[Version|version]] of the protocol that the transaction is being evaluated under and the [[nLocktime|locktime]] being applied to the transaction.

{| class="wikitable" style="text-align: center;"
|colspan="4" style="font-style: italic; width: 600px;"|TxID
|-
|colspan="4" style="background: #abebc6;"|Version
|-
|colspan="4" style="background: #abebc6;"|Locktime
|-
|colspan="2" style="width: 50%;"|Inputs
|colspan="2" style="width: 50%;"|Outputs
|-
|
|style="font-style: italic;"|Unlocking Script
|
|style="font-style: italic;"|Locking Script
|- style="height: 7em;"
|style="background-color:#abebc6; font-style: italic;"|Outpoint A
|.....Sig Pa, Tx.....
|Xa BSV
|[ChecksigP1]
|- style="height: 7em;"
|style="font-style: italic;"|Outpoint B
|.....Sig Pb, Tx.....
|Xb BSV
|[ChecksigP2]
|-
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|- style="height: 7em;"
|style="font-style: italic;"|Outpoint N
|.....Sig PN, Tx.....
|XN BSV
|[ChecksigPm]
|}

==Items that are ''never'' signed==

Unlocking scripts are ''never'' signed

{| class="wikitable" style="text-align: center;"
|colspan="4" style="font-style: italic; width: 600px;"|TxID
|-
|colspan="4"|Version
|-
|colspan="4"|Locktime
|-
|colspan="2" style="width: 50%;"|Inputs
|colspan="2" style="width: 50%;"|Outputs
|-
|
|style="font-style: italic;"|Unlocking Script
|
|style="font-style: italic;"|Locking Script
|- style="height: 7em;"
|style="font-style: italic;"|Outpoint A
|style="background: #f5b7b1;"|.....Sig Pa, Tx.....
|Xa BSV
|[ChecksigP1]
|- style="height: 7em;"
|style="font-style: italic;"|Outpoint B
|style="background: #f5b7b1;"|.....Sig Pb, Tx.....
|Xb BSV
|[ChecksigP2]
|-
|style="font-style: bold;"|...
|style="font-style: bold; background: #f5b7b1;"|...
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|- style="height: 7em;"
|style="font-style: italic;"|Outpoint N
|style="background: #f5b7b1;"|.....Sig PN, Tx.....
|XN BSV
|[ChecksigPm]
|}

==SIGHASH_ALL==

SIGHASH_ALL signs all inputs and outputs used to build the transaction. Once an input signed with SIGHASH_ALL is added to a transaction, the transaction's details cannot be changed without that signature being invalidated.

{| class="wikitable" style="text-align: center;"
|colspan="4" style="font-style: italic; width: 600px;"|TxID
|-
|colspan="4" style="background: #abebc6;"|Version
|-
|colspan="4" style="background: #abebc6;"|Locktime
|-
|colspan="2" style="width: 50%;"|Inputs
|colspan="2" style="width: 50%;"|Outputs
|-
|
|style="font-style: italic;"|Unlocking Script
|
|style="font-style: italic;"|Locking Script
|- style="height: 7em;"
|style="background-color:#abebc6; font-style: italic;"|Outpoint A
|.....Sig Pa, Tx.....
|style="background-color:#abebc6;"|Xa BSV
|style="background-color:#abebc6;"|[ChecksigP1]
|- style="height: 7em;"
|style="background-color:#abebc6;font-style: italic;"|Outpoint B
|.....Sig Pb, Tx.....
|style="background-color:#abebc6"|Xb BSV
|style="background-color:#abebc6"|[ChecksigP2]
|-
|style="font-style: bold; background-color:#abebc6;"|...
|style="font-style: bold;"|...
|style="font-style: bold; background-color:#abebc6;"|...
|style="font-style: bold; background-color:#abebc6;"|...
|- style="height: 7em;"
|style="background-color:#abebc6; font-style: italic;"|Outpoint N
|.....Sig PN, Tx.....
|style="background-color:#abebc6"|XN BSV
|style="background-color:#abebc6"|[ChecksigPm]
|}

==SIGHASH_SINGLE==

SIGHASH_SINGLE signs all inputs and the output that shares the same index as the input being signed. If that output or any inputs are changed that signature becomes invalidated.

{| class="wikitable" style="text-align: center;"
|colspan="4" style="font-style: italic; width: 600px;"|TxID
|-
|colspan="4" style="background: #abebc6;"|Version
|-
|colspan="4" style="background: #abebc6;"|Locktime
|-
|colspan="2" style="width: 50%;"|Inputs
|colspan="2" style="width: 50%;"|Outputs
|-
|
|style="font-style: italic;"|Unlocking Script
|
|style="font-style: italic;"|Locking Script
|- style="height: 7em;"
|style="background-color:#abebc6; font-style: italic;"|Outpoint A
|.....Sig Pa, Tx.....
|style="background-color:#abebc6;"|Xa BSV
|style="background-color:#abebc6;"|[ChecksigP1]
|- style="height: 7em;"
|style="background-color:#abebc6;font-style: italic;"|Outpoint B
|.....Sig Pb, Tx.....
|Xb BSV
|[ChecksigP2]
|-
|style="font-style: bold; background-color:#abebc6;"|...
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|- style="height: 7em;"
|style="background-color:#abebc6; font-style: italic;"|Outpoint N
|.....Sig PN, Tx.....
|XN BSV
|[ChecksigPm]
|}

==SIGHASH_NONE==

SIGHASH_NONE signs all inputs and no outputs. Any output can be changed without invalidating the signature however if any inputs are changed that signature becomes invalidated.

{| class="wikitable" style="text-align: center;"
|colspan="4" style="font-style: italic; width: 600px;"|TxID
|-
|colspan="4" style="background: #abebc6;"|Version
|-
|colspan="4" style="background: #abebc6;"|Locktime
|-
|colspan="2" style="width: 50%;"|Inputs
|colspan="2" style="width: 50%;"|Outputs
|-
|
|style="font-style: italic;"|Unlocking Script
|
|style="font-style: italic;"|Locking Script
|- style="height: 7em;"
|style="background-color:#abebc6; font-style: italic;"|Outpoint A
|.....Sig Pa, Tx.....
|Xa BSV
|[ChecksigP1]
|- style="height: 7em;"
|style="background-color:#abebc6;font-style: italic;"|Outpoint B
|.....Sig Pb, Tx.....
|Xb BSV
|[ChecksigP2]
|-
|style="font-style: bold; background-color:#abebc6;"|...
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|- style="height: 7em;"
|style="background-color:#abebc6; font-style: italic;"|Outpoint N
|.....Sig PN, Tx.....
|XN BSV
|[ChecksigPm]
|}

==SIGHASH_ALL|ANYONECANPAY==

`Once an input signed with SIGHASH_ALL|ANYONECANPAY is added to a transaction outputs cannot be changed or added without that signature being invalidated.

{| class="wikitable" style="text-align: center;"
|colspan="4" style="font-style: italic; width: 600px;"|TxID
|-
|colspan="4" style="background: #abebc6;"|Version
|-
|colspan="4" style="background: #abebc6;"|Locktime
|-
|colspan="2" style="width: 50%;"|Inputs
|colspan="2" style="width: 50%;"|Outputs
|-
|
|style="font-style: italic;"|Unlocking Script
|
|style="font-style: italic;"|Locking Script
|- style="height: 7em;"
|style="background-color:#abebc6; font-style: italic;"|Outpoint A
|.....Sig Pa, Tx.....
|style="background-color:#abebc6;"|Xa BSV
|style="background-color:#abebc6;"|[ChecksigP1]
|- style="height: 7em;"
|style="font-style: italic;"|Outpoint B
|.....Sig Pb, Tx.....
|style="background-color:#abebc6"|Xb BSV
|style="background-color:#abebc6"|[ChecksigP2]
|-
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|style="font-style: bold; background-color:#abebc6;"|...
|style="font-style: bold; background-color:#abebc6;"|...
|- style="height: 7em;"
|style="font-style: italic;"|Outpoint N
|.....Sig PN, Tx.....
|style="background-color:#abebc6"|XN BSV
|style="background-color:#abebc6"|[ChecksigPm]
|}

==SIGHASH_SINGLE|ANYONECANPAY==

SIGHASH_SINGLE|ANYONECANPAY signs the input being signed and the output that shares the same index. If that output is changed that signature becomes invalidated.

{| class="wikitable" style="text-align: center;"
|colspan="4" style="font-style: italic; width: 600px;"|TxID
|-
|colspan="4" style="background: #abebc6;"|Version
|-
|colspan="4" style="background: #abebc6;"|Locktime
|-
|colspan="2" style="width: 50%;"|Inputs
|colspan="2" style="width: 50%;"|Outputs
|-
|
|style="font-style: italic;"|Unlocking Script
|
|style="font-style: italic;"|Locking Script
|- style="height: 7em;"
|style="background-color:#abebc6; font-style: italic;"|Outpoint A
|.....Sig Pa, Tx.....
|style="background-color:#abebc6;"|Xa BSV
|style="background-color:#abebc6;"|[ChecksigP1]
|- style="height: 7em;"
|style="font-style: italic;"|Outpoint B
|.....Sig Pb, Tx.....
|Xb BSV
|[ChecksigP2]
|-
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|- style="height: 7em;"
|style="font-style: italic;"|Outpoint N
|.....Sig PN, Tx.....
|XN BSV
|[ChecksigPm]
|}

==SIGHASH_NONE|ANYONECANPAY==

SIGHASH_NONE|ANYONECANPAY signs a single inputs and no outputs. This type of signature can be used to easily assign funds to a person or smart-contract without creating an on-chain action.

{| class="wikitable" style="text-align: center;"
|colspan="4" style="font-style: italic; width: 600px;"|TxID
|-
|colspan="4" style="background: #abebc6;"|Version
|-
|colspan="4" style="background: #abebc6;"|Locktime
|-
|colspan="2" style="width: 50%;"|Inputs
|colspan="2" style="width: 50%;"|Outputs
|-
|
|style="font-style: italic;"|Unlocking Script
|
|style="font-style: italic;"|Locking Script
|- style="height: 7em;"
|style="background-color:#abebc6; font-style: italic;"|Outpoint A
|.....Sig Pa, Tx.....
|Xa BSV
|[ChecksigP1]
|- style="height: 7em;"
|style="font-style: italic;"|Outpoint B
|.....Sig Pb, Tx.....
|Xb BSV
|[ChecksigP2]
|-
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|style="font-style: bold;"|...
|- style="height: 7em;"
|style="font-style: italic;"|Outpoint N
|.....Sig PN, Tx.....
|XN BSV
|[ChecksigPm]
|}

==Use cases==
SIGHASH flags are useful 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 keeping 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 anyone to add their desired outputs to the transaction to claim the funds 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

Simplified Payment Verification

2020-02-16T18:22:45Z

Steve:

Simplified Payment Verification (SPV) is described in section 8 of the [[Bitcoin whitepaper]]. It allows a transaction recipient to prove that the sender has control of the source funds of the payment they are offering 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]]. This does not guarantee that the funds have not been previously spent, this assurance is received by submitting the transaction to the Bitcoin miners. However, in such a case the SPV proof acts as strong evidence of fraud backed by legally recognised digital signature technology.

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 transactions relating to them (an extremely difficult 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 buried 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]]). Given that they will likely receive notification and proof of a fraud attempt within seconds, they will not want to maintain a copy of the entire blockchain to check against, because the risk they face does not justify the cost. SPV is adequate just as an instant contactless payment without a pin number although arguably the security of SPV is far superior given that discovery of fraud attempts is rapid. 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>.

Simplified Payment Verification

2020-02-16T18:04:55Z

Steve:

Simplified Payment Verification (SPV) is described in section 8 of the [[Bitcoin whitepaper]]. It allows a transaction recipient to prove that the sender has control of the source funds of the payment they are offering 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]]. This does not guarantee that the funds have not been previously spent, this assurance is received by submitting the transaction to the Bitcoin miners. However, in such a case the SPV proof acts as strong evidence of fraud backed by legally recognised digital signature technology.

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>.

Coinbase

2020-02-16T17:55:21Z

Steve:

'''Coinbase''' is the special name given to the first transaction in every block. These can also be called 'Generation Transactions'.

The winning miner creates this special transaction as part of the block templating process.

A coinbase transaction follows the same format as a normal transaction, except:
* It has exactly one txin
* This txin's prevout hash is 0000...0000.
* This txin's prevout index is 0xFFFFFFFF
* The txin's prevout script is an arbitrary byte array which has historically been used by miners to signal identity and pass messages from block winning nodes to the rest of the network
* The sum of the txout's values cannot exceed the total of the current [[Miner subsidy]] plus the mining fees paid by all other transactions included in the block

A part of the coinbase is also used as an 'extra nonce' during the block discovery process due to a single ASIC miner being able to test more combinations than allowed for in the 2^32 possible combinations that changing the nonce in the block header can create. The extra nonce field is incremented and the merkle root updated to generate a further 2^32 possible block hashes to try.

The winning miner can pay the coinbase value to multiple outputs as needed, and is also free to include zero value OP_FALSE OP_RETURN outputs in the transaction.

[[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP 0034]] mandated that the block height value be specified in the first item of the coinbase transaction. This value requires 4 bytes to store.

Prior to [[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP 0034]] the coinbase script size was between 2 and 100 bytes. Since the smallest number of bytes required to store the current Block Height is 1 byte for the length and 3 bytes for the value, a minimum of 4 bytes are required to store the block height. Therefore, post [[https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki BIP 0034]] the coinbase script size now is between 4 and 100 bytes in length.

''Note'': The maximum block height that can be represented in 3 bytes is (2 ^ (3 x 8 bits)) -1) == 16,777,215. At time of writing the block height is 614,372, therefore > 16 million more blocks can be represented with the current structure.

The block height of the [[Genesis_block]] is <u>zero</u>.

The upcoming innovation, [[MinerID]] will use the Coinbase transaction to present information to the network such as node identity, transaction pricing data and more. This data will use standard formats such that user wallets shall be able to read and parse the information, giving them up-to-date knowledge of which nodes are competitive on the network and more.

Digital signatures in Bitcoin

2020-02-16T17:34:11Z

Steve:

The [https://bitcoinsv.io/bitcoin.pdf Bitcoin whitepaper] describes an electronic coin as a chain of digital signatures. These digital signatures confer practical control, and in most cases, ownership over the coins held in any given script, and can be used as a record of custodial control to trace transfers of control 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==
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 Bitcoin SV ledger to be evaluated and signed allowing oracle functionality within Bitcoin transactions.
Currently no practical implementation of a Rabin signature in Bitcoin Script exists.

Digital signatures in Bitcoin

2020-02-16T17:31:57Z

Steve:

The [https://bitcoinsv.io/bitcoin.pdf Bitcoin whitepaper] describes an electronic coin as a chain of digital signatures. These digital signatures confer practical control, and in most cases, ownership over the coins held in any given script, and can be used as a record of custodial control to trace transfers of control 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.

Digital signatures in Bitcoin

2020-02-16T17:30:51Z

Steve:

The [https://bitcoinsv.io/bitcoin.pdf Bitcoin whitepaper] describes an electronic coin as a chain of digital signatures. These digital signatures confer practical control, and in most cases, ownership 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.

Bitcoin address

2020-02-16T17:22:03Z

Steve:

A Bitcoin address, or simply address, is an identifier of 26-35 alphanumeric characters, beginning with the number 1 that represents a public key hash to be used in a P2PKH output to create a [[Payments in Bitcoin|bitcoin payment]].
Bitcoin SV currently utilizes an address format delineated with the prefix number 1. e.g: <code>1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</code>.

==Privacy concerns==
If a Bitcoin user receives all of their payments into a single Bitcoin address it becomes very easy for anyone to discover how much money they have and what they are doing with that money. To protect user privacy, [[Address reuse]] is discouraged. This idea is part of the original plan for user protections in Bitcoin and is mentioned in '''Section 10: Privacy''' of the [http://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper] where it is stated:

''As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner.''

==Offline creation==
Creating addresses can be done without an Internet connection and does not require any contact or registration with the Bitcoin network. It is possible to create large batches of addresses offline using freely available software tools. Generating batches of addresses is useful in several scenarios, such as e-commerce websites where a unique pre-generated address is dispensed to each customer who chooses a "pay with Bitcoin" option. Newer "HD wallets" can generate a "master public key" token which can be used to allow untrusted systems (such as webservers) to generate an unlimited number of addresses without the ability to spend the bitcoins received.

==Addresses are often case sensitive and exact==
Old-style Bitcoin addresses are case-sensitive. Bitcoin addresses should be copied and pasted using the computer's clipboard wherever possible. If you copy a Bitcoin address by re-typing the address ‘character by character’, and each character is not transcribed exactly - including capitalization - the incorrect address will most likely be rejected by the Bitcoin SV wallet software. You will have to check your entry and try again.

Due to the presence of a 4 byte checksum, the probability that a mistyped address is accepted as being valid is 1 in 2<sup>32</sup> , that is, approximately 1 in 4.29 billion. Importantly, in this rare case, a payee providing a payer with an incorrect address will lead to the payee being unable to ever unlock the funds sent to said incorrect address.

==Proving you receive with an address==
Most Bitcoin wallets have a function to "sign" a message, proving the entity receiving funds with an address has agreed to the message. This can be used to, for example, finalise a contract in a cryptographically provable way prior to making payment for it.

Some services will also piggy-back on this capability by dedicating a specific address for authentication only, in which case the address should never be used for actual Bitcoin transactions. When you login to or use their service, you will provide a signature proving you are the same person with the pre-negotiated address.

Current standards for message signatures are only compatible with "version zero" bitcoin addresses (that begin with the number 1).

==Address validation==
If you would like to validate a Bitcoin address in an application, it is advisable to use a method from [https://bitcointalk.org/index.php?topic=1026.0 this thread] rather than to just check for string length, allowed characters, or that the address starts with a 1. Validation may also be done using open source code available in [http://rosettacode.org/wiki/Bitcoin/address_validation various languages] or with an [http://lenschulwitz.com/base58 online validating tool].

==What's in an address==
Most Bitcoin SV addresses are 34 characters. They consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter "O", uppercase letter "I", lowercase letter "l", and the number "0" are never used to prevent visual ambiguity.

Some Bitcoin SV addresses can be shorter than 34 characters (as few as 26) and still be valid. A significant percentage of Bitcoin addresses are only 33 characters, and some addresses may be even shorter. Every Bitcoin address stands for a number. These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.

Several of the characters inside a Bitcoin address are used as a checksum so that typographical errors can be automatically found and rejected. The checksum also allows Bitcoin software to confirm that a 33-character (or shorter) address is in fact valid and is not simply an address with a missing character.

==Testnet==
Addresses on the Bitcoin SV Testnet are generated with a different address version, which results in a different prefix.

==Misconceptions==
===Address reuse===

Addresses are not intended to be used more than once, and doing so has numerous problems associated.
See the dedicated article on [[Address reuse| address reuse]] for more details.

===Address balances===
It is important to note that addresses are not wallets nor accounts, and do not carry balances. Addresses only receive funds, the transfer of funds should not be seen at any time as the funds being sent ‘from’ an address. Unfortunately, services and software have contributed to this confusion by displaying ‘bitcoins received with an address - bitcoins sent in random unrelated transactions’ as an "address balance". However, this “address balance” value is not meaningful; it does not imply that the recipient of the bitcoins sent to the address had spent them, nor that said recipient had retained the bitcoins received.

As an example of where such a misunderstanding can be problematic, are occasions where individual would believe that their ‘address contains 3BSV’. They submit a transaction that spends 0.5BSV believing the ‘address now contained 2.5BSV’ when, in actuality, it contained zero. The absent 2.5BSV would have been transferred to a change address for which efforts had not been made to have this change address backed up, causing or risking a permanent loss of funds. This has happened on a few occasions to users of paper wallets.

==="From" addresses===
Bitcoin SV transactions do not have any kind of origin-, source- or "from" address.

==See Also==
* [[Technical background of Bitcoin addresses]]
* [[Elliptic Curve Digital Signature Algorithm]]
* [[Wallets and key management]]
* [[Base58Check encoding]]

Seed phrase

2020-02-16T17:15:02Z

Steve:

A '''seed phrase''', '''seed recovery phrase''' or '''backup seed phrase''' is a list of words which correspond to the master private key of a Bitcoin SV wallet. In typical usage, a wallet will generate a seed phrase and instruct the user to write it down on paper. If the user's computer breaks or their hard drive becomes corrupted, they can download the same wallet software again and use the paper backup to deterministically re-generate their wallet. Seed phrases are the most frequently encountered means of backing up Bitcoin SV wallets.

Anybody with access to the phrase can steal the bitcoins, so it must be kept safe. Phrases should not be transmitted electronically and should never be written on any website.

== Example ==

An example of a seed phrase is:

witch collapse practice feed shame open despair creek road again ice least

The word order is important.

== Explanation ==

A simplified explanation of how seed phrases work is that the wallet software has a list of words taken from a dictionary, with each word assigned to a number. The words in the seed phrase are each converted to their corresponding number and concatenated to generate the seed integer to a [[Deterministic wallet|deterministic wallet]]. From this seed integer the wallet generates all [[Private Keys|key pairs]] used in the wallet.

The English-language wordlist for the BIP39 standard has 2048 words, so if the phrase contained only 12 random words, the number of possible combinations would be 2048^12 = 2^132 and the phrase would have 132 bits of security. However, some of the data in a BIP39 phrase is not random (see: [https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#Generating_the_mnemonic BIP39: Generating the mnemonic]), so the actual security of a 12-word BIP39 seed phrase is only 128 bits.

== Two-Factor Seed Phrases ==

Several wallets enable their users to generate seed phrases with an added layer of encryption to prevent someone who discovers the words from accessing the wallet. The password can be used to create a two-factor seed phrase where both ''"something you have"'' plus ''"something you know"'' is required to recover the wallet.

This works by the wallet creating a seed phrase and asking the user for a password. Then both the seed phrase and extra word are required to recover the wallet. [https://electrumsv.io/ ElectrumSV] and some other wallets call the passphrase a '''"seed extension"''', '''"extension word"''' or '''"13th/25th word"'''. The BIP39 standard defines a way of passphrase-protecting a seed phrase. A similar scheme is also used in the Electrum SV standard. If a passphrase is not present, an empty string "" is used instead.

== Storing Seed Phrases for the Long Term ==

Most people write down phrases on paper but they can be stored in many other ways such as [[Brainwallet|memorizing]], engraving on metal, writing in the margins of a book or any other creative and inventive way.

For storing on paper writing with pencil is much better than pen [http://www.joethorn.net/blog/2011/12/07/pencil-does-not-fade Pencil Does Not Fade] [https://www.quora.com/How-do-I-maintain-a-paper-notebook-that-can-remain-for-years How do I maintain a paper notebook that can remain for years?]. Paper should be acid-free or archival paper, and stored in the dark avoiding extremes of heat and moisture [https://www.loc.gov/preservation/care/deterioratebrochure.html Essential facts about preservation of Paper] [https://www.quora.com/If-I-write-with-a-pencil-on-my-notebook-will-the-writing-last-for-a-long-time-say-50-years-or-will-it-just-fade-away-gradually Writing in a notebook with pencil] [http://copar.org/bulletin14.htm CoPAR: Creating records that will last] .

== Word Lists ==

Generally a seed phrase only works with the same wallet software that created it. If storing for a long period of time it's a good idea to write the name of the wallet too.

The BIP39 English word list has each word being uniquely identified by the first four letters, which can be useful when space to write them is scarce.

* [https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md BIP39 wordlists]
* [https://github.com/spesmilo/electrum/blob/1.9.8/lib/mnemonic.py Electrum old-style wordlist]
* [https://github.com/spesmilo/electrum/blob/master/electrum/wordlist/english.txt Electrum new-style wordlist]

== Alternative name "Mnemonic Phrase" ==

Seed phrases are sometimes called "mnemonic phrases" especially in older literature. This is a bad name because the word mnemonic implies that the phrase should be memorized. It is less misleading to call them seed phrases.

== The power of backups ==

An especially interesting aspect in the power of paper backups is allowing your money to be two places at once. You can store backups on multiple devices/physical media in different locations and with password encryption. With that one can carry $100,000 which can instantly be moved to a phone or transferred yet with total security. If it's stolen then there is no risk because it is backed up elsewhere. [https://www.reddit.com/r/Bitcoin/comments/2hmnru/poll_do_you_use_paper_wallets_why_why_not_what]

== See Also ==

* [[Deterministic wallet]]
* [[Brainwallet]]

Transaction Pools

2020-02-16T17:05:22Z

Steve:

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 ''getminingcandidate'' or the older ''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

Confirmation

2020-02-16T17:03:06Z

Steve:

'''Bitcoin transaction confirmation''' is the process of finalization a transaction with an economically expensive attestation by the Mining network that the transaction is valid and does not conflict with any previously seen transactions. One of the key functions of Bitcoin is that it solves the problem of [[Double-spending|double-spending]] by establish the order in which conflicting transactions have been publicly broadcast on the network. [https://bitcoinsv.io/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]] if the including transaction fee is sufficient to satisfy most miners.

==How Bitcoin transaction are confirmed==
A transaction is the exchange of information between parties. That information can be a quantity of [[Satoshis}, tokens or data of some other kind. Confirmation occurs when that transaction is included in a block that is added to the Bitcoin [[Block chain]]. When a user wishes to have a transaction confirmed, the complete transaction is broadcast from their wallet to miners in the network who verify that it is valid.
Once validated, [[Mining|miners]] will decide whether or not to include this transaction in their block template and attempt to mine it.
When a miner discovers a block that includes the transaction, it is considered '''confirmed'''. Each time a new block is added to the chain, the transaction is said to be confirmed again with the number of confirmations being the number of blocks added to the ledger that build upon the block containing the transaction. This generally considered to be a measure of how difficult it would be for a dishonest miner to invalidate the transaction by mining a longer competing chain containing a double spend.

== Bitcoin SV Confirmation Time ==
Typically, a transaction that is sent to the network with fees that adhere to the acceptance rate of X% of the network's hash rate will have X% chance of being mined in the next block.

For example, if it is known that 20% of nodes will accept transactions at a given fee rate, the user can assume that there is a 20% chance of it being included in the next block, or conversely that it is likely to be mined in 1 of the next 5 blocks, or within a 50 minute timeframe.
For users who's transactions are less time critical, this is a mechanism to reduce transaction fees, especially in high volume applications.

==Confirmations in Commerce==
Transaction confirmations are a means for receivers to gain assurance that the information they have received is valid, immutable and backed by the proof of work on the network. For most applications, including small to medium value commerce, confirmations are not required however many businesses including cryptocurrency exchanges will make users wait for up to 6 confirmations before accepting funds for trade. Importantly, it is up to the user to set their own comfort threshold for doing business.

=See Also=

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

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

[[Category:Technical]]

Confirmation

2020-02-16T16:56:37Z

Steve:

'''Bitcoin transaction confirmation''' is the process of finalization a transaction with an economically expensive attestation by the Mining network that the transaction is valid and does not conflict with any previously seen transactions. One of the key functions of Bitcoin is that it solves the problem of [[Double-spending|double-spending]] by establish the order in which conflicting transactions have been publicly broadcast on the network. [https://bitcoinsv.io/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 Bitcoin transaction are confirmed==
A transaction is the exchange of information between parties. That information can be a quantity of [[Satoshis}, tokens or data of some other kind. Confirmation occurs when that transaction is included in a block that is added to the Bitcoin [[Block chain]]. When a user wishes to have a transaction confirmed, the complete transaction is broadcast from their wallet to miners in the Core network who verify that it is valid.
Once validated, [[Mining|miners]] will decide whether or not to include this transaction in their block template and attempt to mine it.
When a miner discovers a block that includes the transaction, it is considered '''confirmed'''. Each time a new block is added to the chain, the transaction is said to be confirmed again with the number of confirmations being the number of blocks added to the ledger that build upon the block containing the transaction.

== Bitcoin SV Confirmation Time ==
Typically, a transaction that is sent to the network with fees that adhere to the acceptance rate of X% of the network's hash rate will have X% chance of being mined in the next block.

For example, if it is known that 20% of nodes will accept transactions at a given fee rate, the user can assume that there is a 20% chance of it being included in the next block, or conversely that it is likely to be mined in 1 of the next 5 blocks, or within a 50 minute timeframe.
For users whos transactions are less time critical, this is a great way to save money, especially in high volume applications.

==Confirmations in Commerce==
Transaction confirmations are a means for receivers to be certain that the information they have received is valid and backed by the proof of work on the network. For most applications, including small to medium value commerce, confirmations are not required however many businesses including cryptocurrency exchanges will make users wait for up to 6 confirmations before accepting funds for trade. Importantly, it is up to the user to set their own comfort threshold for doing business.

=See Also=

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

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

[[Category:Technical]]

Difficulty

2020-02-16T16:49:56Z

Steve:

''See also: [[Target]]''

=== What is difficulty? ===

Difficulty is a measure of how difficult it is to find a hash below a given [[target]]. Difficulty answers the question: "how many times more difficult is it to mine a block now, compared with how difficult it was to mine the [[Genesis block|Genesis Block]]?". It has a close relationship with target but is not the same thing. Rather it has an inverse relationship where a higher difficult implies a lower target value.

The Bitcoin network has a global block difficulty. Valid blocks must have a hash below this target.
Mining pools also have a pool-specific share difficulty setting a lower limit for shares.

=== How often does the network difficulty change? ===

See [[Target|target]].

=== What is the formula for difficulty? ===
difficulty = difficulty_1_target / current_target

''target is a 256 bit number''

''difficulty_1_target is the target used in the Genesis Block and represents a difficulty of 1.''

difficulty_1_target can be different for various ways to measure difficulty.
Traditionally, it represents a hash where the leading 32 bits are zero and the rest are one (this is known as "pool difficulty" or "pdiff").
The Bitcoin protocol represents targets as a custom floating point type with limited precision; as a result, Bitcoin clients often approximate difficulty based on this (this is known as "bdiff").

===How is difficulty stored in blocks?===

Each block stores a packed representation in its block header (called [[Block hashing algorithm|Bits]]) for its actual hexadecimal [[target]]. The target can be derived from Bits via a predefined formula. For example, if the packed target in the block is 0x1b0404cb, the hexadecimal target is:
0x0404cb * 2**(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000

Note that the 0x0404cb value is a signed value in this format. The largest legal value for this field is 0x7fffff. To make a larger value you must shift it down one full byte. Also 0x008000 is the smallest positive valid value.

===How is difficulty calculated? What is the difference between bdiff and pdiff?===

The highest possible target (difficulty 1) is defined as 0x1d00ffff, which gives us a hex target of
0x00ffff * 2**(8*(0x1d - 3)) = 0x00000000FFFF0000000000000000000000000000000000000000000000000000

It should be noted that pooled mining often uses non-truncated targets, which puts "pool difficulty 1" at
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

So the difficulty at 0x1b0404cb is therefore:
0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
0x00000000000404CB000000000000000000000000000000000000000000000000
= 16307.420938523983 (bdiff)
And:
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF /
0x00000000000404CB000000000000000000000000000000000000000000000000
= 16307.669773817162 (pdiff)

Here's a fast way to calculate bitcoin difficulty. It uses a modified Taylor series for the logarithm (you can see tutorials on flipcode and wikipedia) and relies on logs to transform the difficulty calculation:

<source lang="cpp">
#include <iostream>
#include <cmath>

inline float fast_log(float val)
{
int * const exp_ptr = reinterpret_cast <int *>(&val);
int x = *exp_ptr;
const int log_2 = ((x >> 23) & 255) - 128;
x &= ~(255 << 23);
x += 127 << 23;
*exp_ptr = x;

val = ((-1.0f/3) * val + 2) * val - 2.0f/3;
return ((val + log_2) * 0.69314718f);
}

float difficulty(unsigned int bits)
{
static double max_body = fast_log(0x00ffff), scaland = fast_log(256);
return exp(max_body - fast_log(bits & 0x00ffffff) + scaland * (0x1d - ((bits & 0xff000000) >> 24)));
}

int main()
{
std::cout << difficulty(0x1b0404cb) << std::endl;
return 0;
}
</source>

To see the math to go from the normal difficulty calculations (which require large big ints bigger than the space in any normal integer) to the calculation above, here's some python:

<source lang="python">
import decimal, math
l = math.log
e = math.e

print 0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3)))
print l(0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3))))
print l(0x00ffff * 2**(8*(0x1d - 3))) - l(0x0404cb * 2**(8*(0x1b - 3)))
print l(0x00ffff) + l(2**(8*(0x1d - 3))) - l(0x0404cb) - l(2**(8*(0x1b - 3)))
print l(0x00ffff) + (8*(0x1d - 3))*l(2) - l(0x0404cb) - (8*(0x1b - 3))*l(2)
print l(0x00ffff / float(0x0404cb)) + (8*(0x1d - 3))*l(2) - (8*(0x1b - 3))*l(2)
print l(0x00ffff / float(0x0404cb)) + (0x1d - 0x1b)*l(2**8)
</source>

=== What is the current difficulty? ===
[https://whatsonchain.com/ Current difficulty]

=== What is the maximum difficulty? ===

There is no minimum target. The maximum difficulty is roughly: maximum_target / 1 (since 0 would result in infinity), which is a ridiculously huge number (about 2^224).

The actual maximum difficulty is when current_target=0, but we would not be able to calculate the difficulty if that happened. (fortunately it never will, so we're ok.)

The difficulty can rise by a maximum of 400% of the current difficulty, or by a factor of 4 in a single adjustment.

=== Can the network difficulty decrease? ===
Yes it can. See discussion in [[target]].

The network's difficulty can adjust downwards by up to 75% of the current difficulty in a single adjustment.

=== What is the minimum difficulty? ===
The minimum difficulty, when the target is at the maximum allowed value, is 1. This is the difficulty of the [[Genesis block]].

=== What network hash rate results in a given difficulty? ===
The difficulty is adjusted every 2016 blocks based on the [[Block_timestamp|time]] it took to find the previous 2016 blocks. At the desired rate of one block each 10 minutes, 2016 blocks would take exactly two weeks to find. If the previous 2016 blocks took more than two weeks to find, the difficulty is reduced. If they took less than two weeks, the difficulty is increased. The change in difficulty is in proportion to the amount of time over or under two weeks the previous 2016 blocks took to find.

To find a block, the hash must be less than the target. The hash is effectively a random number between 0 and 2**256-1. The offset for difficulty 1 is
0xffff * 2**208
and for difficulty D is
(0xffff * 2**208)/D

The expected number of hashes we need to calculate to find a block with difficulty D is therefore
D * 2**256 / (0xffff * 2**208)
or just
D * 2**48 / 0xffff

The difficulty is set such that the previous 2016 blocks would have been found at the rate of one every 10 minutes, so we were calculating (D * 2**48 / 0xffff) hashes in 600 seconds. That means the hash rate of the network was
D * 2**48 / 0xffff / 600
over the previous 2016 blocks. Can be further simplified to
D * 2**32 / 600
without much loss of accuracy.

At difficulty 1, that is around 7 Mhashes per second.

At the time of writing, the difficulty is 22012.4941572, which means that over the previous set of 2016 blocks found the average network hash rate was
22012.4941572 * 2**32 / 600 = around 157 Ghashes per second.

=== How soon might I expect to generate a block? ===
The average time to find a block can be approximated by calculating:
time = difficulty * 2**32 / hashrate
where difficulty is the current difficulty, hashrate is the number of hashes your miner calculates per second, and time is the average in seconds between the blocks you find.

For example, using Python we calculate the average time to generate a block using a 1Ghash/s mining rig when the difficulty is 20000:
$ python -c "print 20000 * 2**32 / 10**9 / 60 / 60.0"
23.85
and find that it takes just under 24 hours on average.

Remember - any one grinding of the hash stands the same chance of "winning" as any other. The numbers game is how many attempts hardware can make per second.

==Related Links==

* See also: [[Target]]

Difficulty

2020-02-16T16:48:16Z

Steve:

''See also: [[Target]]''

=== What is difficulty? ===

Difficulty is a measure of how difficult it is to find a hash below a given [[target]]. Difficulty answers the question: "how many times more difficult is it to mine a block now, compared with how difficult it was to mine the [[Genesis block|Genesis Block]]?". It has a close relationship with target but is not the same thing. Rather it has an inverse relationship where a higher difficult implies a lower target value.

The Bitcoin network has a global block difficulty. Valid blocks must have a hash below this target.
Mining pools also have a pool-specific share difficulty setting a lower limit for shares.

=== How often does the network difficulty change? ===

See [[Target|target]].

=== What is the formula for difficulty? ===
difficulty = difficulty_1_target / current_target

''target is a 256 bit number''

''difficulty_1_target is the target used in the Genesis Block and represents a difficulty of 1.''

difficulty_1_target can be different for various ways to measure difficulty.
Traditionally, it represents a hash where the leading 32 bits are zero and the rest are one (this is known as "pool difficulty" or "pdiff").
The Bitcoin protocol represents targets as a custom floating point type with limited precision; as a result, Bitcoin clients often approximate difficulty based on this (this is known as "bdiff").

===How is difficulty stored in blocks?===

Each block stores a packed representation in its block header (called [[Block hashing algorithm|Bits]]) for its actual hexadecimal [[target]]. The target can be derived from Bits via a predefined formula. For example, if the packed target in the block is 0x1b0404cb, the hexadecimal target is:
0x0404cb * 2**(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000

Note that the 0x0404cb value is a signed value in this format. The largest legal value for this field is 0x7fffff. To make a larger value you must shift it down one full byte. Also 0x008000 is the smallest positive valid value.

===How is difficulty calculated? What is the difference between bdiff and pdiff?===

The highest possible target (difficulty 1) is defined as 0x1d00ffff, which gives us a hex target of
0x00ffff * 2**(8*(0x1d - 3)) = 0x00000000FFFF0000000000000000000000000000000000000000000000000000

It should be noted that pooled mining often uses non-truncated targets, which puts "pool difficulty 1" at
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

So the difficulty at 0x1b0404cb is therefore:
0x00000000FFFF0000000000000000000000000000000000000000000000000000 /
0x00000000000404CB000000000000000000000000000000000000000000000000
= 16307.420938523983 (bdiff)
And:
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF /
0x00000000000404CB000000000000000000000000000000000000000000000000
= 16307.669773817162 (pdiff)

Here's a fast way to calculate bitcoin difficulty. It uses a modified Taylor series for the logarithm (you can see tutorials on flipcode and wikipedia) and relies on logs to transform the difficulty calculation:

<source lang="cpp">
#include <iostream>
#include <cmath>

inline float fast_log(float val)
{
int * const exp_ptr = reinterpret_cast <int *>(&val);
int x = *exp_ptr;
const int log_2 = ((x >> 23) & 255) - 128;
x &= ~(255 << 23);
x += 127 << 23;
*exp_ptr = x;

val = ((-1.0f/3) * val + 2) * val - 2.0f/3;
return ((val + log_2) * 0.69314718f);
}

float difficulty(unsigned int bits)
{
static double max_body = fast_log(0x00ffff), scaland = fast_log(256);
return exp(max_body - fast_log(bits & 0x00ffffff) + scaland * (0x1d - ((bits & 0xff000000) >> 24)));
}

int main()
{
std::cout << difficulty(0x1b0404cb) << std::endl;
return 0;
}
</source>

To see the math to go from the normal difficulty calculations (which require large big ints bigger than the space in any normal integer) to the calculation above, here's some python:

<source lang="python">
import decimal, math
l = math.log
e = math.e

print 0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3)))
print l(0x00ffff * 2**(8*(0x1d - 3)) / float(0x0404cb * 2**(8*(0x1b - 3))))
print l(0x00ffff * 2**(8*(0x1d - 3))) - l(0x0404cb * 2**(8*(0x1b - 3)))
print l(0x00ffff) + l(2**(8*(0x1d - 3))) - l(0x0404cb) - l(2**(8*(0x1b - 3)))
print l(0x00ffff) + (8*(0x1d - 3))*l(2) - l(0x0404cb) - (8*(0x1b - 3))*l(2)
print l(0x00ffff / float(0x0404cb)) + (8*(0x1d - 3))*l(2) - (8*(0x1b - 3))*l(2)
print l(0x00ffff / float(0x0404cb)) + (0x1d - 0x1b)*l(2**8)
</source>

=== What is the current difficulty? ===
[https://whatsonchain.com/ Current difficulty]

=== What is the maximum difficulty? ===

There is no minimum target. The maximum difficulty is roughly: maximum_target / 1 (since 0 would result in infinity), which is a ridiculously huge number (about 2^224).

The actual maximum difficulty is when current_target=0, but we would not be able to calculate the difficulty if that happened. (fortunately it never will, so we're ok.)

The difficulty can rise by a maximum of 400% of the current difficulty, or by a factor of 4.

=== Can the network difficulty decrease? ===
Yes it can. See discussion in [[target]].

The network's difficulty can adjust downwards by up to 75% of the current difficulty.

=== What is the minimum difficulty? ===
The minimum difficulty, when the target is at the maximum allowed value, is 1. This is the difficulty of the [[Genesis block]].

=== What network hash rate results in a given difficulty? ===
The difficulty is adjusted every 2016 blocks based on the [[Block_timestamp|time]] it took to find the previous 2016 blocks. At the desired rate of one block each 10 minutes, 2016 blocks would take exactly two weeks to find. If the previous 2016 blocks took more than two weeks to find, the difficulty is reduced. If they took less than two weeks, the difficulty is increased. The change in difficulty is in proportion to the amount of time over or under two weeks the previous 2016 blocks took to find.

To find a block, the hash must be less than the target. The hash is effectively a random number between 0 and 2**256-1. The offset for difficulty 1 is
0xffff * 2**208
and for difficulty D is
(0xffff * 2**208)/D

The expected number of hashes we need to calculate to find a block with difficulty D is therefore
D * 2**256 / (0xffff * 2**208)
or just
D * 2**48 / 0xffff

The difficulty is set such that the previous 2016 blocks would have been found at the rate of one every 10 minutes, so we were calculating (D * 2**48 / 0xffff) hashes in 600 seconds. That means the hash rate of the network was
D * 2**48 / 0xffff / 600
over the previous 2016 blocks. Can be further simplified to
D * 2**32 / 600
without much loss of accuracy.

At difficulty 1, that is around 7 Mhashes per second.

At the time of writing, the difficulty is 22012.4941572, which means that over the previous set of 2016 blocks found the average network hash rate was
22012.4941572 * 2**32 / 600 = around 157 Ghashes per second.

=== How soon might I expect to generate a block? ===
The average time to find a block can be approximated by calculating:
time = difficulty * 2**32 / hashrate
where difficulty is the current difficulty, hashrate is the number of hashes your miner calculates per second, and time is the average in seconds between the blocks you find.

For example, using Python we calculate the average time to generate a block using a 1Ghash/s mining rig when the difficulty is 20000:
$ python -c "print 20000 * 2**32 / 10**9 / 60 / 60.0"
23.85
and find that it takes just under 24 hours on average.

Remember - any one grinding of the hash stands the same chance of "winning" as any other. The numbers game is how many attempts hardware can make per second.

==Related Links==

* See also: [[Target]]

Target

2020-02-16T16:44:16Z

Steve:

The '''target''' is a 256-bit number (extremely large) that all Bitcoin clients share. The double SHA-256 [https://wiki.bitcoinsv.io/index.php/Mining#Hashing hash] of a [[Block hashing algorithm|block's header]] must be less than or equal to the current target for the block to be accepted by the network. The lower the target, the more [[difficulty|difficult]] it is to generate a block.

It's important to realize that block generation is not a long, set problem (like doing a million hashes), but more like a lottery. Each hash is a random number between 0 and the maximum value of a 256-bit number (2^256-1). If a hash is below the target, the node wins. If not, you increment the nonce (completely changing the hash) and try again.

The bitcoin network tries to produce one block every ten minutes on average. As mining hash power changes over time, it achieves this through changing the target value.

Historically (prior to forking from BTC in August 2017), Bitcoin changed its target every 2016 blocks (exactly two weeks if a block time of 10 minutes was kept perfectly). This change in the target is known as a 'difficulty adjustment'. Under the original difficulty adjustment paradigm, when adjusting the target, every bitcoin client compared the actual time it took to generate 2016 blocks with the two week goal, and modified the target by the percentage difference. A single retarget never changes the target by more than a factor of 4 either way to prevent large changes in difficulty.

After the hard fork of August 2017, Bitcoin changed the original difficulty adjustment algorithm to what was named the Emergency Difficulty Adjustment (EDA) algorithm. The EDA had the capacity to update the target value every time a new block was found (as opposed to every 2016 blocks), while still targeting a ten minute block time average. The EDA was changed to the Difficulty Adjustment Algorithm (DAA) on 17 November 2017 to address instabilities associated with the EDA. The DAA uses a moving average of the last 144 blocks to determine changes to the target and like the EDA, the target can change every block.

The reason the EDA (and later, it's improvement, the DAA) needed to be implemented was because of the forking off of BTC and adopting the new BCH ticker in August 2017. Because it was expected that BCH would garner significantly less hash power than BTC, measures were put in place so that block production on BCH would not slow to a crawl due to inheriting BTC's target difficulty and a small number of miners.

It is proposed that Bitcoin will move back to the original difficulty adjustment algorithm (still used by BTC) in the future.

===How is the target stored in blocks?===
Each block stores a packed representation in its block header (called [[Block hashing algorithm|Bits]]) for its actual hexadecimal target. The target can be derived from Bits via a predefined formula. For example, if the packed target in the block is 0x1b0404cb, the hexadecimal target is:
0x0404cb * 2**(8*(0x1b - 3)) = 0x00000000000404CB000000000000000000000000000000000000000000000000

Note that the 0x0404cb value is a signed value in this format. The largest legal value for this field is 0x7fffff. To make a larger value you must shift it down one full byte. Also 0x008000 is the smallest positive valid value.

=== What is the current target? ===
Check the [[Block hashing algorithm|Bits]] field of the most recent block on a [https://whatsonchain.com/ block explorer].

=== What is the maximum target? ===
The maximum target used by SHA256 mining devices is:
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Because Bitcoin stores the target as a floating-point type, this is truncated:
0x00000000FFFF0000000000000000000000000000000000000000000000000000

The maximum target is the target used in the [[Genesis block|Genesis Block]] and represents a [[difficulty]] of 1. Its packed representation as [[Block hashing algorithm|Bits]] is 0x1d00ffff.

Since a lower target makes Bitcoin generation more difficult, the maximum target is the ''lowest'' possible [[difficulty]].

==Related Links==
See also [[Difficulty]]

Block hashing algorithm

2020-02-16T16:32:04Z

Steve:

Bitcoin mining uses the [[hashcash]] proof of work function; the hashcash algorithm requires the following parameters: a service string, a nonce, and a counter. In bitcoin the service string is encoded in the block header data structure, and includes a version field, the hash of the previous block, the root hash of the merkle tree of all transactions in the block, the current time, and the difficulty. Bitcoin miners commonly make use of two nonce fields. One in the block header and a second one in the extraNonce field which is part of the coinbase transaction, which is stored as the left most leaf node in the merkle tree (the coinbase is the special first transaction in the block). The counter parameter is equivilent to the nonce field in the header, it is relatively small at 32-bits so each time it wraps the extraNonce field must be incremented (or otherwise changed) to avoid repeating work.
When mining bitcoin, the hashcash algorithm repeatedly hashes the block header while incrementing the counter & extraNonce fields. Incrementing the extraNonce field entails recomputing the merkle tree root, as the coinbase transaction is changed.

==Block Header==
A block header contains these fields:
{| class="wikitable"
|-
! Field
! Purpose
! Updated when...
! Size (Bytes)
|-
|Version
|Block version number
|You upgrade the software and it specifies a new version
|4
|-
|hashPrevBlock
|256-bit hash of the previous block header
|A new block comes in
|32
|-d
|hashMerkleRoot
|256-bit hash based on all of the transactions in the block
|A transaction is accepted
|32
|-
|Time
|Current [[block timestamp]] as seconds since 1970-01-01T00:00 UTC
|Every few seconds
|4
|-
|Bits
|Current [[target]] in compact format
|The [[difficulty]] is adjusted
|4
|-
|Nonce
|32-bit number (starts at 0)
|A hash is tried (increments)
|4
|}

The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions.

The format of target is a floating-point encoding using a 3 byte mantissa, the leading byte as exponent (where only the 5 lowest bits are used) and its base is 256.

The [[Nonce]] is increased by the mining machine, usually in a strictly linear way, to generate new hash results in an attempt to solve the proof of work for the block. Starting at 0, the field is incremented for each hash attempt. If the Nonce overflows (meaning 2^32 hash attempts have been made), the extraNonce portion of the [[Coinbase]] transaction is incremented, which changes the Merkle root and the Nonce value is reset to zero so a further 2^32 attempts can be made.

It is not possible for two nodes to be working on the same Merkle root because the Coinbase transaction is unique to that node, generating a different hash output. Every hash attempt made has the same chance of winning as every other hash calculated across the network.

==Endianess==
Note that the hash, which is a 256-bit number, has lots of leading zero bytes when stored or printed as a big-endian hexadecimal constant, but it has trailing zero bytes when stored or printed in little-endian. For example, if interpreted as a string and the lowest (or start of) the string address keeps lowest significant byte, it is little-endian.

Most block explorers display the hash values as big-endian numbers; notation for numbers is usual (leading digits are the most significant digits read from left to right).

Mining

2020-02-16T16:28:59Z

Steve:

== Introduction ==
'''Mining''' is the process where nodes in the Bitcoin [[Network]] assemble newly broadcast [[Bitcoin Transactions|bitcoin transactions]] into a data structure called a [[block]]. Nodes then compete to append their block to the public [[Block chain|blockchain]] by repeatedly mutating the block's header data structure, usually by incrementing the nonce field, the hashing it in an attempt to find a value that satisfies a difficult [[Proof of Work|proof-of-work]].

When a node finds a valid proof-of-work hash for a block, it broadcasts the block to all nodes. Other nodes accept this block only if all the transactions in it are valid and have not yet been included in a block. Other nodes in the network then express their acceptance of the block by building upon it to create the next block in the chain.

Every block is [[Block timestamp|timestamped]] and references the hash of the block preceding it. Blocks form a backward reinforcing, timestamped chain – a [[Timechain]], the precursor to the term ‘blockchain’.

The blockchain structures itself in a manner that is computationally and eonomically impractical to modify by any one entity. Due to this, transactions included in the blockchain are considered immutable. In addition to this quality, the blockchain establishes an authoritative order of these transactions throughout the network by establishing which out of any pair of conflicting transactions was seen first, thereby protecting users from [[Double-spending|attempts to re-spend coins]] that have already been spent elsewhere. This is the key innovation of mining and of bitcoin.

=== Nodes ===
Nodes are entities that run software that carries out the mining functions above. Nodes communicate using a [[P2P Network]] with its own protocol, and are the authors of the Bitcoin ledger and enforcers of the [[protocol]] rules.

Interestingly, the bitcoin whitepaper makes no reference to the term ‘miner’ or the concept of ‘mining’. These terms are encompassed within Satoshi Nakamoto’s description of a ‘node’. It is possible however to run the node client software without performing block assembly or proof-of-work. Such a setup can be used as an interface to the network for other systems such as block explorers, payment gateways and archives. Eventually it is expected that customised client software will be developed for each of these services so they will no longer be dependent on the node client for them to operate.

Computers that run a node client but which do not perform proof-of-work cannot append new blocks to the blockchain. This means they can neither express acceptance of valid blocks by working on extending them, nor reject invalid blocks by refusing to work on them. These computers exist as passive entities that follow the gatekeepers of the network, the miners.

=== Mempool ===
Before a bitcoin transaction can be committed to the blockchain it needs to be received and validated by a miner. If the miner deems the transaction valid, they add the transaction to one of several [[Protocol#mempool|mempools]]. Mempools are temporary transaction stores and can be used to hold transactions grouped in different ways such as transactions to be mined in the next block, transactions to watch, or transactions which cannot be mined due to an nLocktime/nSequence lock.

It is important to note every miner has their own mempools and that mempools vary across miners. It is also important to note that an individual transaction can be included in different mempools at the same time.

A miner takes the transactions to be mined in the next block and hashes them into a [[Protocol#Merkle_Trees|merkle tree]] structure and includes the resulting merkle root within a block header candidate [[Block hashing algorithm|block header]]. The miner then hashes this candidate block header, attempting to find a valid proof-of-work.

=== Hashing ===
A hash is a function that converts a string of data into a fixed length value that represents the original string, called the hash value. Every hash value is unique.

Hashing is a one-way function, meaning it is infeasible to determine what the input data is by looking at the hash produced from it. Conversely, it is trivial to run the same input data through the same hash function and reproduce the same hash. Because of this, a hash value of input data can be thought of as the digital fingerprint of that data. In bitcoin mining, the input data is the 80-byte [[Block hashing algorithm|block header]].

The hashing algorithm used in bitcoin mining is [[SHA-256]]. SHA-256 stands for Secure Hash Algorithm – 256 bit. Passing the same block header data through this algorithm will always output the same 256-bit number. However if the header data is modified even by a single a bit a completely different and unrelated 256-bit number will result.

Bitcoin mining passes the block header data through the SHA-256 algorithm twice (SHA-256d).

=== Proof-of-work ===
Bitcoin uses a [[Proof of Work]] function based on the earlier work of [[hashcash]].

A miner cannot create a new block without finding a valid proof-of-work hash for the block header they are hashing. To be valid, the SHA-256d hash (which is just a number) of the block header must be less than another number, called the [[target]]. The target value is defined by the [[Block hashing algorithm|Bits]] field in the block header that is being hashed.

The target adjusts so that the average time it takes for the entire network to find a valid proof-of-work hash is ten minutes.

Because of the extraordinarily large SHA-256 target space, it is extremely unlikely that any given hash will be below the target. As a result of this, hashing entities invest large amounts of capital into specialized hashing hardware along with the associated electricity costs in order to produce as many of these hashes as possible in a given time period. Therefore, the only way a miner can append a block to the blockchain is through a substantial commitment of operational expenditure – proof-of-work.

=== Incentive ===
The first transaction in every block is called the [[Coinbase]] transaction. The Coinbase transaction is a special transaction which pays bitcoins to the miner of the block. The Coinbase payment is made up of the [[Miner subsidy|subsidy]] amount and the sum of all [[transaction fees]] paid by transactions within the mined block.

== Competition ==

=== Propagation and validation ===
If a miner finds a valid proof-of-work for the block header they are hashing, they immediately announce this by sending the entire block to other miners. Meanwhile, they start working on finding the next block in the chain.

Competing miners receive this block and immediately check that all transactions within the block, as well as the proof-of-work are valid. If the block is valid they discontinue mining on top of the previous block and start working on hashing a new block header, building on the block just found by their competitor.

There are incentives at play here. First, winning 'miner A' strives to get their winning block to all other miners as quickly as possible. This reduces the possibility that competing 'miner B' (who found a valid block at approximately the same time) propagates their block to some miners before 'miner A' could. This opens up the possibility that 'miner A's' block could later be [[Orphan Block|orphaned]] and the Coinbase reward rendered invalid and unusable by 'miner A'. The degree of bandwidth and connectivity to other miners can be seen as a competitive advantage and as such, the mining network tends toward a densely connected, small world structure with high bandwidth.

There also exists a competitive advantage in validating transactions. When validating a block, each transaction's inputs must be looked up in the miner's [[VOUT|UTXO]] set to check they are unspent and the amount in satoshis is correct. Additionally, each input's locking and unlocking scripts need to be run by the miner to assess whether each transaction is valid.

=== Rejected blocks ===
At any given point in time, two or more independent miners may mine a block at the same time. In this situation, nodes can be in disagreement about which of these blocks should be the tip of the blockchain.

Miners always follow the longest chain they deem to be valid. Eventually another block will be found that builds on one of the competing chain tips. Miners then switch to this tip provided they consider it to be valid. As such, any fork scenario is eventually resolved back to one persistent chain through the actions of the majority of hash power.

In this scenario, blocks that don't end up forming part of the longest chain are rejected by the network and are called orphans. Orphaned blocks represent wasted effort on the behalf of a miner and an incentive to invest in infrastructure in order to reduce the frequency of these events. However, orphans do not reduce the overall revenues of the Bitcoin system as the wasted work is not factored into the difficulty adjustment, thus if a certain percentage of hashing work is wasted due to the orphaned blocks the difficulty will adjust downwards by a similar percentage, maintaining the same rate of valid block production overall. Additionally the fee paying transactions in the orphaned block will still be valid and included in the competing block or its descendants.

Competing valid blocks are not the only way that blocks end up being rejected. Any miner can refuse to build on any block for any reason. Such an action by a particular miner is only meaningful if the majority of miners carry out the same action. It is through this mechanism that the mining network can establish consensus on variables that are miner configurable - such as maximum block size. This is the basis of Nakamoto Consensus:

"They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism."

== The mining ecosystem ==

=== Asic mining ===
An application-specific integrated circuit, or ASIC, is a microchip designed and manufactured for a very specific purpose. ASICs designed for Bitcoin mining were first released in 2013. For the amount of power they consume, they are vastly more energy efficient than predecessor approaches to mining - using CPU, GPU or FPGA.

=== Pooled mining ===
As more and more miners competed for the limited supply of blocks, individuals found that they were working for months without finding a block and receiving any reward for their mining efforts. To address the variance in their income, miners started organizing themselves into pools so that blocks could be found more frequently and with rewards distributed among participating miners proportionally to their work contribution.

==== Stratum ====
Stratum is an open-source mining protocol used by many mining pools. Stratum facilitates coordination between the mining pool operator and individual mining machines.

==See also==
* [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper]

Mining

2020-02-16T16:09:16Z

Steve:

== Introduction ==
'''Mining''' is the process where nodes in the Bitcoin [[Network]] assemble newly broadcast [[Bitcoin Transactions|bitcoin transactions]] into a data structure called a [[block]]. Nodes then compete to append their block to the public [[Block chain|blockchain]] by repeatedly mutating the block's header data structure, usually by incrementing the nonce field, the hashing it in an attempt to find a value that satisfies a difficult [[Proof of Work|proof-of-work]].

When a node finds a valid proof-of-work hash for a block, it broadcasts the block to all nodes. Other nodes accept this block only if all the transactions in it are valid and have not yet been included in a block. Other nodes in the network then express their acceptance of the block by building upon it to create the next block in the chain.

Every block is [[Block timestamp|timestamped]] and references the hash of the block preceding it. Blocks form a backward reinforcing, timestamped chain – a [[Timechain]], the precursor to the term ‘blockchain’.

The blockchain structures itself in a manner that is computationally and eonomically impractical to modify by any one entity. Due to this, transactions included in the blockchain are considered immutable. In addition to this quality, the blockchain establishes an authoritative order of these transactions throughout the network by establishing which out of any pair of conflicting transactions was seen first, thereby protecting users from [[Double-spending|attempts to re-spend coins]] that have already been spent elsewhere. This is the key innovation of mining and of bitcoin.

=== Nodes ===
Nodes are entities that run software that carries out the mining functions above. Nodes communicate using a [[P2P Network]] with its own protocol, and are the maintainers of the Bitcoin ledger and guardians of the [[protocol]].

Interestingly, the bitcoin whitepaper makes no reference to the term ‘miner’ or the concept of ‘mining’. These terms are encompassed within Satoshi Nakamoto’s description of a ‘node’. It is possible however to run node client software without performing proof-of-work. Such a setup can be used as an interface to the network for other systems such as block explorers, payment gateways and archives. Eventually it is expected that customised client software will be developed for each of these services so they will no longer be dependent on the node client for them to operate.

Computers that run a node client but which do not perform proof-of-work cannot append new blocks to the blockchain. This means they can neither express acceptance of valid blocks by working on extending them, nor reject invalid blocks by refusing to work on them. These computers exist as passive entities that follow the gatekeepers of the network, the miners.

=== Mempool ===
Before a bitcoin transaction can be committed to the blockchain it needs to be received and validated by a miner. If the miner deems the transaction valid, they add the transaction to one of several [[Protocol#mempool|mempools]]. Mempools are temporary transaction stores and can be used to hold transactions grouped in different ways such as transactions to be mined in the next block, transactions to watch, or transactions which cannot be mined due to an nLocktime/nSequence interlock.

It is important to note every miner has their own mempools and that mempools vary across miners. It is also important to note that an individual transaction can be included in different mempools at the same time.

A miner takes the transactions to be mined in the next block and hashes them into a [[Protocol#Merkle_Trees|merkle tree]] structure and includes the resulting merkle root within a candidate [[Block hashing algorithm|block header]]. The miner then hashes this candidate block header, attempting to find a valid proof-of-work.

=== Hashing ===
A hash is a function that converts a string of data into a fixed length value that represents the original string, called the hash value. Every hash value is unique.

Hashing is a one-way function, meaning it is infeasible to determine what the input data is by looking at the hash produced from it. Conversely, it is trivial to run the same input data through the same hash function and reproduce the same hash. Because of this, a hash value of input data can be thought of as the digital fingerprint of that data. In bitcoin mining, the input data is the 80-byte [[Block hashing algorithm|block header]].

The hashing algorithm used in bitcoin mining is [[SHA-256]]. SHA-256 stands for Secure Hash Algorithm – 256 bit. Passing the block header data through this algorithm will always output a 256-bit number that is unique.

Bitcoin mining passes the block header data through the SHA-256 algorithm twice (SHA-256d). The reason for this is to accommodate the presumed future fracture of mining interests into separate specialized entities. A double hash allows for a hashing entity to indicate they have a valid proof-of-work to another mining related entity without having to reveal the block header input data.

=== Proof-of-work ===
Bitcoin uses the [[hashcash]] [[Proof of Work]] function.

A miner cannot create a new block without finding a valid proof-of-work hash for the block header they are hashing. To be valid, the SHA-256d hash (which is just a number) of the block header must be less than another number, called the [[target]]. The target value is defined by the [[Block hashing algorithm|Bits]] field in the block header that is being hashed.

The target adjusts so that the average time it takes to find a valid proof-of-work hash is ten minutes.

Because of the extraordinarily large SHA-256 target space, it is extremely unlikely that any given hash will be below the target. As a result of this, hashing entities invest large amounts of capital into specialized hashing hardware along with the associated electricity costs in order to produce as many of these hashes as possible. Therefore, the only way a miner can append a block to the blockchain is through substantial financial commitment – proof-of-work.

=== Incentive ===
The first transaction in every block is called the [[Coinbase]] transaction. The Coinbase transaction is a special transaction which pays bitcoins to the miner of the block. The Coinbase payment is made up of the [[Miner subsidy|subsidy]] amount and the sum of all [[transaction fees]] paid by transactions within the mined block.

== Competition ==

=== Propagation and validation ===
If a miner finds a valid proof-of-work for the block header they are hashing, they immediately announce this by sending the entire block to other miners. Meanwhile, they start working on finding the next block in the chain.

Competing miners receive this block and immediately check that all transactions within the block, as well as the proof-of-work are valid. If the block is valid they discontinue mining on the old block height and start working on hashing a new block header, building on the block just found by their competitor.

There are incentives at play here. First, winning 'miner A' strives to get their winning block to all other miners as quickly as possible. This reduces the possibility that competing 'miner B' (who found a valid block at approximately the same time) propagates their block to some miners before 'miner A' could. This opens up the possibility that 'miner A's' block could later be [[Orphan Block|orphaned]]. The degree of bandwidth and connectivity to other miners can be seen as a competitive advantage and as such, the mining network tends toward a densely connected, small world structure with high bandwidth.

There also exists a competitive advantage in validating transactions. When validating a block, each transaction's inputs must be looked up in the miner's [[VOUT|UTXO]] set to check they are unspent and the amount in satoshis is correct. Additionally, each input's locking and unlocking scripts need to be run by the miner to assess whether each transaction is valid.

=== Rejected blocks ===
At any given point in time, two or more independent miners may mine a block at the same time. In this situation, nodes can be in disagreement about which of these blocks should be at the top of the blockchain.

Miners always follow the longest chain they deem to be valid, in practice this means the chain with the most chainwork - the chain with the most proof-of-work invested in it. Eventually another block will be found that builds on one of the competing chain tips. Miners then switch to this tip provided they consider it to be valid. As such, any fork scenario is eventually resolved back to one persistent chain through the actions of the majority of hash power.

In this scenario, blocks that don't end up forming part of the longest chain are rejected by the network and are called orphans. Orphaned blocks represent wasted effort on the behalf of a miner and an incentive to invest in infrastructure in order to reduce the frequency of these events.

Competing valid blocks are not the only way that blocks end up being rejected. Any miner can refuse to build on any block for any reason. Such an action by a particular miner is only meaningful if the majority of miners carry out the same action. It is through this mechanism that the mining network can establish consensus on variables that are miner configurable - such as maximum block size. This is the basis of Nakamoto Consensus:

"They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism."

== The mining ecosystem ==

=== Asic mining ===
An application-specific integrated circuit, or ASIC, is a microchip designed and manufactured for a very specific purpose. ASICs designed for Bitcoin mining were first released in 2013. For the amount of power they consume, they are vastly superior to predecessor approaches to mining - using CPU, GPU or FPGA.

=== Pooled mining ===
As more and more miners competed for the limited supply of blocks, individuals found that they were working for months without finding a block and receiving any reward for their mining efforts. To address the variance in their income, miners started organizing themselves into pools so that rewards could be shared evenly.

==== Stratum ====
Stratum is an open-source mining protocol used by some mining pools. Stratum facilitates coordination between the mining pool operator and individual mining machines.

==See also==
* [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper]

Mining

2020-02-16T16:07:07Z

Steve:

== Introduction ==
'''Mining''' is the process where nodes in the Bitcoin [[Network]] assemble newly broadcast [[Bitcoin Transactions|bitcoin transactions]] into a data structure called a [[block]]. Nodes then compete to append their block to the public [[Block chain|blockchain]] by repeatedly mutating the block's header data structure, usually by incrementing the nonce field, the hashing it in an attempt to find a value that satisfies a difficult [[Proof of Work|proof-of-work]].

When a node finds a valid proof-of-work hash for a block, it broadcasts the block to all nodes. Other nodes accept this block only if all the transactions in it are valid and have not yet been included in a block. Other nodes in the network then express their acceptance of the block by building upon it to create the next block in the chain.

Every block is [[Block timestamp|timestamped]] and references the hash of the block preceding it. Blocks form a backward reinforcing, timestamped chain – a [[Timechain]], the precursor to the term ‘blockchain’.

The blockchain structures itself in a manner that is computationally impractical to modify by any one entity. Due to this, transactions included in the blockchain are considered immutable. In addition to this quality, the blockchain establishes an authoritative order of these transactions throughout the network, thereby protecting users from [[Double-spending|attempts to re-spend coins]] that have already been spent elsewhere. This is the key innovation of mining and of bitcoin.

=== Nodes ===
Nodes are entities that run software that carries out the mining functions above. Nodes communicate using a [[P2P Network]] with its own protocol, and are the maintainers of the Bitcoin ledger and guardians of the [[protocol]].

Interestingly, the bitcoin whitepaper makes no reference to the term ‘miner’ or the concept of ‘mining’. These terms are encompassed within Satoshi Nakamoto’s description of a ‘node’. It is possible however to run node client software without performing proof-of-work. Such a setup can be used as an interface to the network for other systems such as block explorers, payment gateways and archives. Eventually it is expected that customised client software will be developed for each of these services so they will no longer be dependent on the node client for them to operate.

Computers that run a node client but which do not perform proof-of-work cannot append new blocks to the blockchain. This means they can neither express acceptance of valid blocks by working on extending them, nor reject invalid blocks by refusing to work on them. These computers exist as passive entities that follow the gatekeepers of the network, the miners.

=== Mempool ===
Before a bitcoin transaction can be committed to the blockchain it needs to be received and validated by a miner. If the miner deems the transaction valid, they add the transaction to one of several [[Protocol#mempool|mempools]]. Mempools are temporary transaction stores and can be used to hold transactions grouped in different ways such as transactions to be mined in the next block, transactions to watch, or transactions which cannot be mined due to an nLocktime/nSequence interlock.

It is important to note every miner has their own mempools and that mempools vary across miners. It is also important to note that an individual transaction can be included in different mempools at the same time.

A miner takes the transactions to be mined in the next block and hashes them into a [[Protocol#Merkle_Trees|merkle tree]] structure and includes the resulting merkle root within a candidate [[Block hashing algorithm|block header]]. The miner then hashes this candidate block header, attempting to find a valid proof-of-work.

=== Hashing ===
A hash is a function that converts a string of data into a fixed length value that represents the original string, called the hash value. Every hash value is unique.

Hashing is a one-way function, meaning it is infeasible to determine what the input data is by looking at the hash produced from it. Conversely, it is trivial to run the same input data through the same hash function and reproduce the same hash. Because of this, a hash value of input data can be thought of as the digital fingerprint of that data. In bitcoin mining, the input data is the 80-byte [[Block hashing algorithm|block header]].

The hashing algorithm used in bitcoin mining is [[SHA-256]]. SHA-256 stands for Secure Hash Algorithm – 256 bit. Passing the block header data through this algorithm will always output a 256-bit number that is unique.

Bitcoin mining passes the block header data through the SHA-256 algorithm twice (SHA-256d). The reason for this is to accommodate the presumed future fracture of mining interests into separate specialized entities. A double hash allows for a hashing entity to indicate they have a valid proof-of-work to another mining related entity without having to reveal the block header input data.

=== Proof-of-work ===
Bitcoin uses the [[hashcash]] [[Proof of Work]] function.

A miner cannot create a new block without finding a valid proof-of-work hash for the block header they are hashing. To be valid, the SHA-256d hash (which is just a number) of the block header must be less than another number, called the [[target]]. The target value is defined by the [[Block hashing algorithm|Bits]] field in the block header that is being hashed.

The target adjusts so that the average time it takes to find a valid proof-of-work hash is ten minutes.

Because of the extraordinarily large SHA-256 target space, it is extremely unlikely that any given hash will be below the target. As a result of this, hashing entities invest large amounts of capital into specialized hashing hardware along with the associated electricity costs in order to produce as many of these hashes as possible. Therefore, the only way a miner can append a block to the blockchain is through substantial financial commitment – proof-of-work.

=== Incentive ===
The first transaction in every block is called the [[Coinbase]] transaction. The Coinbase transaction is a special transaction which pays bitcoins to the miner of the block. The Coinbase payment is made up of the [[Miner subsidy|subsidy]] amount and the sum of all [[transaction fees]] paid by transactions within the mined block.

== Competition ==

=== Propagation and validation ===
If a miner finds a valid proof-of-work for the block header they are hashing, they immediately announce this by sending the entire block to other miners. Meanwhile, they start working on finding the next block in the chain.

Competing miners receive this block and immediately check that all transactions within the block, as well as the proof-of-work are valid. If the block is valid they discontinue mining on the old block height and start working on hashing a new block header, building on the block just found by their competitor.

There are incentives at play here. First, winning 'miner A' strives to get their winning block to all other miners as quickly as possible. This reduces the possibility that competing 'miner B' (who found a valid block at approximately the same time) propagates their block to some miners before 'miner A' could. This opens up the possibility that 'miner A's' block could later be [[Orphan Block|orphaned]]. The degree of bandwidth and connectivity to other miners can be seen as a competitive advantage and as such, the mining network tends toward a densely connected, small world structure with high bandwidth.

There also exists a competitive advantage in validating transactions. When validating a block, each transaction's inputs must be looked up in the miner's [[VOUT|UTXO]] set to check they are unspent and the amount in satoshis is correct. Additionally, each input's locking and unlocking scripts need to be run by the miner to assess whether each transaction is valid.

=== Rejected blocks ===
At any given point in time, two or more independent miners may mine a block at the same time. In this situation, nodes can be in disagreement about which of these blocks should be at the top of the blockchain.

Miners always follow the longest chain they deem to be valid, in practice this means the chain with the most chainwork - the chain with the most proof-of-work invested in it. Eventually another block will be found that builds on one of the competing chain tips. Miners then switch to this tip provided they consider it to be valid. As such, any fork scenario is eventually resolved back to one persistent chain through the actions of the majority of hash power.

In this scenario, blocks that don't end up forming part of the longest chain are rejected by the network and are called orphans. Orphaned blocks represent wasted effort on the behalf of a miner and an incentive to invest in infrastructure in order to reduce the frequency of these events.

Competing valid blocks are not the only way that blocks end up being rejected. Any miner can refuse to build on any block for any reason. Such an action by a particular miner is only meaningful if the majority of miners carry out the same action. It is through this mechanism that the mining network can establish consensus on variables that are miner configurable - such as maximum block size. This is the basis of Nakamoto Consensus:

"They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism."

== The mining ecosystem ==

=== Asic mining ===
An application-specific integrated circuit, or ASIC, is a microchip designed and manufactured for a very specific purpose. ASICs designed for Bitcoin mining were first released in 2013. For the amount of power they consume, they are vastly superior to predecessor approaches to mining - using CPU, GPU or FPGA.

=== Pooled mining ===
As more and more miners competed for the limited supply of blocks, individuals found that they were working for months without finding a block and receiving any reward for their mining efforts. To address the variance in their income, miners started organizing themselves into pools so that rewards could be shared evenly.

==== Stratum ====
Stratum is an open-source mining protocol used by some mining pools. Stratum facilitates coordination between the mining pool operator and individual mining machines.

==See also==
* [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper]

Timechain

2020-02-16T16:05:35Z

Steve:

The word Timechain can be used to refer to the nature of the Bitcoin [[Block chain]] as a chain of timestamped events in history. Transactions themselves do not have a timestamp component and as such are attributed with the timestamp of the [[Block]] they end up being included in. It is possible to include more accurate timestamp information in a Bitcoin transaction as part of an [[Application layer protocol]] however this must be done with the explicit intent of a secondary system existing that can interpret the time and is not part of the Bitoin protocol.

Private Keys

2019-12-18T15:42:48Z

Steve:

A '''private key''' is a coordinate on the Bitcoin Elliptic Curve which can be used in a variety of ways including the transfer of Bitcoins, the encryption of data and more.

Every Bitcoin wallet contains one or more private keys, which are typically deterministically generated from a root key, and which are saved in the wallet file. Having knowledge of a private key allows any coins that can be unlocked with that key to be spent, so it is important that these are kept secret and safe.
Private keys themselves are almost never handled by the user, instead the user will typically be given a [[seed phrase]] from which their wallet's root key can be derived.

==Range of valid ECDSA private keys==
Nearly every 256-bit number is a valid [[Digital Signatures (ECDSA)|ECDSA]] private key. Specifically, any 256-bit number from 0x1 to 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140 is a valid private key.

The range of valid private keys is governed by the [[secp256k1]] ECDSA standard used by Bitcoin.

==Hierarchical Deterministic (HD) Wallet Keys==

Wallet software may use a [[BIP 0032|mnemonic]] seed to generate many private keys and corresponding public keys from a single secret value. This is called a ''hierarchical deterministic wallet'', or ''HD wallet'' for short. The seed value, or ''master extended key'', consists of a 256-bit private key and a 256-bit ''chain code'', for 512 bits in total. The seed value should not be confused with the private keys used directly to sign Bitcoin transactions.

Users are strongly advised to use HD wallets, for safety reasons: An HD wallet only needs to be backed up once typically using a [[seed phrase]]; thereafter in the future, that single backup can always deterministically regenerate the same private keys. Therefore, it can safely recover all addresses, and all funds sent to those addresses. Non-HD wallets generate a new randomly-selected private key for each new address; therefore, if the wallet file is lost or damaged, the user will irretrievably lose all funds received to addresses generated after the most recent backup.

==Base58 Wallet Import format==
When importing or sweeping ECDSA private keys, a shorter format known as [[Wallet import format]] is often used, which offers a few advantages.
The wallet import format is shorter, and includes built-in error checking codes so that typos can be automatically detected and/or corrected (which is impossible in hex format) and type bits indicating how it is intended to be used.
Wallet import format is the most common way to represent private keys in Bitcoin.
For private keys associated with uncompressed public keys, they are 51 characters and always start with the number 5 on mainnet (9 on testnet). Private keys associated with compressed public keys are 52 characters and start with a capital L or K on mainnet (c on testnet). This is the same private key in (mainnet) wallet import format:

5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF

When a WIF private key is imported, it always corresponds to exactly one [[Address|Bitcoin address]].
Any utility which performs the conversion can display the matching Bitcoin address.
The mathematical conversion is somewhat complex and best left to a computer, but it's notable that the WIF guarantees it will always correspond to the same address no matter which program is used to convert it.

The Bitcoin address implemented using the sample above is: 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj

==Summary==
Any Bitcoins sent to the address 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj can be spent by anybody who knows the private key implementing it in ''any'' of the three formats, regardless of when the bitcoins were sent, unless the wallet receiving them has since made use of the coins generated.
The private key is only needed to spend the bitcoins, not necessarily to see the value of them.

If a private key controlling unspent bitcoins is compromised or stolen, the value can be protected if it is immediately spent to a different output which is secure.
Because bitcoins in an unspent transaction output can only be spent once, when they are spent using a private key, the private key becomes worthless.
It is often possible, but inadvisable and insecure, to use the address implemented by the private key more than once, in which case the same private key would be [[Address reuse|reused]].

==See Also==

* [[Paper wallet]]

Coinbase

2019-12-18T14:50:30Z

Steve:

Opcodes used in Bitcoin Script

2019-12-17T15:48:17Z

Steve: clarify OP_ENDIF

This is a list of all Script words, also known as opcodes, commands, or functions.

OP_NOP1-OP_NOP10 were originally set aside to be used when HASH and other security functions become insecure due to improvements in computing.

False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.

=== Constants ===
When talking about scripts, these value-pushing words are usually omitted.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_0, OP_FALSE
|0
|0x00
|Nothing.
|(empty value)
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)
|-
|N/A
|1-75
|0x01-0x4b
|(special)
|data
|The next ''opcode'' bytes is data to be pushed onto the stack
|-
|OP_PUSHDATA1
|76
|0x4c
|(special)
|data
|The next byte contains the number of bytes to be pushed onto the stack.
|-
|OP_PUSHDATA2
|77
|0x4d
|(special)
|data
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|OP_PUSHDATA4
|78
|0x4e
|(special)
|data
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.
|-
|OP_1NEGATE
|79
|0x4f
|Nothing.
| -1
|The number -1 is pushed onto the stack.
|-
|OP_1, OP_TRUE
|81
|0x51
|Nothing.
|1
|The number 1 is pushed onto the stack.
|-
|OP_2-OP_16
|82-96
|0x52-0x60
|Nothing.
|2-16
|The number in the word name (2-16) is pushed onto the stack.
|}

=== Flow control ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_NOP
|97
|0x61
|Nothing
|Nothing
|Does nothing.
|-
|OP_VER '''DISABLED'''
|98
|0x62
|Nothing
|Transaction version
|Puts the version of the transaction onto the stack
|-
|OP_IF
|99
|0x63
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the top stack value is not False, the statements are executed. The top stack value is removed.
|-
|OP_NOTIF
|100
|0x64
| colspan="2"|<expression> notif [statements] [else [statements]]* endif
|If the top stack value is False, the statements are executed. The top stack value is removed.
|-
|OP_VERIF '''DISABLED'''
|101
|0x65
|Version
|<version> verif [statements] [else [statements]]* endif
|If the top stack value is EQUAL to the version of the transaction, the statements are executed. The top stack value is removed.
|-
|OP_VERNOTIF '''DISABLED'''
|102
|0x66
|Version
|<version> vernotif [statements] [else [statements]]* endif
|If the top stack value is NOT EQUAL to the version of the transaction, the statements are executed. The top stack value is removed.
|-
|OP_ELSE
|103
|0x67
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not.
|-
|OP_ENDIF
|104
|0x68
| colspan="2"|<expression> if [statements] [else [statements]]* endif
|Ends an if/else block. All blocks must end, or the transaction is '''invalid'''. An OP_ENDIF without a prior matching OP_IF or OP_NOTIF is also '''invalid'''.
|-
|OP_VERIFY
|105
|0x69
|True / false
|Nothing / ''fail''
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.
|-
|[[OP_RETURN]]
|106
|0x6a
|Nothing
|''Ends script with top value on stack as final result''
| OP_RETURN can also be used to create "False Return" outputs with a scriptPubKey consisting of OP_FALSE OP_RETURN followed by data. Such outputs are provably unspendable and should be given a value of zero Satoshis. These outputs can be pruned from storage in the UTXO set, reducing its size. Currently the BitcoinSV network supports multiple FALSE RETURN outputs in a given transaction with each one capable of holding up to 100kB of data. After the Genesis upgrade in 2020 miners will be free to mine transactions containing FALSE RETURN outputs of any size.
|}

=== Stack ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_TOALTSTACK
|107
|0x6b
|x1
|(alt)x1
|Puts the input onto the top of the alt stack. Removes it from the main stack.
|-
|OP_FROMALTSTACK
|108
|0x6c
|(alt)x1
|x1
|Puts the input onto the top of the main stack. Removes it from the alt stack.
|-
|OP_IFDUP
|115
|0x73
|x
|x / x x
|If the top stack value is not 0, duplicate it.
|-
|OP_DEPTH
|116
|0x74
|Nothing
|<Stack size>
|Puts the number of stack items onto the stack.
|-
|OP_DROP
|117
|0x75
|x
|Nothing
|Removes the top stack item.
|-
|OP_DUP
|118
|0x76
|x
|x x
|Duplicates the top stack item.
|-
|OP_NIP
|119
|0x77
|x1 x2
|x2
|Removes the second-to-top stack item.
|-
|OP_OVER
|120
|0x78
|x1 x2
|x1 x2 x1
|Copies the second-to-top stack item to the top.
|-
|OP_PICK
|121
|0x79
|xn ... x2 x1 x0 <n>
|xn ... x2 x1 x0 xn
|The item ''n'' back in the stack is copied to the top.
|-
|OP_ROLL
|122
|0x7a
|xn ... x2 x1 x0 <n>
|... x2 x1 x0 xn
|The item ''n'' back in the stack is moved to the top.
|-
|OP_ROT
|123
|0x7b
|x1 x2 x3
|x2 x3 x1
|The top three items on the stack are rotated to the left.
|-
|OP_SWAP
|124
|0x7c
|x1 x2
|x2 x1
|The top two items on the stack are swapped.
|-
|OP_TUCK
|125
|0x7d
|x1 x2
|x2 x1 x2
|The item at the top of the stack is copied and inserted before the second-to-top item.
|-
|OP_2DROP
|109
|0x6d
|x1 x2
|Nothing
|Removes the top two stack items.
|-
|OP_2DUP
|110
|0x6e
|x1 x2
|x1 x2 x1 x2
|Duplicates the top two stack items.
|-
|OP_3DUP
|111
|0x6f
|x1 x2 x3
|x1 x2 x3 x1 x2 x3
|Duplicates the top three stack items.
|-
|OP_2OVER
|112
|0x70
|x1 x2 x3 x4
|x1 x2 x3 x4 x1 x2
|Copies the pair of items two spaces back in the stack to the front.
|-
|OP_2ROT
|113
|0x71
|x1 x2 x3 x4 x5 x6
|x3 x4 x5 x6 x1 x2
|The fifth and sixth items back are moved to the top of the stack.
|-
|OP_2SWAP
|114
|0x72
|x1 x2 x3 x4
|x3 x4 x1 x2
|Swaps the top two pairs of items.
|}

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CAT
|126
|0x7e
|x1 x2
|out
|Concatenates two strings.
|-
|OP_SPLIT
|127
|0x7f
|in size
|x1 x2
|Breaks a string into two sections of length 'size' and the remainder.
|-
|OP_SIZE
|130
|0x82
|in
|in size
|Pushes the string length of the top element of the stack (without popping it).
|}

=== Bitwise logic ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_INVERT
|131
|0x83
|in
|out
|Flips all of the bits in the input.
|-
|OP_AND
|132
|0x84
|x1 x2
|out
|Boolean ''and'' between each bit in the inputs.
|-
|OP_OR
|133
|0x85
|x1 x2
|out
|Boolean ''or'' between each bit in the inputs.
|-
|OP_XOR
|134
|0x86
|x1 x2
|out
|Boolean ''exclusive or'' between each bit in the inputs.
|-
|OP_EQUAL
|135
|0x87
|x1 x2
|True / false
|Returns 1 if the inputs are exactly equal, 0 otherwise.
|-
|OP_EQUALVERIFY
|136
|0x88
|x1 x2
|Nothing / ''fail''
|Same as OP_EQUAL, but runs OP_VERIFY afterward.
|}

=== Arithmetic ===

Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.

If any input value for any of these commands is longer than 4 bytes, the script must abort and fail.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_1ADD
|139
|0x8b
|in
|out
|1 is added to the input.
|-
|OP_1SUB
|140
|0x8c
|in
|out
|1 is subtracted from the input.
|-
|OP_2MUL
|141
|0x8d
|in
|out
|The input is multiplied by 2.
|-
|OP_2DIV
|142
|0x8e
|in
|out
|The input is divided by 2.
|-
|OP_NEGATE
|143
|0x8f
|in
|out
|The sign of the input is flipped.
|-
|OP_ABS
|144
|0x90
|in
|out
|The input is made positive.
|-
|OP_NOT
|145
|0x91
|in
|out
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.
|-
|OP_0NOTEQUAL
|146
|0x92
|in
|out
|Returns 0 if the input is 0. 1 otherwise.
|-
|OP_ADD
|147
|0x93
|a b
|out
|a is added to b.
|-
|OP_SUB
|148
|0x94
|a b
|out
|b is subtracted from a.
|-
|OP_MUL
|149
|0x95
|a b
|out
|a is multiplied by b.
|-
|OP_DIV
|150
|0x96
|a b
|out
|a is divided by b.
|-
|OP_MOD
|151
|0x97
|a b
|out
|Returns the remainder after dividing a by b.
|-
|OP_LSHIFT
|152
|0x98
|a b
|out
|Shifts a left b bits, preserving sign.
|-
|OP_RSHIFT
|153
|0x99
|a b
|out
|Shifts a right b bits, preserving sign.
|-
|OP_BOOLAND
|154
|0x9a
|a b
|out
|If both a and b are not 0, the output is 1. Otherwise 0.
|-
|OP_BOOLOR
|155
|0x9b
|a b
|out
|If a or b is not 0, the output is 1. Otherwise 0.
|-
|OP_NUMEQUAL
|156
|0x9c
|a b
|out
|Returns 1 if the numbers are equal, 0 otherwise.
|-
|OP_NUMEQUALVERIFY
|157
|0x9d
|a b
|Nothing / ''fail''
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
|-
|OP_NUMNOTEQUAL
|158
|0x9e
|a b
|out
|Returns 1 if the numbers are not equal, 0 otherwise.
|-
|OP_LESSTHAN
|159
|0x9f
|a b
|out
|Returns 1 if a is less than b, 0 otherwise.
|-
|OP_GREATERTHAN
|160
|0xa0
|a b
|out
|Returns 1 if a is greater than b, 0 otherwise.
|-
|OP_LESSTHANOREQUAL
|161
|0xa1
|a b
|out
|Returns 1 if a is less than or equal to b, 0 otherwise.
|-
|OP_GREATERTHANOREQUAL
|162
|0xa2
|a b
|out
|Returns 1 if a is greater than or equal to b, 0 otherwise.
|-
|OP_MIN
|163
|0xa3
|a b
|out
|Returns the smaller of a and b.
|-
|OP_MAX
|164
|0xa4
|a b
|out
|Returns the larger of a and b.
|-
|OP_WITHIN
|165
|0xa5
|x min max
|out
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.
|}

=== Crypto ===

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_RIPEMD160
|166
|0xa6
|in
|hash
|The input is hashed using RIPEMD-160.
|-
|OP_SHA1
|167
|0xa7
|in
|hash
|The input is hashed using SHA-1.
|-
|OP_SHA256
|168
|0xa8
|in
|hash
|The input is hashed using SHA-256.
|-
|OP_HASH160
|169
|0xa9
|in
|hash
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.
|-
|OP_HASH256
|170
|0xaa
|in
|hash
|The input is hashed two times with SHA-256.
|-
|OP_CODESEPARATOR
|171
|0xab
|Nothing
|Nothing
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.
|-
|[[OP_CHECKSIG]]
|172
|0xac
|sig pubkey
|True / false
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.
|-
|OP_CHECKSIGVERIFY
|173
|0xad
|sig pubkey
|Nothing / ''fail''
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
|-
|OP_CHECKMULTISIG
|174
|0xae
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys>
|True / False
|Compares the first signature against each public key until it finds an ECDSA match. Starting with the subsequent public key, it compares the second signature against each remaining public key until it finds an ECDSA match. The process is repeated until all signatures have been checked or not enough public keys remain to produce a successful result. All signatures need to match a public key. Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the scriptSig using the same order as their corresponding public keys were placed in the scriptPubKey or redeemScript. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.
|-
|OP_CHECKMULTISIGVERIFY
|175
|0xaf
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys>
|Nothing / ''fail''
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.
|}

=== Locktime ===
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Input
!Output
!Description
|-
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)
|177
|0xb1
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 0065]. '''This opcode will be deprecated post activation of the Genesis upgrade. Any UTXOs that incorporate it into their locking script will remain spendable however if it appears in new transactions it will be treated as OP_NOP2'''
|-
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)
|178
|0xb2
|x
|x / ''fail''
|'''Marks transaction as invalid''' if the relative lock time of the input (enforced by [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 0068] with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki BIP 0112]. '''This opcode will be deprecated post activation of the Genesis upgrade. Any UTXOs that incorporate it into their locking script will remain spendable however if it appears in new transactions it will be treated as OP_NOP3'''
|}

===Pseudo-words===
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.
{| class="wikitable"
|-
!Word
!Opcode
!Hex
!Description
|-
|OP_PUBKEYHASH
|253
|0xfd
|Represents a public key hashed with OP_HASH160.
|-
|OP_PUBKEY
|254
|0xfe
|Represents a public key compatible with OP_CHECKSIG.
|-
|OP_INVALIDOPCODE
|255
|0xff
|Matches any opcode that is not yet assigned.
|}

=== Reserved words ===
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.

{| class="wikitable"
|-
!Word
!Opcode
!Hex
!When used...
|-
|OP_RESERVED
|80
|0x50
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED1
|137
|0x89
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_RESERVED2
|138
|0x8a
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch
|-
|OP_NOP1, OP_NOP4-OP_NOP10
|176, 179-185
|0xb0, 0xb3-0xb9
|The word is ignored. Does not mark transaction as invalid.
|}

==Examples==

For examples of common Bitcoin transaction scripts please see [[Bitcoin Transactions]]

OP CHECKSIG

2019-12-17T13:57:39Z

Steve: missing word

'''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 know the current transaction, the index of the transaction input in which the signature is checked, the scriptPubKey corresponding to the input, and the value in satoshis that the input represents.

== 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,

# the public key and the signature are popped from the top of the stack, in that order. Signature format is [<DER signature> <1 byte hash-type>]. Hashtype value is last byte of the signature.
# A new subScript is created from the previous scriptPubKey identified by the input in which the signature is verified. The partial script from the immediately after the most recently parsed OP_CODESEPARATOR to the end of the scriptPubKey is the subScript. If there is no OP_CODESEPARATOR the entire scriptPubKey becomes the subScript.
# Any occurrences of signatures are deleted from subScript, if present. (It is ''not standard'' to have a signature in a scriptPubKey (locking script) of a transaction.)
# Any remaining OP_CODESEPARATORS are removed from the subScript.
# The hashtype is removed from the last byte of the signature and stored.
# A copy is made from the current transaction (hereby referred to txCopy).
# The scripts for all transaction inputs in txCopy are set to empty scripts (exactly 1 byte 0x00).
# The scriptSig in the current transaction input in txCopy is set to subScript (lead in by its length as a var-integer encoded).

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

===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