https://wiki.bitcoinsv.io/api.php?action=feedcontributions&user=Brendan&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T19:27:53ZUser contributionsMediaWiki 1.33.0https://wiki.bitcoinsv.io/index.php?title=Merkle_root&diff=3101Merkle root2023-10-09T14:01:50Z<p>Brendan: </p>
<hr />
<div>The hash value that summarises all data elements included in a [[Merkle Tree]]. <br />
<br />
As the leaf nodes are concatenated in pairs and hashed, the same occurs for all interior node values, whereupon the binary tree structure converge to a single root value.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Merkle_root&diff=3099Merkle root2023-10-09T14:00:22Z<p>Brendan: </p>
<hr />
<div>The hash value that summarises all data elements included in a [[Merkle Tree]]. <br />
<br />
As the leaf nodes are concatenated in pairs and hashed, the same occurs for all interior node values, whereupon the binary tree structure converge to a single root value.<br />
<br />
[[new page here]]</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Target&diff=3098Target2023-05-06T07:05:09Z<p>Brendan: </p>
<hr />
<div>The '''target''' is a 256-bit number 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.<br />
<br />
It's important to realise 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. <br />
<br />
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.<br />
<br />
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 downwards (increasing difficulty) by more than a factor of 4, or upwards (decreasing difficulty) by more than a factor of 0.75. This prevents large changes in difficulty.<br />
<br />
After the duplication of the Bitcoin transaction ledger by operators of the BTC network in August 2017, Bitcoin's original difficulty adjustment algorithm was changed 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. A single DAA retarget never changes the target downwards (increasing difficulty) by more than a factor of 2, or upwards (decreasing difficulty) by more than a factor of 2. This sets the maximum bounds for any change in difficulty.<br />
<br />
The reason the EDA (and later the DAA) needed to be implemented was due to the creation of the competing BTC network which was expected to garner significantly more hash power than Bitcoin (known as Bitcoin Cash at the time). These measures were put in place so that block production could remain relatively stable due to Miners' ability to instantaneously re-allocate hash between the networks.<br />
<br />
It is proposed that Bitcoin will move back to the original difficulty adjustment algorithm (still used by Bitcoin Core - BTC) in the future.<br />
<br />
===How is the target stored in blocks?===<br />
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:<br />
0x0404cb x 256^(0x1b - 3) = 0x00000000000404CB000000000000000000000000000000000000000000000000<br />
<br />
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.<br />
<br />
=== What is the current target? ===<br />
Check the [[Block hashing algorithm|Bits]] field of the most recent block on a [https://whatsonchain.com/ block explorer].<br />
<br />
=== What is the maximum target? ===<br />
The maximum target used by SHA256 mining devices is:<br />
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF<br />
Because Bitcoin stores the target as a floating-point type, this is truncated:<br />
0x00000000FFFF0000000000000000000000000000000000000000000000000000<br />
<br />
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.<br />
<br />
Since a lower target makes Bitcoin generation more difficult, the maximum target is the ''lowest'' possible [[difficulty]].<br />
<br />
==Related Links==<br />
See also [[Difficulty]]<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Target 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Elliptic_Curve_Digital_Signature_Algorithm&diff=3096Elliptic Curve Digital Signature Algorithm2023-02-14T23:39:45Z<p>Brendan: </p>
<hr />
<div>'''Elliptic Curve Digital Signature Algorithm''' or '''ECDSA''' is a cryptographic algorithm used by Bitcoin to ensure the effective and secure control of ownership of funds.<br />
<br />
A few concepts related to ECDSA:<br />
* [[Private Keys|private key]]: A secret number, known only to the person that generated it. A private key can be a randomly generated number but in 2019 most wallets use deterministic key schemes derived from [https://github.com/bitcoin/bips/tree/master/bip-0032 BIP 0032]. In Bitcoin, someone who can prove ownership of unspent outputs can use the private key to spend the funds. In Bitcoin, a private key is a single unsigned 256-bit integer (32 bytes). <br />
* public key: A coordinate that corresponds to a private key but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine by using ECDSA to validate that a signature was generated by the private key, that corresponds to the public key that has been proffered, without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called ''x''. Uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called ''x'' and ''y'' (2 * 32 bytes). The prefix of a compressed key allows for the ''y'' value to be derived from the ''x'' value.<br />
* [[Protocol#Signatures|signatures]]: A string of bytes proving that a private key was used to sign a message. A signature is mathematically generated from a [[SHA-256|hash]] of the message being signed and a private key. The signature itself is two numbers known as ''r'' and ''s'' and the message being signed is the Bitcoin transaction (minus the signature data). With the public key, a mathematical algorithm (signature verification) can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are usually 71, 72, or 73 bytes long, with probabilities approximately 25%, 50% and 25% respectively.<br />
<br />
In Bitcoin, elliptic curve signatures must sign a hash of a "transaction message" which can be reproduced easily by nodes validating the signature during the process of validating transactions.<br />
The message that is hashed for the signature contains the following elements concatenated into a single string:<br />
# nVersion - Transaction version (4 bytes, little endian)<br />
# hashPrevouts - concatenation of input source / sources (32 byte hash)<br />
# hashSequence - concatenation of input nSequence value / values (32 byte hash)<br />
# outpoint - Outpoint for input being spent (TXID / Vout) (32 byte hash + 4 bytes, little endian)<br />
# scriptLen - Length of the input scriptPubKey for input being spent ([[VarInt| VarInt format]])<br />
# scriptPubKey = Script for input being spent (scriptLen bytes)<br />
# value - Qty of satoshis being spent by input (8 bytes, little endian)<br />
# nSequence - Sequence value for input being spent (4 bytes, little endian)<br />
# hashOutputs - Hash of output/outputs being signed (32 byte hash)<br />
# nLocktime - Transaction locktime (4 bytes, Little Endian [[NLocktime_and_nSequence#NLocktime|locktime format]])<br />
# Sighash flag (4 bytes, XX000000 where XX is Sighash Flag)<br />
<br />
==Variations based on [[Sighash flags]]==<br />
Depending on the Sighash flag that is set, the signature message can be tailored to include or exclude various elements of the transaction.<br />
<br />
===hashPrevouts===<br />
If the ANYONECANPAY flag is *not* set, hashPrevouts is the double SHA256 of the serialization of all input outpoints.<br />
e.g. SHA256D(CAT(TXID1/Out1, TXID2/Out2, TXID3/Out3)<br />
<br />
If the ANYONECANPAY flag is set, hashPrevouts is a uint256 of 0x0000......0000.<br />
<br />
===hashSequence===<br />
If *none* of the ANYONECANPAY, SINGLE, NONE Sighash flags are set, hashSequence is the double SHA256 of the serialization of nSequence of all inputs.<br />
<br />
e.g. SHA256D(CAT(input1.nSequence, input2.nSequence, input3.nSequence)<br />
<br />
If one or more of the ANYONECANPAY, SINGLE or NONE Sighash flags are set, hashSequence is a uint256 of 0x0000......0000.<br />
<br />
===hashOutputs===<br />
If the ALL Sighash flag is set, hashOutputs is the double SHA256 of the serialization of all outputs in [[Bitcoin_Transactions#Format_of_a_Transaction_Output|Output format]].<br />
e.g. SHA256D(CAT(value1/scriptLen1/scriptPubkey1, value2/scriptLen2/scriptPubkey2, value3/scriptLen3/scriptPubkey3) <br />
<br />
If the SINGLE Sighash flag is set and the input index is smaller than the number of outputs, hashOutputs is the double SHA256 of the output of the same index as the input in [[Bitcoin_Transactions#Format_of_a_Transaction_Output|Output format]].<br />
<br />
Otherwise, hashOutputs is a uint256 of 0x0000......0000.[7]<br />
<br />
==Applying SIGHASH flags==<br />
<br />
All signatures include [[SIGHASH flags]] which tell the transaction validator which parts of the message have been used in the construction of the message hash.<br />
<br />
==See also==<br />
* [[Secp256k1]]<br />
<br />
==External Links==<br />
* [https://en.wikipedia.org/wiki/Elliptic_Curve_DSA Elliptic Curve Digital Signature Algorithm - Wikipedia article]<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Draft_139&diff=3092Draft 1392022-11-20T13:48:41Z<p>Brendan: </p>
<hr />
<div>The Bitcoin Whitepaper contains two references to an alert key.<br />
<br />
'''1. In Section 8, Simplified Payment Verification**'''<br />
<br />
''"One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency."''<br />
<br />
'''2. In Section 11, Calculations:'''<br />
<br />
''"We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late."''<br />
<br />
Both sections talk about the Alert Key's use in prevention of double spending.<br />
<br />
===Using the Alert Key==<br />
The original Alert key (introduced in version 0.3.10) was operated by the Bitcoin Foundation and controlled with a 2 of 3 multisignature system. The key allowed them to notify all nodes on the network of critical network problems such as technical issues/bugs or in a situation where Simplified Payment Verification was widely used to notify users of dishonest activity including invalid blocks and attempted double spends.<br />
<br />
The original alert system was removed in Bitcoin Core release 0.13.0.<br />
<br />
==Technical Details==<br />
<br />
When an alert was in effect, the message it contained would appear in a status bar in all clients and in the "errors" field of RPC ''getinfo''. Any script registered with the <code>-alertnotify</code> command-line option will be notified.<br />
<br />
===Alert message===<br />
Alerts were broadcast using the same TCP relay system as ''block'' and ''tx'' messages. They were not encoded in a special transaction. Unlike block and tx relaying, alerts were sent at the start of every new connection for as long as the alert was in effect. This ensured that everyone received the alert.<br />
<br />
Alerts contained this information:<br />
* How long to relay the alert.<br />
* How long to consider the alert valid.<br />
* An alert ID number.<br />
* A list of alerts that should be canceled upon receipt of this alert.<br />
* Exactly which versions of Bitcoin are affected by the alert. Unaffected versions still relay the alert for the benefit of older versions.<br />
* Alert priority.<br />
* The alert text.<br />
<br />
Only alerts that are signed by a specific ECDSA public key were considered valid, but the private key was made public after the alert system was retired.<br />
<br />
===Safe mode===<br />
Until version 0.3.20, Bitcoin went into safe mode when a valid alert was received. In safe mode, all RPC commands that send BTC or get info about received BTC return an error.<br />
<br />
==History==<br />
{{multiple image|align=vertical|width=300<br />
|image1=alert.png<br />
|image2=bitcoin-alert-cli.png<br />
|footer=An alert appearing on bitcoin clients<br />
}}<br />
<br />
The alert system was implemented by [[Satoshi Nakamoto]] after the [[value overflow incident]] on August 15, 2010.<br />
<br />
===List of published alerts prior to Alert Key removal===<br />
{| class="wikitable" border="1"<br />
|-<br />
! ID<br />
! Sent date<br />
! Expires (UTC)<br />
! Versions<br />
! Priority<br />
! Message<br />
|-<br />
| 1010<br />
| Feb 18, 2012<br />
| Feb 21 02:47:15<br />
| All<br />
| 100<br />
| See bitcoin.org/feb20 if you have trouble connecting after 20 February<br />
|-<br />
| 1011<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 0.5 - 0.5.3<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1012<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 6.0<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1013<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 5.99<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1015<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.1 - 0.4.5<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1016<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.4.99 - 0.5.4<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1020<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.6.0<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1032<br />
| March 12, 2013<br />
| March 13, 2013<br />
| 0.8.0<br />
| 5000<br />
| URGENT: chain fork, stop mining on version 0.8<br />
|-<br />
| 1033<br />
| March 19, 2013<br />
| March 20, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| See http://bitcoin.org/may15.html for an important message<br />
|-<br />
| 1034<br />
| May 9, 2013<br />
| June 8, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| Action required: see http://bitcoin.org/may15.html for more information<br />
|-<br />
| 1040<br />
| April 11, 2014<br />
| cancelled<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed/<br />
|-<br />
| 1041<br />
| April 11, 2014<br />
| April 11, 2015<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed<br />
|}<br />
<br />
==See Also==<br />
<br />
* https://github.com/bitcoin/bitcoin/pull/7692 - The pull request where removing the alert system from [[Bitcoin Core]] was discussed<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Alert_system 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Draft_139&diff=3091Draft 1392022-11-20T13:44:08Z<p>Brendan: </p>
<hr />
<div>The Bitcoin Whitepaper contains two references to an alert key.<br />
<br />
'''1. In Section 8, Simplified Payment Verification**'''<br />
<br />
''"One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency."''<br />
<br />
'''2. In Section 11, Calculations:'''<br />
<br />
''"We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late."''<br />
<br />
Both talk about the Alert Key's use in prevention of double spending. The original Alert key (introduced in version 0.3.10) was operated by the Bitcoin Foundation and controlled with a 2 of 3 multisignature system. The key allowed them to notify all nodes on the network of critical network problems such as technical issues/bugs or in a situation where Simplified Payment Verification was widely used to notify users of dishonest activity including invalid chains of blocks and double spends. <br />
<br />
The original alert system was removed in Bitcoin Core release 0.13.0.<br />
<br />
==Technical Details==<br />
<br />
When an alert was in effect, the message it contained would appear in a status bar in all clients and in the "errors" field of RPC ''getinfo''. Any script registered with the <code>-alertnotify</code> command-line option will be notified.<br />
<br />
===Alert message===<br />
Alerts were broadcast using the same TCP relay system as ''block'' and ''tx'' messages. They were not encoded in a special transaction. Unlike block and tx relaying, alerts were sent at the start of every new connection for as long as the alert was in effect. This ensured that everyone received the alert.<br />
<br />
Alerts contained this information:<br />
* How long to relay the alert.<br />
* How long to consider the alert valid.<br />
* An alert ID number.<br />
* A list of alerts that should be canceled upon receipt of this alert.<br />
* Exactly which versions of Bitcoin are affected by the alert. Unaffected versions still relay the alert for the benefit of older versions.<br />
* Alert priority.<br />
* The alert text.<br />
<br />
Only alerts that are signed by a specific ECDSA public key were considered valid, but the private key was made public after the alert system was retired.<br />
<br />
===Safe mode===<br />
Until version 0.3.20, Bitcoin went into safe mode when a valid alert was received. In safe mode, all RPC commands that send BTC or get info about received BTC return an error.<br />
<br />
==History==<br />
{{multiple image|align=vertical|width=300<br />
|image1=alert.png<br />
|image2=bitcoin-alert-cli.png<br />
|footer=An alert appearing on bitcoin clients<br />
}}<br />
<br />
The alert system was implemented by [[Satoshi Nakamoto]] after the [[value overflow incident]] on August 15, 2010.<br />
<br />
===List of published alerts prior to Alert Key removal===<br />
{| class="wikitable" border="1"<br />
|-<br />
! ID<br />
! Sent date<br />
! Expires (UTC)<br />
! Versions<br />
! Priority<br />
! Message<br />
|-<br />
| 1010<br />
| Feb 18, 2012<br />
| Feb 21 02:47:15<br />
| All<br />
| 100<br />
| See bitcoin.org/feb20 if you have trouble connecting after 20 February<br />
|-<br />
| 1011<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 0.5 - 0.5.3<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1012<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 6.0<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1013<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 5.99<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1015<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.1 - 0.4.5<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1016<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.4.99 - 0.5.4<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1020<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.6.0<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1032<br />
| March 12, 2013<br />
| March 13, 2013<br />
| 0.8.0<br />
| 5000<br />
| URGENT: chain fork, stop mining on version 0.8<br />
|-<br />
| 1033<br />
| March 19, 2013<br />
| March 20, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| See http://bitcoin.org/may15.html for an important message<br />
|-<br />
| 1034<br />
| May 9, 2013<br />
| June 8, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| Action required: see http://bitcoin.org/may15.html for more information<br />
|-<br />
| 1040<br />
| April 11, 2014<br />
| cancelled<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed/<br />
|-<br />
| 1041<br />
| April 11, 2014<br />
| April 11, 2015<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed<br />
|}<br />
<br />
==See Also==<br />
<br />
* https://github.com/bitcoin/bitcoin/pull/7692 - The pull request where removing the alert system from [[Bitcoin Core]] was discussed<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Alert_system 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Draft_139&diff=3090Draft 1392022-11-20T13:43:33Z<p>Brendan: </p>
<hr />
<div>The Bitcoin Whitepaper contains two references to an alert key.<br />
<br />
'''1. In Section 8, Simplified Payment Verification**'''<br />
<br />
One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency.<br />
<br />
'''2. In Section 11, Calculations:'''<br />
<br />
We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late.<br />
<br />
Both talk about the Alert Key's use in prevention of double spending. The original Alert key (introduced in version 0.3.10) was operated by the Bitcoin Foundation and controlled with a 2 of 3 multisignature system. The key allowed them to notify all nodes on the network of critical network problems such as technical issues/bugs or in a situation where Simplified Payment Verification was widely used to notify users of dishonest activity including invalid chains of blocks and double spends. <br />
<br />
The original alert system was removed in Bitcoin Core release 0.13.0.<br />
<br />
==Technical Details==<br />
<br />
When an alert was in effect, the message it contained would appear in a status bar in all clients and in the "errors" field of RPC ''getinfo''. Any script registered with the <code>-alertnotify</code> command-line option will be notified.<br />
<br />
===Alert message===<br />
Alerts were broadcast using the same TCP relay system as ''block'' and ''tx'' messages. They were not encoded in a special transaction. Unlike block and tx relaying, alerts were sent at the start of every new connection for as long as the alert was in effect. This ensured that everyone received the alert.<br />
<br />
Alerts contained this information:<br />
* How long to relay the alert.<br />
* How long to consider the alert valid.<br />
* An alert ID number.<br />
* A list of alerts that should be canceled upon receipt of this alert.<br />
* Exactly which versions of Bitcoin are affected by the alert. Unaffected versions still relay the alert for the benefit of older versions.<br />
* Alert priority.<br />
* The alert text.<br />
<br />
Only alerts that are signed by a specific ECDSA public key were considered valid, but the private key was made public after the alert system was retired.<br />
<br />
===Safe mode===<br />
Until version 0.3.20, Bitcoin went into safe mode when a valid alert was received. In safe mode, all RPC commands that send BTC or get info about received BTC return an error.<br />
<br />
==History==<br />
{{multiple image|align=vertical|width=300<br />
|image1=alert.png<br />
|image2=bitcoin-alert-cli.png<br />
|footer=An alert appearing on bitcoin clients<br />
}}<br />
<br />
The alert system was implemented by [[Satoshi Nakamoto]] after the [[value overflow incident]] on August 15, 2010.<br />
<br />
===List of published alerts prior to Alert Key removal===<br />
{| class="wikitable" border="1"<br />
|-<br />
! ID<br />
! Sent date<br />
! Expires (UTC)<br />
! Versions<br />
! Priority<br />
! Message<br />
|-<br />
| 1010<br />
| Feb 18, 2012<br />
| Feb 21 02:47:15<br />
| All<br />
| 100<br />
| See bitcoin.org/feb20 if you have trouble connecting after 20 February<br />
|-<br />
| 1011<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 0.5 - 0.5.3<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1012<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 6.0<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1013<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 5.99<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1015<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.1 - 0.4.5<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1016<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.4.99 - 0.5.4<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1020<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.6.0<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1032<br />
| March 12, 2013<br />
| March 13, 2013<br />
| 0.8.0<br />
| 5000<br />
| URGENT: chain fork, stop mining on version 0.8<br />
|-<br />
| 1033<br />
| March 19, 2013<br />
| March 20, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| See http://bitcoin.org/may15.html for an important message<br />
|-<br />
| 1034<br />
| May 9, 2013<br />
| June 8, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| Action required: see http://bitcoin.org/may15.html for more information<br />
|-<br />
| 1040<br />
| April 11, 2014<br />
| cancelled<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed/<br />
|-<br />
| 1041<br />
| April 11, 2014<br />
| April 11, 2015<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed<br />
|}<br />
<br />
==See Also==<br />
<br />
* https://github.com/bitcoin/bitcoin/pull/7692 - The pull request where removing the alert system from [[Bitcoin Core]] was discussed<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Alert_system 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Draft_139&diff=3089Draft 1392022-11-20T13:43:09Z<p>Brendan: </p>
<hr />
<div>The Bitcoin Whitepaper contains two references to an alert key.<br />
<br />
''' # in Section 8, Simplified Payment Verification**'''<br />
<br />
One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency.<br />
<br />
''' # In Section 11, Calculations:'''<br />
<br />
We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late.<br />
<br />
Both talk about the Alert Key's use in prevention of double spending. The original Alert key (introduced in version 0.3.10) was operated by the Bitcoin Foundation and controlled with a 2 of 3 multisignature system. The key allowed them to notify all nodes on the network of critical network problems such as technical issues/bugs or in a situation where Simplified Payment Verification was widely used to notify users of dishonest activity including invalid chains of blocks and double spends. <br />
<br />
The original alert system was removed in Bitcoin Core release 0.13.0.<br />
<br />
==Technical Details==<br />
<br />
When an alert was in effect, the message it contained would appear in a status bar in all clients and in the "errors" field of RPC ''getinfo''. Any script registered with the <code>-alertnotify</code> command-line option will be notified.<br />
<br />
===Alert message===<br />
Alerts were broadcast using the same TCP relay system as ''block'' and ''tx'' messages. They were not encoded in a special transaction. Unlike block and tx relaying, alerts were sent at the start of every new connection for as long as the alert was in effect. This ensured that everyone received the alert.<br />
<br />
Alerts contained this information:<br />
* How long to relay the alert.<br />
* How long to consider the alert valid.<br />
* An alert ID number.<br />
* A list of alerts that should be canceled upon receipt of this alert.<br />
* Exactly which versions of Bitcoin are affected by the alert. Unaffected versions still relay the alert for the benefit of older versions.<br />
* Alert priority.<br />
* The alert text.<br />
<br />
Only alerts that are signed by a specific ECDSA public key were considered valid, but the private key was made public after the alert system was retired.<br />
<br />
===Safe mode===<br />
Until version 0.3.20, Bitcoin went into safe mode when a valid alert was received. In safe mode, all RPC commands that send BTC or get info about received BTC return an error.<br />
<br />
==History==<br />
{{multiple image|align=vertical|width=300<br />
|image1=alert.png<br />
|image2=bitcoin-alert-cli.png<br />
|footer=An alert appearing on bitcoin clients<br />
}}<br />
<br />
The alert system was implemented by [[Satoshi Nakamoto]] after the [[value overflow incident]] on August 15, 2010.<br />
<br />
===List of published alerts prior to Alert Key removal===<br />
{| class="wikitable" border="1"<br />
|-<br />
! ID<br />
! Sent date<br />
! Expires (UTC)<br />
! Versions<br />
! Priority<br />
! Message<br />
|-<br />
| 1010<br />
| Feb 18, 2012<br />
| Feb 21 02:47:15<br />
| All<br />
| 100<br />
| See bitcoin.org/feb20 if you have trouble connecting after 20 February<br />
|-<br />
| 1011<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 0.5 - 0.5.3<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1012<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 6.0<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1013<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 5.99<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1015<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.1 - 0.4.5<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1016<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.4.99 - 0.5.4<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1020<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.6.0<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1032<br />
| March 12, 2013<br />
| March 13, 2013<br />
| 0.8.0<br />
| 5000<br />
| URGENT: chain fork, stop mining on version 0.8<br />
|-<br />
| 1033<br />
| March 19, 2013<br />
| March 20, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| See http://bitcoin.org/may15.html for an important message<br />
|-<br />
| 1034<br />
| May 9, 2013<br />
| June 8, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| Action required: see http://bitcoin.org/may15.html for more information<br />
|-<br />
| 1040<br />
| April 11, 2014<br />
| cancelled<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed/<br />
|-<br />
| 1041<br />
| April 11, 2014<br />
| April 11, 2015<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed<br />
|}<br />
<br />
==See Also==<br />
<br />
* https://github.com/bitcoin/bitcoin/pull/7692 - The pull request where removing the alert system from [[Bitcoin Core]] was discussed<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Alert_system 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Draft_139&diff=3088Draft 1392022-11-20T13:42:38Z<p>Brendan: </p>
<hr />
<div>The Bitcoin Whitepaper contains two references to an alert key.<br />
<br />
'''# in Section 8, Simplified Payment Verification**'''<br />
<br />
One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency.<br />
<br />
'''#In Section 11, Calculations:'''<br />
<br />
We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late.<br />
<br />
Both talk about the Alert Key's use in prevention of double spending. The original Alert key (introduced in version 0.3.10) was operated by the Bitcoin Foundation and controlled with a 2 of 3 multisignature system. The key allowed them to notify all nodes on the network of critical network problems such as technical issues/bugs or in a situation where Simplified Payment Verification was widely used to notify users of dishonest activity including invalid chains of blocks and double spends. <br />
<br />
The original alert system was removed in Bitcoin Core release 0.13.0.<br />
<br />
==Technical Details==<br />
<br />
When an alert was in effect, the message it contained would appear in a status bar in all clients and in the "errors" field of RPC ''getinfo''. Any script registered with the <code>-alertnotify</code> command-line option will be notified.<br />
<br />
===Alert message===<br />
Alerts were broadcast using the same TCP relay system as ''block'' and ''tx'' messages. They were not encoded in a special transaction. Unlike block and tx relaying, alerts were sent at the start of every new connection for as long as the alert was in effect. This ensured that everyone received the alert.<br />
<br />
Alerts contained this information:<br />
* How long to relay the alert.<br />
* How long to consider the alert valid.<br />
* An alert ID number.<br />
* A list of alerts that should be canceled upon receipt of this alert.<br />
* Exactly which versions of Bitcoin are affected by the alert. Unaffected versions still relay the alert for the benefit of older versions.<br />
* Alert priority.<br />
* The alert text.<br />
<br />
Only alerts that are signed by a specific ECDSA public key were considered valid, but the private key was made public after the alert system was retired.<br />
<br />
===Safe mode===<br />
Until version 0.3.20, Bitcoin went into safe mode when a valid alert was received. In safe mode, all RPC commands that send BTC or get info about received BTC return an error.<br />
<br />
==History==<br />
{{multiple image|align=vertical|width=300<br />
|image1=alert.png<br />
|image2=bitcoin-alert-cli.png<br />
|footer=An alert appearing on bitcoin clients<br />
}}<br />
<br />
The alert system was implemented by [[Satoshi Nakamoto]] after the [[value overflow incident]] on August 15, 2010.<br />
<br />
===List of published alerts prior to Alert Key removal===<br />
{| class="wikitable" border="1"<br />
|-<br />
! ID<br />
! Sent date<br />
! Expires (UTC)<br />
! Versions<br />
! Priority<br />
! Message<br />
|-<br />
| 1010<br />
| Feb 18, 2012<br />
| Feb 21 02:47:15<br />
| All<br />
| 100<br />
| See bitcoin.org/feb20 if you have trouble connecting after 20 February<br />
|-<br />
| 1011<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 0.5 - 0.5.3<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1012<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 6.0<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1013<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 5.99<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1015<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.1 - 0.4.5<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1016<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.4.99 - 0.5.4<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1020<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.6.0<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1032<br />
| March 12, 2013<br />
| March 13, 2013<br />
| 0.8.0<br />
| 5000<br />
| URGENT: chain fork, stop mining on version 0.8<br />
|-<br />
| 1033<br />
| March 19, 2013<br />
| March 20, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| See http://bitcoin.org/may15.html for an important message<br />
|-<br />
| 1034<br />
| May 9, 2013<br />
| June 8, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| Action required: see http://bitcoin.org/may15.html for more information<br />
|-<br />
| 1040<br />
| April 11, 2014<br />
| cancelled<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed/<br />
|-<br />
| 1041<br />
| April 11, 2014<br />
| April 11, 2015<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed<br />
|}<br />
<br />
==See Also==<br />
<br />
* https://github.com/bitcoin/bitcoin/pull/7692 - The pull request where removing the alert system from [[Bitcoin Core]] was discussed<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Alert_system 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Draft_139&diff=3087Draft 1392022-11-20T13:41:18Z<p>Brendan: </p>
<hr />
<div>The Bitcoin Whitepaper contains two references to an alert key.<br />
<br />
# ** in Section 8, Simplified Payment Verification**<br />
<br />
One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency.<br />
<br />
# **In Section 11, Calculations:**<br />
<br />
We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late.<br />
<br />
Both talk about the Alert Key's use in prevention of double spending. The original Alert key (introduced in version 0.3.10) was operated by the Bitcoin Foundation and controlled with a 2 of 3 multisignature system. The key allowed them to notify all nodes on the network of critical network problems such as technical issues/bugs or in a situation where Simplified Payment Verification was widely used to notify users of dishonest activity including invalid chains of blocks and double spends. <br />
<br />
The original alert system was removed in Bitcoin Core release 0.13.0.<br />
<br />
==Technical Details==<br />
<br />
When an alert was in effect, the message it contained would appear in a status bar in all clients and in the "errors" field of RPC ''getinfo''. Any script registered with the <code>-alertnotify</code> command-line option will be notified.<br />
<br />
===Alert message===<br />
Alerts were broadcast using the same TCP relay system as ''block'' and ''tx'' messages. They were not encoded in a special transaction. Unlike block and tx relaying, alerts were sent at the start of every new connection for as long as the alert was in effect. This ensured that everyone received the alert.<br />
<br />
Alerts contained this information:<br />
* How long to relay the alert.<br />
* How long to consider the alert valid.<br />
* An alert ID number.<br />
* A list of alerts that should be canceled upon receipt of this alert.<br />
* Exactly which versions of Bitcoin are affected by the alert. Unaffected versions still relay the alert for the benefit of older versions.<br />
* Alert priority.<br />
* The alert text.<br />
<br />
Only alerts that are signed by a specific ECDSA public key were considered valid, but the private key was made public after the alert system was retired.<br />
<br />
===Safe mode===<br />
Until version 0.3.20, Bitcoin went into safe mode when a valid alert was received. In safe mode, all RPC commands that send BTC or get info about received BTC return an error.<br />
<br />
==History==<br />
{{multiple image|align=vertical|width=300<br />
|image1=alert.png<br />
|image2=bitcoin-alert-cli.png<br />
|footer=An alert appearing on bitcoin clients<br />
}}<br />
<br />
The alert system was implemented by [[Satoshi Nakamoto]] after the [[value overflow incident]] on August 15, 2010.<br />
<br />
===List of published alerts prior to Alert Key removal===<br />
{| class="wikitable" border="1"<br />
|-<br />
! ID<br />
! Sent date<br />
! Expires (UTC)<br />
! Versions<br />
! Priority<br />
! Message<br />
|-<br />
| 1010<br />
| Feb 18, 2012<br />
| Feb 21 02:47:15<br />
| All<br />
| 100<br />
| See bitcoin.org/feb20 if you have trouble connecting after 20 February<br />
|-<br />
| 1011<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 0.5 - 0.5.3<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1012<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 6.0<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1013<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 5.99<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1015<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.1 - 0.4.5<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1016<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.4.99 - 0.5.4<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1020<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.6.0<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1032<br />
| March 12, 2013<br />
| March 13, 2013<br />
| 0.8.0<br />
| 5000<br />
| URGENT: chain fork, stop mining on version 0.8<br />
|-<br />
| 1033<br />
| March 19, 2013<br />
| March 20, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| See http://bitcoin.org/may15.html for an important message<br />
|-<br />
| 1034<br />
| May 9, 2013<br />
| June 8, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| Action required: see http://bitcoin.org/may15.html for more information<br />
|-<br />
| 1040<br />
| April 11, 2014<br />
| cancelled<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed/<br />
|-<br />
| 1041<br />
| April 11, 2014<br />
| April 11, 2015<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed<br />
|}<br />
<br />
==See Also==<br />
<br />
* https://github.com/bitcoin/bitcoin/pull/7692 - The pull request where removing the alert system from [[Bitcoin Core]] was discussed<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Alert_system 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Draft_138&diff=3085Draft 1382022-11-20T13:19:50Z<p>Brendan: Brendan moved page Directed Acyclic Graph to Draft 138</p>
<hr />
<div>A Directed Acyclic Graph (DAG) is a directed [[graph]] with no directed cycles. <br />
<br />
That is, it consists of vertices connected by lines (edges), with each edge directed from one vertex to another, such that following those directions will never form a closed loop.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Directed_Acyclic_Graph&diff=3086Directed Acyclic Graph2022-11-20T13:19:50Z<p>Brendan: Brendan moved page Directed Acyclic Graph to Draft 138</p>
<hr />
<div>#REDIRECT [[Draft 138]]</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Draft_139&diff=3084Draft 1392022-11-20T13:16:55Z<p>Brendan: Brendan moved page The Alert Key to Draft 139 without leaving a redirect</p>
<hr />
<div>[[File:Prefinal alert.png|thumb|300px|The prefinal alert message in the status bar of the GUI client]]Bitcoin versions 0.3.10 introduced an '''alert key''' system which allowed messages about critical network problems to be broadcast to all clients.<br />
<br />
The original alert system was removed in Bitcoin Core release 0.13.0.<br />
<br />
When an alert was in effect, the message it contained would appear in a status bar in all clients and in the "errors" field of RPC ''getinfo''. Any script registered with the <code>-alertnotify</code> command-line option will be notified.<br />
<br />
===Alert message===<br />
Alerts were broadcast using the same TCP relay system as ''block'' and ''tx'' messages. They were not encoded in a special transaction. Unlike block and tx relaying, alerts were sent at the start of every new connection for as long as the alert was in effect. This ensured that everyone received the alert.<br />
<br />
Alerts contained this information:<br />
* How long to relay the alert.<br />
* How long to consider the alert valid.<br />
* An alert ID number.<br />
* A list of alerts that should be canceled upon receipt of this alert.<br />
* Exactly which versions of Bitcoin are affected by the alert. Unaffected versions still relay the alert for the benefit of older versions.<br />
* Alert priority.<br />
* The alert text.<br />
<br />
Only alerts that are signed by a specific ECDSA public key were considered valid, but the private key was made public after the alert system was retired.<br />
<br />
===Safe mode===<br />
Until version 0.3.20, Bitcoin went into safe mode when a valid alert was received. In safe mode, all RPC commands that send BTC or get info about received BTC return an error.<br />
<br />
==History==<br />
{{multiple image|align=vertical|width=300<br />
|image1=alert.png<br />
|image2=bitcoin-alert-cli.png<br />
|footer=An alert appearing on bitcoin clients<br />
}}<br />
<br />
The alert system was implemented by [[Satoshi Nakamoto]] after the [[value overflow incident]] on August 15, 2010.<br />
<br />
===List of published alerts prior to Alert Key removal===<br />
{| class="wikitable" border="1"<br />
|-<br />
! ID<br />
! Sent date<br />
! Expires (UTC)<br />
! Versions<br />
! Priority<br />
! Message<br />
|-<br />
| 1010<br />
| Feb 18, 2012<br />
| Feb 21 02:47:15<br />
| All<br />
| 100<br />
| See bitcoin.org/feb20 if you have trouble connecting after 20 February<br />
|-<br />
| 1011<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 0.5 - 0.5.3<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1012<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 6.0<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1013<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 5.99<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1015<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.1 - 0.4.5<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1016<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.4.99 - 0.5.4<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1020<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.6.0<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1032<br />
| March 12, 2013<br />
| March 13, 2013<br />
| 0.8.0<br />
| 5000<br />
| URGENT: chain fork, stop mining on version 0.8<br />
|-<br />
| 1033<br />
| March 19, 2013<br />
| March 20, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| See http://bitcoin.org/may15.html for an important message<br />
|-<br />
| 1034<br />
| May 9, 2013<br />
| June 8, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| Action required: see http://bitcoin.org/may15.html for more information<br />
|-<br />
| 1040<br />
| April 11, 2014<br />
| cancelled<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed/<br />
|-<br />
| 1041<br />
| April 11, 2014<br />
| April 11, 2015<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed<br />
|}<br />
<br />
==See Also==<br />
<br />
* https://github.com/bitcoin/bitcoin/pull/7692 - The pull request where removing the alert system from [[Bitcoin Core]] was discussed<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Alert_system 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Main_Page&diff=3083Main Page2022-11-08T13:23:01Z<p>Brendan: /* Alert Key */</p>
<hr />
<div>Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality.<br />
<br />
===Bitcoin===<br />
<br />
'''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 [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper] in October 2008, and the source code was [https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html released] in January 2009. The Bitcoin ledger and [[Blockchain]] were established with the generation of the [[Genesis block]] on the 3rd of January 2009 and the mining of Block 1 six days later on the 9th of January 2009.<br />
<br />
Bitcoin allows electronic payments to be sent directly from one party to another, without requiring a central institution or server to process transactions and/or store funds. <br />
<br />
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.<br />
<br />
===Applications===<br />
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. But developments such as [[Paymail]] and [[Simplified Payment Verification]] are changing the landscape and making it much easier for users to connect and leverage the blockchain for the [[back-end]] of their applications.<br />
<br />
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 [[Micropayment]]s become a means to both access and monetize data.<br />
<br />
Applications which make use of the immutable nature of the [[Blockchain|Bitcoin Ledger]] to store and retrieve data are emerging at an increasing rate. [[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.<br />
<br />
===Network===<br />
[[The Bitcoin Network]] is the network that all peers use to access the ledger. The network forms spontaneously over time as more peers access and use the system. There is no central governance that determines how peers on the network must connect, but the incentive structure that Bitcoin employs to bring enterprise miners into the system results in the formation of a small world network which is simple and resilient. <br />
<br />
Once the final restrictions on the [[protocol]] are removed in the [[Chronicle Update]] (expected early-mid 2021) network users will be able to create partitioned zones which employ specific rulesets particular to their requirements. This will be enabled by creating transactions that use [[OP_VER]] to give particular subsets of nodes specialised instructions, and will create the effect of layered network partitions over the core system which are referred to as [[Bitcoin Layered Networks]].<br />
<br />
===The Ledger===<br />
The Bitcoin ledger is a record of all valid transactions that have ever been transmitted to 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.<br />
<br />
<div class="img-responsive"><br />
[[File:Chain_of_Signatures.png|centre|alt=Electronic coins are defined as a chain of digital signatures]]<br />
</div><br />
<br />
Valid transactions that are broadcast on [[The Bitcoin Network]] are committed to the ledger by miners in [[Block|Blocks]]. A block consists of a [[Block hashing algorithm#Block_Header|header]] which contains a timestamp, a reference to the block it builds on, a valid [[Proof of Work]] and the double [[SHA-256]] hash of the root of a [[wikipedia:Merkle Tree|Merkle tree]] generated with a list of transactions, and the list of transactions. Most nodes use compact block propagation techniques which [[compress]] the list of transactions to a much smaller size rather than broadcasting the full block. Receiving Nodes must decompress the block using a list of validated transactions that they have also compacted.<br />
<br />
Blocks form a second layer DAG called the [[Blockchain]] 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 become 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]].<br />
<br />
<div class="img-responsive"><br />
[[File:Block_Chain.png|centre|alt=A chain of blocks]]<br />
</div><br />
<br />
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.<br />
<br />
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.<br />
<br />
<div class="img-responsive"><br />
[[File:Simplified_Payment_Verification.png|centre|alt=Simplified payment verification]]<br />
</div><br />
<br />
Users can exchange unfinalised transactions without sending them to the network to be mined creating what are called [[Payment Channels]].<br />
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.<br />
<br />
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 template, it is considered invalid. Transactions can be invalid for a variety of reasons such as being submitted with an invalid scriptSig, not adhering to [[Protocol|network or miner rules]], or not paying an adequate fee.<br />
<br />
===Transactions===<br />
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 [[VOUT|output]] via the creation of arbitrary spending conditions defined by scripts.<br />
<br />
Each transaction uses bitcoins stored in '[[UTXO|unspent transaction outputs]]' as the transaction inputs. The transaction process aggregates the [[satoshis]] held in each input and spends them into a new set of unspent transaction outputs. When UTXOs are spent in a transaction they are consumed.<br />
<br />
<div class="img-responsive"><br />
[[File:Transaction.png|centre|alt=Transaction inputs and outputs]]<br />
</div><br />
<br />
The Bitcoin scripting language is [[wikipedia:Turing_completeness|Turing complete]], and can be used to create [[wikipedia:Turing_machine|Turing machines]] that use the Bitcoin ledger as a tape, writing to and reading from the transaction graph as needed.<br />
<br />
The scripting language 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]].<br />
<br />
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 first transaction in the block's [[wikipedia:Merkle tree|Merkle tree]].<br />
<br />
===Nodes and Mining===<br />
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 enforce 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.<br />
<br />
<div class="img-responsive"><br />
[[File:Proof_of_Work.png|centre|alt=A chain of hash based proof of work]]<br />
</div><br />
<br />
During the [[mining]] process, a node gathers transactions from the network on a [[First seen rule|first seen]] basis 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. Hash operators continuously request new block templates through the [[Getminingcandidate]] interface to ensure they are getting up-to-date block data to hash against. 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.<br />
<br />
[[File:Merkle tree.png|centre|alt=The structure of a Merkle Tree]]<br />
<br />
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 each miner is connected to most of the other miners. Miners gather transactions from users who connect in a layered network over the nodes at the core forming something that closely resembles a [[Mandala Network]]. Peers operating in these shell-like layers use [[Simplified Payment Verification]] to form a much less densely packed structure where information is exchanged in [[Payment Channels]].<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Alert Key===<br />
<br />
<br />
===Unit of account===<br />
[[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.<br />
<br />
Satoshis are distributed by miners to themselves as a [[Block subsidy|subsidy payment]] during the network establishment phase. As the network matures, 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.<br />
<br />
===Network rules===<br />
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.<br />
<br />
There are no limits in the [[Protocol|Bitcoin protocol]]. Any limits imposed 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.<br />
<br />
===History===<br />
[[Bitcoin until today|Bitcoin has a rich history]].<br />
<br />
===Tools and Building on Bitcoin===<br />
Bitcoin has a rich and diverse [[Building on Bitcoin|set of tools]] which are being added to all the time.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Main_Page&diff=3082Main Page2022-11-08T13:22:47Z<p>Brendan: /* Alert Key */</p>
<hr />
<div>Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality.<br />
<br />
===Bitcoin===<br />
<br />
'''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 [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper] in October 2008, and the source code was [https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html released] in January 2009. The Bitcoin ledger and [[Blockchain]] were established with the generation of the [[Genesis block]] on the 3rd of January 2009 and the mining of Block 1 six days later on the 9th of January 2009.<br />
<br />
Bitcoin allows electronic payments to be sent directly from one party to another, without requiring a central institution or server to process transactions and/or store funds. <br />
<br />
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.<br />
<br />
===Applications===<br />
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. But developments such as [[Paymail]] and [[Simplified Payment Verification]] are changing the landscape and making it much easier for users to connect and leverage the blockchain for the [[back-end]] of their applications.<br />
<br />
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 [[Micropayment]]s become a means to both access and monetize data.<br />
<br />
Applications which make use of the immutable nature of the [[Blockchain|Bitcoin Ledger]] to store and retrieve data are emerging at an increasing rate. [[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.<br />
<br />
===Network===<br />
[[The Bitcoin Network]] is the network that all peers use to access the ledger. The network forms spontaneously over time as more peers access and use the system. There is no central governance that determines how peers on the network must connect, but the incentive structure that Bitcoin employs to bring enterprise miners into the system results in the formation of a small world network which is simple and resilient. <br />
<br />
Once the final restrictions on the [[protocol]] are removed in the [[Chronicle Update]] (expected early-mid 2021) network users will be able to create partitioned zones which employ specific rulesets particular to their requirements. This will be enabled by creating transactions that use [[OP_VER]] to give particular subsets of nodes specialised instructions, and will create the effect of layered network partitions over the core system which are referred to as [[Bitcoin Layered Networks]].<br />
<br />
===The Ledger===<br />
The Bitcoin ledger is a record of all valid transactions that have ever been transmitted to 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.<br />
<br />
<div class="img-responsive"><br />
[[File:Chain_of_Signatures.png|centre|alt=Electronic coins are defined as a chain of digital signatures]]<br />
</div><br />
<br />
Valid transactions that are broadcast on [[The Bitcoin Network]] are committed to the ledger by miners in [[Block|Blocks]]. A block consists of a [[Block hashing algorithm#Block_Header|header]] which contains a timestamp, a reference to the block it builds on, a valid [[Proof of Work]] and the double [[SHA-256]] hash of the root of a [[wikipedia:Merkle Tree|Merkle tree]] generated with a list of transactions, and the list of transactions. Most nodes use compact block propagation techniques which [[compress]] the list of transactions to a much smaller size rather than broadcasting the full block. Receiving Nodes must decompress the block using a list of validated transactions that they have also compacted.<br />
<br />
Blocks form a second layer DAG called the [[Blockchain]] 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 become 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]].<br />
<br />
<div class="img-responsive"><br />
[[File:Block_Chain.png|centre|alt=A chain of blocks]]<br />
</div><br />
<br />
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.<br />
<br />
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.<br />
<br />
<div class="img-responsive"><br />
[[File:Simplified_Payment_Verification.png|centre|alt=Simplified payment verification]]<br />
</div><br />
<br />
Users can exchange unfinalised transactions without sending them to the network to be mined creating what are called [[Payment Channels]].<br />
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.<br />
<br />
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 template, it is considered invalid. Transactions can be invalid for a variety of reasons such as being submitted with an invalid scriptSig, not adhering to [[Protocol|network or miner rules]], or not paying an adequate fee.<br />
<br />
===Transactions===<br />
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 [[VOUT|output]] via the creation of arbitrary spending conditions defined by scripts.<br />
<br />
Each transaction uses bitcoins stored in '[[UTXO|unspent transaction outputs]]' as the transaction inputs. The transaction process aggregates the [[satoshis]] held in each input and spends them into a new set of unspent transaction outputs. When UTXOs are spent in a transaction they are consumed.<br />
<br />
<div class="img-responsive"><br />
[[File:Transaction.png|centre|alt=Transaction inputs and outputs]]<br />
</div><br />
<br />
The Bitcoin scripting language is [[wikipedia:Turing_completeness|Turing complete]], and can be used to create [[wikipedia:Turing_machine|Turing machines]] that use the Bitcoin ledger as a tape, writing to and reading from the transaction graph as needed.<br />
<br />
The scripting language 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]].<br />
<br />
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 first transaction in the block's [[wikipedia:Merkle tree|Merkle tree]].<br />
<br />
===Nodes and Mining===<br />
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 enforce 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.<br />
<br />
<div class="img-responsive"><br />
[[File:Proof_of_Work.png|centre|alt=A chain of hash based proof of work]]<br />
</div><br />
<br />
During the [[mining]] process, a node gathers transactions from the network on a [[First seen rule|first seen]] basis 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. Hash operators continuously request new block templates through the [[Getminingcandidate]] interface to ensure they are getting up-to-date block data to hash against. 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.<br />
<br />
[[File:Merkle tree.png|centre|alt=The structure of a Merkle Tree]]<br />
<br />
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 each miner is connected to most of the other miners. Miners gather transactions from users who connect in a layered network over the nodes at the core forming something that closely resembles a [[Mandala Network]]. Peers operating in these shell-like layers use [[Simplified Payment Verification]] to form a much less densely packed structure where information is exchanged in [[Payment Channels]].<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Alert Key==<br />
<br />
<br />
===Unit of account===<br />
[[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.<br />
<br />
Satoshis are distributed by miners to themselves as a [[Block subsidy|subsidy payment]] during the network establishment phase. As the network matures, 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.<br />
<br />
===Network rules===<br />
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.<br />
<br />
There are no limits in the [[Protocol|Bitcoin protocol]]. Any limits imposed 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.<br />
<br />
===History===<br />
[[Bitcoin until today|Bitcoin has a rich history]].<br />
<br />
===Tools and Building on Bitcoin===<br />
Bitcoin has a rich and diverse [[Building on Bitcoin|set of tools]] which are being added to all the time.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Draft_139&diff=3081Draft 1392022-11-08T13:22:09Z<p>Brendan: Created page with "The prefinal alert message in the status bar of the GUI clientBitcoin versions 0.3.10 introduced an '''alert key''' system which allow..."</p>
<hr />
<div>[[File:Prefinal alert.png|thumb|300px|The prefinal alert message in the status bar of the GUI client]]Bitcoin versions 0.3.10 introduced an '''alert key''' system which allowed messages about critical network problems to be broadcast to all clients.<br />
<br />
The original alert system was removed in Bitcoin Core release 0.13.0.<br />
<br />
When an alert was in effect, the message it contained would appear in a status bar in all clients and in the "errors" field of RPC ''getinfo''. Any script registered with the <code>-alertnotify</code> command-line option will be notified.<br />
<br />
===Alert message===<br />
Alerts were broadcast using the same TCP relay system as ''block'' and ''tx'' messages. They were not encoded in a special transaction. Unlike block and tx relaying, alerts were sent at the start of every new connection for as long as the alert was in effect. This ensured that everyone received the alert.<br />
<br />
Alerts contained this information:<br />
* How long to relay the alert.<br />
* How long to consider the alert valid.<br />
* An alert ID number.<br />
* A list of alerts that should be canceled upon receipt of this alert.<br />
* Exactly which versions of Bitcoin are affected by the alert. Unaffected versions still relay the alert for the benefit of older versions.<br />
* Alert priority.<br />
* The alert text.<br />
<br />
Only alerts that are signed by a specific ECDSA public key were considered valid, but the private key was made public after the alert system was retired.<br />
<br />
===Safe mode===<br />
Until version 0.3.20, Bitcoin went into safe mode when a valid alert was received. In safe mode, all RPC commands that send BTC or get info about received BTC return an error.<br />
<br />
==History==<br />
{{multiple image|align=vertical|width=300<br />
|image1=alert.png<br />
|image2=bitcoin-alert-cli.png<br />
|footer=An alert appearing on bitcoin clients<br />
}}<br />
<br />
The alert system was implemented by [[Satoshi Nakamoto]] after the [[value overflow incident]] on August 15, 2010.<br />
<br />
===List of published alerts prior to Alert Key removal===<br />
{| class="wikitable" border="1"<br />
|-<br />
! ID<br />
! Sent date<br />
! Expires (UTC)<br />
! Versions<br />
! Priority<br />
! Message<br />
|-<br />
| 1010<br />
| Feb 18, 2012<br />
| Feb 21 02:47:15<br />
| All<br />
| 100<br />
| See bitcoin.org/feb20 if you have trouble connecting after 20 February<br />
|-<br />
| 1011<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 0.5 - 0.5.3<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1012<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 6.0<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1013<br />
| Mar 16, 2012<br />
| cancelled May 15, 2012<br />
| 5.99<br />
| 5000<br />
| URGENT: security fix for Bitcoin-Qt on Windows: http://bitcoin.org/critfix<br />
|-<br />
| 1015<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.1 - 0.4.5<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1016<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.4.99 - 0.5.4<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1020<br />
| May 15, 2012<br />
| May 16, 2013<br />
| 0.6.0<br />
| 5000<br />
| URGENT: upgrade required, see http://bitcoin.org/dos for details<br />
|-<br />
| 1032<br />
| March 12, 2013<br />
| March 13, 2013<br />
| 0.8.0<br />
| 5000<br />
| URGENT: chain fork, stop mining on version 0.8<br />
|-<br />
| 1033<br />
| March 19, 2013<br />
| March 20, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| See http://bitcoin.org/may15.html for an important message<br />
|-<br />
| 1034<br />
| May 9, 2013<br />
| June 8, 2013<br />
| 0.1 - 0.7.2<br />
| 10<br />
| Action required: see http://bitcoin.org/may15.html for more information<br />
|-<br />
| 1040<br />
| April 11, 2014<br />
| cancelled<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed/<br />
|-<br />
| 1041<br />
| April 11, 2014<br />
| April 11, 2015<br />
| 0.9.0<br />
| 5000<br />
| URGENT: Upgrade required: see https://www.bitcoin.org/heartbleed<br />
|}<br />
<br />
==See Also==<br />
<br />
* https://github.com/bitcoin/bitcoin/pull/7692 - The pull request where removing the alert system from [[Bitcoin Core]] was discussed<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Alert_system 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Main_Page&diff=3080Main Page2022-11-08T13:13:47Z<p>Brendan: /* Nodes and Mining */</p>
<hr />
<div>Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality.<br />
<br />
===Bitcoin===<br />
<br />
'''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 [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper] in October 2008, and the source code was [https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html released] in January 2009. The Bitcoin ledger and [[Blockchain]] were established with the generation of the [[Genesis block]] on the 3rd of January 2009 and the mining of Block 1 six days later on the 9th of January 2009.<br />
<br />
Bitcoin allows electronic payments to be sent directly from one party to another, without requiring a central institution or server to process transactions and/or store funds. <br />
<br />
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.<br />
<br />
===Applications===<br />
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. But developments such as [[Paymail]] and [[Simplified Payment Verification]] are changing the landscape and making it much easier for users to connect and leverage the blockchain for the [[back-end]] of their applications.<br />
<br />
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 [[Micropayment]]s become a means to both access and monetize data.<br />
<br />
Applications which make use of the immutable nature of the [[Blockchain|Bitcoin Ledger]] to store and retrieve data are emerging at an increasing rate. [[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.<br />
<br />
===Network===<br />
[[The Bitcoin Network]] is the network that all peers use to access the ledger. The network forms spontaneously over time as more peers access and use the system. There is no central governance that determines how peers on the network must connect, but the incentive structure that Bitcoin employs to bring enterprise miners into the system results in the formation of a small world network which is simple and resilient. <br />
<br />
Once the final restrictions on the [[protocol]] are removed in the [[Chronicle Update]] (expected early-mid 2021) network users will be able to create partitioned zones which employ specific rulesets particular to their requirements. This will be enabled by creating transactions that use [[OP_VER]] to give particular subsets of nodes specialised instructions, and will create the effect of layered network partitions over the core system which are referred to as [[Bitcoin Layered Networks]].<br />
<br />
===The Ledger===<br />
The Bitcoin ledger is a record of all valid transactions that have ever been transmitted to 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.<br />
<br />
<div class="img-responsive"><br />
[[File:Chain_of_Signatures.png|centre|alt=Electronic coins are defined as a chain of digital signatures]]<br />
</div><br />
<br />
Valid transactions that are broadcast on [[The Bitcoin Network]] are committed to the ledger by miners in [[Block|Blocks]]. A block consists of a [[Block hashing algorithm#Block_Header|header]] which contains a timestamp, a reference to the block it builds on, a valid [[Proof of Work]] and the double [[SHA-256]] hash of the root of a [[wikipedia:Merkle Tree|Merkle tree]] generated with a list of transactions, and the list of transactions. Most nodes use compact block propagation techniques which [[compress]] the list of transactions to a much smaller size rather than broadcasting the full block. Receiving Nodes must decompress the block using a list of validated transactions that they have also compacted.<br />
<br />
Blocks form a second layer DAG called the [[Blockchain]] 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 become 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]].<br />
<br />
<div class="img-responsive"><br />
[[File:Block_Chain.png|centre|alt=A chain of blocks]]<br />
</div><br />
<br />
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.<br />
<br />
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.<br />
<br />
<div class="img-responsive"><br />
[[File:Simplified_Payment_Verification.png|centre|alt=Simplified payment verification]]<br />
</div><br />
<br />
Users can exchange unfinalised transactions without sending them to the network to be mined creating what are called [[Payment Channels]].<br />
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.<br />
<br />
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 template, it is considered invalid. Transactions can be invalid for a variety of reasons such as being submitted with an invalid scriptSig, not adhering to [[Protocol|network or miner rules]], or not paying an adequate fee.<br />
<br />
===Transactions===<br />
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 [[VOUT|output]] via the creation of arbitrary spending conditions defined by scripts.<br />
<br />
Each transaction uses bitcoins stored in '[[UTXO|unspent transaction outputs]]' as the transaction inputs. The transaction process aggregates the [[satoshis]] held in each input and spends them into a new set of unspent transaction outputs. When UTXOs are spent in a transaction they are consumed.<br />
<br />
<div class="img-responsive"><br />
[[File:Transaction.png|centre|alt=Transaction inputs and outputs]]<br />
</div><br />
<br />
The Bitcoin scripting language is [[wikipedia:Turing_completeness|Turing complete]], and can be used to create [[wikipedia:Turing_machine|Turing machines]] that use the Bitcoin ledger as a tape, writing to and reading from the transaction graph as needed.<br />
<br />
The scripting language 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]].<br />
<br />
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 first transaction in the block's [[wikipedia:Merkle tree|Merkle tree]].<br />
<br />
===Nodes and Mining===<br />
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 enforce 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.<br />
<br />
<div class="img-responsive"><br />
[[File:Proof_of_Work.png|centre|alt=A chain of hash based proof of work]]<br />
</div><br />
<br />
During the [[mining]] process, a node gathers transactions from the network on a [[First seen rule|first seen]] basis 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. Hash operators continuously request new block templates through the [[Getminingcandidate]] interface to ensure they are getting up-to-date block data to hash against. 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.<br />
<br />
[[File:Merkle tree.png|centre|alt=The structure of a Merkle Tree]]<br />
<br />
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 each miner is connected to most of the other miners. Miners gather transactions from users who connect in a layered network over the nodes at the core forming something that closely resembles a [[Mandala Network]]. Peers operating in these shell-like layers use [[Simplified Payment Verification]] to form a much less densely packed structure where information is exchanged in [[Payment Channels]].<br />
<br />
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.<br />
<br />
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.<br />
<br />
==Alert Key==<br />
[[The Alert Key]]<br />
<br />
===Unit of account===<br />
[[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.<br />
<br />
Satoshis are distributed by miners to themselves as a [[Block subsidy|subsidy payment]] during the network establishment phase. As the network matures, 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.<br />
<br />
===Network rules===<br />
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.<br />
<br />
There are no limits in the [[Protocol|Bitcoin protocol]]. Any limits imposed 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.<br />
<br />
===History===<br />
[[Bitcoin until today|Bitcoin has a rich history]].<br />
<br />
===Tools and Building on Bitcoin===<br />
Bitcoin has a rich and diverse [[Building on Bitcoin|set of tools]] which are being added to all the time.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Opcodes_used_in_Bitcoin_Script&diff=3079Opcodes used in Bitcoin Script2022-10-09T02:54:15Z<p>Brendan: </p>
<hr />
<div>This is a list of all Script words, also known as opcodes, commands, or functions.<br />
<br />
OP_NOP1-OP_NOP10 were originally set aside to be used when HASH and other security functions become insecure due to improvements in computing.<br />
<br />
False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|[[Pushdata Opcodes|Pushdata Bytelength]]<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA1]]<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA2]]<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA4]]<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_VER '''DISABLED'''<br />
|98<br />
|0x62<br />
|Nothing<br />
|Protocol version<br />
|Puts the version of the protocol under which this transaction will be evaluated onto the stack.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<br />
<code><br />
[expression] IF<br />
[statement 1]<br />
ENDIF<br />
</code><br />
</br>OR<br />
</br><code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF<br />
</code><br />
|If the top stack value is TRUE, statement 1 is executed.<br />
If the top stack value is FALSE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<br />
<code><br />
[expression] NOTIF<br />
[statement 1]<br />
ENDIF<br />
</code></br>OR<br />
</br><code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF<br />
</code><br />
|If the top stack value is FALSE, statement 1 is executed.<br />
If the top stack value is TRUE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_VERIF '''DISABLED'''<br />
|101<br />
|0x65<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_VERNOTIF '''DISABLED'''<br />
|102<br />
|0x66<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<br />
<code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF </code><br />
|If the preceding IF or NOTIF check was not valid then statement 2 is executed.<br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<br />
<code><br />
[expression]<br />
IF<br />
[statements]<br />
ELSE<br />
[statements]<br />
ENDIF<br />
</code><br />
|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'''.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / ''fail''<br />
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.<br />
|-<br />
|[[OP_RETURN]]<br />
|106<br />
|0x6a<br />
|Nothing<br />
|''Ends script with top value on stack as final result''<br />
| 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.<br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Counts the number of stack items onto the stack and places the value on the top<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|}<br />
<br />
===Data Manipulation===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|Concatenates two strings.<br />
|-<br />
|OP_SPLIT<br />
|127<br />
|0x7f<br />
|x n<br />
|x1 x2<br />
|Splits byte sequence x at position n.<br />
|-<br />
|OP_NUM2BIN<br />
|128<br />
|0x80<br />
|a b<br />
| out<br />
|Converts numeric value a into byte sequence of length b.<br />
|-<br />
|OP_BIN2NUM<br />
|129<br />
|0x81<br />
| x<br />
| out<br />
|Converts byte sequence x into a numeric value.<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Pushes the string length of the top element of the stack (without popping it).<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|Flips all of the bits in the input.<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|Boolean ''and'' between each bit in the inputs.<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|Boolean ''or'' between each bit in the inputs.<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|Boolean ''exclusive or'' between each bit in the inputs.<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|Nothing / ''fail''<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
BitcoinScript supports arithmetic on bignum values<br />
A bignum is a byte sequence that represents a numeric value. The length of the byte sequence must be less than or equal to 750,000 bytes. Byte sequences larger than 750,000 bytes are valid in Bitcoin however current rules dictate that they are not recognised as a valid numeric value.<br />
<br />
Note that while some operations require parameters to be valid numeric values, they may produce byte sequences which are not valid numeric values (for example, OP_MUL may produce a byte sequence which is too large to validly represent a numeric value).<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL '''DISABLED'''<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|The input is multiplied by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_2DIV '''DISABLED'''<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|The input is divided by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|a is multiplied by b.<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|a is divided by b.<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|Returns the remainder after dividing a by b.<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|Logical left shift b bits. Sign data is discarded<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|Logical right shift b bits. Sign data is discarded<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|Nothing / ''fail''<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Cryptography ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|[[OP_CODESEPARATOR]]<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|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.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|Nothing / ''fail''<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|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, an extra unused value (x) is removed from the stack. Script spenders must account for this by adding a junk value (typically zero) to the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|Nothing / ''fail''<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
=== Used NOP opcode identifiers ===<br />
In Bitcoin's history, new opcodes were added that used reserved NO_OP opcode identifiers. These opcodes have been reverted to the original OP_NOP functionality.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word <br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP2<br />
<br />
(previously OP_CHECKLOCKTIMEVERIFY)<br />
|177<br />
|0xb1<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|-<br />
|OP_NOP3<br />
<br />
(previously OP_CHECKSEQUENCEVERIFY)<br />
|178<br />
|0xb2<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1, OP_NOP4-OP_NOP10<br />
|176, 179-185<br />
|0xb0, 0xb3-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
==Examples==<br />
<br />
For examples of common Bitcoin transaction scripts please see [[Bitcoin Transactions]]<br />
<br />
==Attribution==<br />
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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Opcodes_used_in_Bitcoin_Script&diff=3078Opcodes used in Bitcoin Script2022-10-09T02:52:54Z<p>Brendan: </p>
<hr />
<div>This is a list of all Script words, also known as opcodes, commands, or functions.<br />
<br />
OP_NOP1-OP_NOP10 were originally set aside to be used when HASH and other security functions become insecure due to improvements in computing.<br />
<br />
False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|[[Pushdata Opcodes|Pushdata Bytelength]]<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA1]]<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA2]]<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA4]]<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_VER '''DISABLED'''<br />
|98<br />
|0x62<br />
|Nothing<br />
|Protocol version<br />
|Puts the version of the protocol under which this transaction will be evaluated onto the stack.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<br />
<code><br />
[expression] IF<br />
[statement 1]<br />
ENDIF<br />
</code><br />
</br>OR<br />
</br><code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF<br />
</code><br />
|If the top stack value is TRUE, statement 1 is executed.<br />
If the top stack value is FALSE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<br />
<code><br />
[expression] NOTIF<br />
[statement 1]<br />
ENDIF<br />
</code></br>OR<br />
</br><code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF<br />
</code><br />
|If the top stack value is FALSE, statement 1 is executed.<br />
If the top stack value is TRUE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_VERIF '''DISABLED'''<br />
|101<br />
|0x65<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_VERNOTIF '''DISABLED'''<br />
|102<br />
|0x66<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<br />
<code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF </code><br />
|If the preceding IF or NOTIF check was not valid then statement 2 is executed.<br />
|-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<br />
[expression]<br />
IF<br />
[statements]<br />
ELSE<br />
[statements]<br />
ENDIF<br />
|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'''.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / ''fail''<br />
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.<br />
|-<br />
|[[OP_RETURN]]<br />
|106<br />
|0x6a<br />
|Nothing<br />
|''Ends script with top value on stack as final result''<br />
| 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.<br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Counts the number of stack items onto the stack and places the value on the top<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|}<br />
<br />
===Data Manipulation===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|Concatenates two strings.<br />
|-<br />
|OP_SPLIT<br />
|127<br />
|0x7f<br />
|x n<br />
|x1 x2<br />
|Splits byte sequence x at position n.<br />
|-<br />
|OP_NUM2BIN<br />
|128<br />
|0x80<br />
|a b<br />
| out<br />
|Converts numeric value a into byte sequence of length b.<br />
|-<br />
|OP_BIN2NUM<br />
|129<br />
|0x81<br />
| x<br />
| out<br />
|Converts byte sequence x into a numeric value.<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Pushes the string length of the top element of the stack (without popping it).<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|Flips all of the bits in the input.<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|Boolean ''and'' between each bit in the inputs.<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|Boolean ''or'' between each bit in the inputs.<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|Boolean ''exclusive or'' between each bit in the inputs.<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|Nothing / ''fail''<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
BitcoinScript supports arithmetic on bignum values<br />
A bignum is a byte sequence that represents a numeric value. The length of the byte sequence must be less than or equal to 750,000 bytes. Byte sequences larger than 750,000 bytes are valid in Bitcoin however current rules dictate that they are not recognised as a valid numeric value.<br />
<br />
Note that while some operations require parameters to be valid numeric values, they may produce byte sequences which are not valid numeric values (for example, OP_MUL may produce a byte sequence which is too large to validly represent a numeric value).<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL '''DISABLED'''<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|The input is multiplied by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_2DIV '''DISABLED'''<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|The input is divided by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|a is multiplied by b.<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|a is divided by b.<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|Returns the remainder after dividing a by b.<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|Logical left shift b bits. Sign data is discarded<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|Logical right shift b bits. Sign data is discarded<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|Nothing / ''fail''<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Cryptography ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|[[OP_CODESEPARATOR]]<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|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.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|Nothing / ''fail''<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|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, an extra unused value (x) is removed from the stack. Script spenders must account for this by adding a junk value (typically zero) to the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|Nothing / ''fail''<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
=== Used NOP opcode identifiers ===<br />
In Bitcoin's history, new opcodes were added that used reserved NO_OP opcode identifiers. These opcodes have been reverted to the original OP_NOP functionality.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word <br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP2<br />
<br />
(previously OP_CHECKLOCKTIMEVERIFY)<br />
|177<br />
|0xb1<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|-<br />
|OP_NOP3<br />
<br />
(previously OP_CHECKSEQUENCEVERIFY)<br />
|178<br />
|0xb2<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1, OP_NOP4-OP_NOP10<br />
|176, 179-185<br />
|0xb0, 0xb3-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
==Examples==<br />
<br />
For examples of common Bitcoin transaction scripts please see [[Bitcoin Transactions]]<br />
<br />
==Attribution==<br />
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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Opcodes_used_in_Bitcoin_Script&diff=3077Opcodes used in Bitcoin Script2022-10-07T07:45:23Z<p>Brendan: </p>
<hr />
<div>This is a list of all Script words, also known as opcodes, commands, or functions.<br />
<br />
OP_NOP1-OP_NOP10 were originally set aside to be used when HASH and other security functions become insecure due to improvements in computing.<br />
<br />
False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|[[Pushdata Opcodes|Pushdata Bytelength]]<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA1]]<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA2]]<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA4]]<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_VER '''DISABLED'''<br />
|98<br />
|0x62<br />
|Nothing<br />
|Protocol version<br />
|Puts the version of the protocol under which this transaction will be evaluated onto the stack.</br><br />
(This opcode is scheduled to be re-enabled in the Chronicle update)</br><br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<br />
<code><br />
[expression] IF<br />
[statement 1]<br />
ENDIF<br />
</code><br />
</br>OR<br />
</br><code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF<br />
</code><br />
|If the top stack value is TRUE, statement 1 is executed.<br />
If the top stack value is FALSE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<br />
<code><br />
[expression] NOTIF<br />
[statement 1]<br />
ENDIF<br />
</code></br>OR<br />
</br><code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF<br />
</code><br />
|If the top stack value is FALSE, statement 1 is executed.<br />
If the top stack value is TRUE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_VERIF '''DISABLED'''<br />
|101<br />
|0x65<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_VERNOTIF '''DISABLED'''<br />
|102<br />
|0x66<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<br />
<code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF </code><br />
|If the preceding IF or NOTIF check was not valid then statement 2 is executed. |-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|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'''.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / ''fail''<br />
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.<br />
|-<br />
|[[OP_RETURN]]<br />
|106<br />
|0x6a<br />
|Nothing<br />
|''Ends script with top value on stack as final result''<br />
| 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.<br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Counts the number of stack items onto the stack and places the value on the top<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|}<br />
<br />
===Data Manipulation===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|Concatenates two strings.<br />
|-<br />
|OP_SPLIT<br />
|127<br />
|0x7f<br />
|x n<br />
|x1 x2<br />
|Splits byte sequence x at position n.<br />
|-<br />
|OP_NUM2BIN<br />
|128<br />
|0x80<br />
|a b<br />
| out<br />
|Converts numeric value a into byte sequence of length b.<br />
|-<br />
|OP_BIN2NUM<br />
|129<br />
|0x81<br />
| x<br />
| out<br />
|Converts byte sequence x into a numeric value.<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Pushes the string length of the top element of the stack (without popping it).<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|Flips all of the bits in the input.<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|Boolean ''and'' between each bit in the inputs.<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|Boolean ''or'' between each bit in the inputs.<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|Boolean ''exclusive or'' between each bit in the inputs.<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|Nothing / ''fail''<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
BitcoinScript supports arithmetic on bignum values<br />
A bignum is a byte sequence that represents a numeric value. The length of the byte sequence must be less than or equal to 750,000 bytes. Byte sequences larger than 750,000 bytes are valid in Bitcoin however current rules dictate that they are not recognised as a valid numeric value.<br />
<br />
Note that while some operations require parameters to be valid numeric values, they may produce byte sequences which are not valid numeric values (for example, OP_MUL may produce a byte sequence which is too large to validly represent a numeric value).<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL '''DISABLED'''<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|The input is multiplied by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_2DIV '''DISABLED'''<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|The input is divided by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|a is multiplied by b.<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|a is divided by b.<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|Returns the remainder after dividing a by b.<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|Logical left shift b bits. Sign data is discarded<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|Logical right shift b bits. Sign data is discarded<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|Nothing / ''fail''<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Cryptography ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|[[OP_CODESEPARATOR]]<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|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.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|Nothing / ''fail''<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|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, an extra unused value (x) is removed from the stack. Script spenders must account for this by adding a junk value (typically zero) to the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|Nothing / ''fail''<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
=== Used NOP opcode identifiers ===<br />
In Bitcoin's history, new opcodes were added that used reserved NO_OP opcode identifiers. These opcodes have been reverted to the original OP_NOP functionality.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word <br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP2<br />
<br />
(previously OP_CHECKLOCKTIMEVERIFY)<br />
|177<br />
|0xb1<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|-<br />
|OP_NOP3<br />
<br />
(previously OP_CHECKSEQUENCEVERIFY)<br />
|178<br />
|0xb2<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1, OP_NOP4-OP_NOP10<br />
|176, 179-185<br />
|0xb0, 0xb3-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
==Examples==<br />
<br />
For examples of common Bitcoin transaction scripts please see [[Bitcoin Transactions]]<br />
<br />
==Attribution==<br />
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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Opcodes_used_in_Bitcoin_Script&diff=3076Opcodes used in Bitcoin Script2022-10-07T07:42:35Z<p>Brendan: </p>
<hr />
<div>This is a list of all Script words, also known as opcodes, commands, or functions.<br />
<br />
OP_NOP1-OP_NOP10 were originally set aside to be used when HASH and other security functions become insecure due to improvements in computing.<br />
<br />
False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|[[Pushdata Opcodes|Pushdata Bytelength]]<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA1]]<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA2]]<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA4]]<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_VER '''DISABLED'''<br />
|98<br />
|0x62<br />
|Nothing<br />
|Protocol version<br />
|Puts the version of the protocol under which this transaction will be evaluated onto the stack.</br><br />
(This opcode is scheduled to be re-enabled in the Chronicle update)</br><br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<br />
<code><br />
[expression] IF<br />
[statement 1]<br />
ENDIF<br />
</code><br />
</br>OR<br />
</br><code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF<br />
</code><br />
|If the top stack value is TRUE, statement 1 is executed.<br />
If the top stack value is FALSE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<br />
<code><br />
[expression] NOTIF<br />
[statement 1]<br />
ENDIF<br />
</code></br>OR<br />
</br><code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF<br />
</code><br />
|If the top stack value is FALSE, statement 1 is executed.<br />
If the top stack value is TRUE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_VERIF '''DISABLED'''<br />
|101<br />
|0x65<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_VERNOTIF '''DISABLED'''<br />
|102<br />
|0x66<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<code> [expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF </code><br />
|If the preceding IF or NOTIF check was not valid then statement 2 is executed. |-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|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'''.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / ''fail''<br />
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.<br />
|-<br />
|[[OP_RETURN]]<br />
|106<br />
|0x6a<br />
|Nothing<br />
|''Ends script with top value on stack as final result''<br />
| 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.<br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Counts the number of stack items onto the stack and places the value on the top<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|}<br />
<br />
===Data Manipulation===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|Concatenates two strings.<br />
|-<br />
|OP_SPLIT<br />
|127<br />
|0x7f<br />
|x n<br />
|x1 x2<br />
|Splits byte sequence x at position n.<br />
|-<br />
|OP_NUM2BIN<br />
|128<br />
|0x80<br />
|a b<br />
| out<br />
|Converts numeric value a into byte sequence of length b.<br />
|-<br />
|OP_BIN2NUM<br />
|129<br />
|0x81<br />
| x<br />
| out<br />
|Converts byte sequence x into a numeric value.<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Pushes the string length of the top element of the stack (without popping it).<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|Flips all of the bits in the input.<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|Boolean ''and'' between each bit in the inputs.<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|Boolean ''or'' between each bit in the inputs.<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|Boolean ''exclusive or'' between each bit in the inputs.<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|Nothing / ''fail''<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
BitcoinScript supports arithmetic on bignum values<br />
A bignum is a byte sequence that represents a numeric value. The length of the byte sequence must be less than or equal to 750,000 bytes. Byte sequences larger than 750,000 bytes are valid in Bitcoin however current rules dictate that they are not recognised as a valid numeric value.<br />
<br />
Note that while some operations require parameters to be valid numeric values, they may produce byte sequences which are not valid numeric values (for example, OP_MUL may produce a byte sequence which is too large to validly represent a numeric value).<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL '''DISABLED'''<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|The input is multiplied by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_2DIV '''DISABLED'''<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|The input is divided by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|a is multiplied by b.<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|a is divided by b.<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|Returns the remainder after dividing a by b.<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|Logical left shift b bits. Sign data is discarded<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|Logical right shift b bits. Sign data is discarded<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|Nothing / ''fail''<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Cryptography ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|[[OP_CODESEPARATOR]]<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|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.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|Nothing / ''fail''<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|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, an extra unused value (x) is removed from the stack. Script spenders must account for this by adding a junk value (typically zero) to the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|Nothing / ''fail''<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
=== Used NOP opcode identifiers ===<br />
In Bitcoin's history, new opcodes were added that used reserved NO_OP opcode identifiers. These opcodes have been reverted to the original OP_NOP functionality.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word <br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP2<br />
<br />
(previously OP_CHECKLOCKTIMEVERIFY)<br />
|177<br />
|0xb1<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|-<br />
|OP_NOP3<br />
<br />
(previously OP_CHECKSEQUENCEVERIFY)<br />
|178<br />
|0xb2<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1, OP_NOP4-OP_NOP10<br />
|176, 179-185<br />
|0xb0, 0xb3-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
==Examples==<br />
<br />
For examples of common Bitcoin transaction scripts please see [[Bitcoin Transactions]]<br />
<br />
==Attribution==<br />
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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Opcodes_used_in_Bitcoin_Script&diff=3075Opcodes used in Bitcoin Script2022-10-07T07:41:56Z<p>Brendan: </p>
<hr />
<div>This is a list of all Script words, also known as opcodes, commands, or functions.<br />
<br />
OP_NOP1-OP_NOP10 were originally set aside to be used when HASH and other security functions become insecure due to improvements in computing.<br />
<br />
False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|[[Pushdata Opcodes|Pushdata Bytelength]]<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA1]]<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA2]]<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA4]]<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_VER '''DISABLED'''<br />
|98<br />
|0x62<br />
|Nothing<br />
|Protocol version<br />
|Puts the version of the protocol under which this transaction will be evaluated onto the stack.</br><br />
(This opcode is scheduled to be re-enabled in the Chronicle update)</br><br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<br />
<code><br />
[expression] IF<br />
[statement 1]<br />
ENDIF<br />
</code><br />
</br>OR<br />
<code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF<br />
</code><br />
|If the top stack value is TRUE, statement 1 is executed.<br />
If the top stack value is FALSE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<br />
<code><br />
[expression] NOTIF<br />
[statement 1]<br />
ENDIF<br />
</code></br>OR<br />
<code><br />
[expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF<br />
</code><br />
|If the top stack value is FALSE, statement 1 is executed.<br />
If the top stack value is TRUE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_VERIF '''DISABLED'''<br />
|101<br />
|0x65<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_VERNOTIF '''DISABLED'''<br />
|102<br />
|0x66<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<code> [expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF </code><br />
|If the preceding IF or NOTIF check was not valid then statement 2 is executed. |-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|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'''.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / ''fail''<br />
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.<br />
|-<br />
|[[OP_RETURN]]<br />
|106<br />
|0x6a<br />
|Nothing<br />
|''Ends script with top value on stack as final result''<br />
| 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.<br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Counts the number of stack items onto the stack and places the value on the top<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|}<br />
<br />
===Data Manipulation===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|Concatenates two strings.<br />
|-<br />
|OP_SPLIT<br />
|127<br />
|0x7f<br />
|x n<br />
|x1 x2<br />
|Splits byte sequence x at position n.<br />
|-<br />
|OP_NUM2BIN<br />
|128<br />
|0x80<br />
|a b<br />
| out<br />
|Converts numeric value a into byte sequence of length b.<br />
|-<br />
|OP_BIN2NUM<br />
|129<br />
|0x81<br />
| x<br />
| out<br />
|Converts byte sequence x into a numeric value.<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Pushes the string length of the top element of the stack (without popping it).<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|Flips all of the bits in the input.<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|Boolean ''and'' between each bit in the inputs.<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|Boolean ''or'' between each bit in the inputs.<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|Boolean ''exclusive or'' between each bit in the inputs.<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|Nothing / ''fail''<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
BitcoinScript supports arithmetic on bignum values<br />
A bignum is a byte sequence that represents a numeric value. The length of the byte sequence must be less than or equal to 750,000 bytes. Byte sequences larger than 750,000 bytes are valid in Bitcoin however current rules dictate that they are not recognised as a valid numeric value.<br />
<br />
Note that while some operations require parameters to be valid numeric values, they may produce byte sequences which are not valid numeric values (for example, OP_MUL may produce a byte sequence which is too large to validly represent a numeric value).<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL '''DISABLED'''<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|The input is multiplied by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_2DIV '''DISABLED'''<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|The input is divided by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|a is multiplied by b.<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|a is divided by b.<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|Returns the remainder after dividing a by b.<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|Logical left shift b bits. Sign data is discarded<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|Logical right shift b bits. Sign data is discarded<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|Nothing / ''fail''<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Cryptography ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|[[OP_CODESEPARATOR]]<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|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.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|Nothing / ''fail''<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|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, an extra unused value (x) is removed from the stack. Script spenders must account for this by adding a junk value (typically zero) to the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|Nothing / ''fail''<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
=== Used NOP opcode identifiers ===<br />
In Bitcoin's history, new opcodes were added that used reserved NO_OP opcode identifiers. These opcodes have been reverted to the original OP_NOP functionality.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word <br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP2<br />
<br />
(previously OP_CHECKLOCKTIMEVERIFY)<br />
|177<br />
|0xb1<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|-<br />
|OP_NOP3<br />
<br />
(previously OP_CHECKSEQUENCEVERIFY)<br />
|178<br />
|0xb2<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1, OP_NOP4-OP_NOP10<br />
|176, 179-185<br />
|0xb0, 0xb3-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
==Examples==<br />
<br />
For examples of common Bitcoin transaction scripts please see [[Bitcoin Transactions]]<br />
<br />
==Attribution==<br />
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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Opcodes_used_in_Bitcoin_Script&diff=3074Opcodes used in Bitcoin Script2022-10-07T07:39:52Z<p>Brendan: </p>
<hr />
<div>This is a list of all Script words, also known as opcodes, commands, or functions.<br />
<br />
OP_NOP1-OP_NOP10 were originally set aside to be used when HASH and other security functions become insecure due to improvements in computing.<br />
<br />
False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|[[Pushdata Opcodes|Pushdata Bytelength]]<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA1]]<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA2]]<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA4]]<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_VER '''DISABLED'''<br />
|98<br />
|0x62<br />
|Nothing<br />
|Protocol version<br />
|Puts the version of the protocol under which this transaction will be evaluated onto the stack.</br><br />
(This opcode is scheduled to be re-enabled in the Chronicle update)</br><br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<code> [expression] IF<br />
[statement 1]<br />
ENDIF<br />
</code> OR<br />
<code> [expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF</code><br />
|If the top stack value is TRUE, statement 1 is executed.<br />
If the top stack value is FALSE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<code> [expression] NOTIF<br />
[statement 1]<br />
ENDIF<br />
</code>OR<br />
<code> [expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF</code><br />
|If the top stack value is FALSE, statement 1 is executed.<br />
If the top stack value is TRUE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_VERIF '''DISABLED'''<br />
|101<br />
|0x65<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_VERNOTIF '''DISABLED'''<br />
|102<br />
|0x66<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<code> [expression] IF<br />
[statement 1]<br />
ELSE<br />
[statement 2]<br />
ENDIF </code><br />
|If the preceding IF or NOTIF check was not valid then statement 2 is executed. |-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|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'''.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / ''fail''<br />
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.<br />
|-<br />
|[[OP_RETURN]]<br />
|106<br />
|0x6a<br />
|Nothing<br />
|''Ends script with top value on stack as final result''<br />
| 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.<br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Counts the number of stack items onto the stack and places the value on the top<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|}<br />
<br />
===Data Manipulation===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|Concatenates two strings.<br />
|-<br />
|OP_SPLIT<br />
|127<br />
|0x7f<br />
|x n<br />
|x1 x2<br />
|Splits byte sequence x at position n.<br />
|-<br />
|OP_NUM2BIN<br />
|128<br />
|0x80<br />
|a b<br />
| out<br />
|Converts numeric value a into byte sequence of length b.<br />
|-<br />
|OP_BIN2NUM<br />
|129<br />
|0x81<br />
| x<br />
| out<br />
|Converts byte sequence x into a numeric value.<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Pushes the string length of the top element of the stack (without popping it).<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|Flips all of the bits in the input.<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|Boolean ''and'' between each bit in the inputs.<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|Boolean ''or'' between each bit in the inputs.<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|Boolean ''exclusive or'' between each bit in the inputs.<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|Nothing / ''fail''<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
BitcoinScript supports arithmetic on bignum values<br />
A bignum is a byte sequence that represents a numeric value. The length of the byte sequence must be less than or equal to 750,000 bytes. Byte sequences larger than 750,000 bytes are valid in Bitcoin however current rules dictate that they are not recognised as a valid numeric value.<br />
<br />
Note that while some operations require parameters to be valid numeric values, they may produce byte sequences which are not valid numeric values (for example, OP_MUL may produce a byte sequence which is too large to validly represent a numeric value).<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL '''DISABLED'''<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|The input is multiplied by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_2DIV '''DISABLED'''<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|The input is divided by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|a is multiplied by b.<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|a is divided by b.<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|Returns the remainder after dividing a by b.<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|Logical left shift b bits. Sign data is discarded<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|Logical right shift b bits. Sign data is discarded<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|Nothing / ''fail''<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Cryptography ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|[[OP_CODESEPARATOR]]<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|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.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|Nothing / ''fail''<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|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, an extra unused value (x) is removed from the stack. Script spenders must account for this by adding a junk value (typically zero) to the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|Nothing / ''fail''<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
=== Used NOP opcode identifiers ===<br />
In Bitcoin's history, new opcodes were added that used reserved NO_OP opcode identifiers. These opcodes have been reverted to the original OP_NOP functionality.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word <br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP2<br />
<br />
(previously OP_CHECKLOCKTIMEVERIFY)<br />
|177<br />
|0xb1<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|-<br />
|OP_NOP3<br />
<br />
(previously OP_CHECKSEQUENCEVERIFY)<br />
|178<br />
|0xb2<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1, OP_NOP4-OP_NOP10<br />
|176, 179-185<br />
|0xb0, 0xb3-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
==Examples==<br />
<br />
For examples of common Bitcoin transaction scripts please see [[Bitcoin Transactions]]<br />
<br />
==Attribution==<br />
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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Opcodes_used_in_Bitcoin_Script&diff=3073Opcodes used in Bitcoin Script2022-10-07T07:36:39Z<p>Brendan: </p>
<hr />
<div>This is a list of all Script words, also known as opcodes, commands, or functions.<br />
<br />
OP_NOP1-OP_NOP10 were originally set aside to be used when HASH and other security functions become insecure due to improvements in computing.<br />
<br />
False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|[[Pushdata Opcodes|Pushdata Bytelength]]<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA1]]<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA2]]<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|[[Pushdata Opcodes|OP_PUSHDATA4]]<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack in little endian order.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_VER '''DISABLED'''<br />
|98<br />
|0x62<br />
|Nothing<br />
|Protocol version<br />
|Puts the version of the protocol under which this transaction will be evaluated onto the stack.</br><br />
(This opcode is scheduled to be re-enabled in the Chronicle update)</br><br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<code> <expression> IF<br />
[statement 1><br />
ENDIF</code><br />
OR<br />
<code> <expression> IF<br />
[statement 1><br />
ELSE<br />
[statement 2]<br />
ENDIF</code><br />
|If the top stack value is TRUE, statement 1 is executed.<br />
If the top stack value is FALSE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<code><expression> NOTIF<br />
[statement 1]<br />
ENDIF</code><br />
OR<br />
<code> <expression> IF<br />
[statement 1><br />
ELSE<br />
[statement 2]<br />
ENDIF</code><br />
|If the top stack value is FALSE, statement 1 is executed.<br />
If the top stack value is TRUE and ELSE is used, statement 2 is executed. If ELSE is NOT used, the script jumps to ENDIF.</br><br />
The top stack value is removed.</br><br />
|-<br />
|OP_VERIF '''DISABLED'''<br />
|101<br />
|0x65<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_VERNOTIF '''DISABLED'''<br />
|102<br />
|0x66<br />
|colspan="2"| '''DISABLED'''<br />
| '''DISABLED'''<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statement 1] [else [statement 2]]* endif<br />
|If the preceding IF or NOTIF check was not valid then statement 2 is executed. |-<br />
|OP_ENDIF<br />
|104<br />
|0x68<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|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'''.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / ''fail''<br />
|'''Marks transaction as invalid''' if top stack value is not true. The top stack value is removed.<br />
|-<br />
|[[OP_RETURN]]<br />
|106<br />
|0x6a<br />
|Nothing<br />
|''Ends script with top value on stack as final result''<br />
| 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.<br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Counts the number of stack items onto the stack and places the value on the top<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|}<br />
<br />
===Data Manipulation===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|Concatenates two strings.<br />
|-<br />
|OP_SPLIT<br />
|127<br />
|0x7f<br />
|x n<br />
|x1 x2<br />
|Splits byte sequence x at position n.<br />
|-<br />
|OP_NUM2BIN<br />
|128<br />
|0x80<br />
|a b<br />
| out<br />
|Converts numeric value a into byte sequence of length b.<br />
|-<br />
|OP_BIN2NUM<br />
|129<br />
|0x81<br />
| x<br />
| out<br />
|Converts byte sequence x into a numeric value.<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Pushes the string length of the top element of the stack (without popping it).<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|Flips all of the bits in the input.<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|Boolean ''and'' between each bit in the inputs.<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|Boolean ''or'' between each bit in the inputs.<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|Boolean ''exclusive or'' between each bit in the inputs.<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|Nothing / ''fail''<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
BitcoinScript supports arithmetic on bignum values<br />
A bignum is a byte sequence that represents a numeric value. The length of the byte sequence must be less than or equal to 750,000 bytes. Byte sequences larger than 750,000 bytes are valid in Bitcoin however current rules dictate that they are not recognised as a valid numeric value.<br />
<br />
Note that while some operations require parameters to be valid numeric values, they may produce byte sequences which are not valid numeric values (for example, OP_MUL may produce a byte sequence which is too large to validly represent a numeric value).<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL '''DISABLED'''<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|The input is multiplied by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_2DIV '''DISABLED'''<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|The input is divided by 2. (This opcode is scheduled to be re-enabled in the Chronicle update)<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|a is multiplied by b.<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|a is divided by b.<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|Returns the remainder after dividing a by b.<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|Logical left shift b bits. Sign data is discarded<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|Logical right shift b bits. Sign data is discarded<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|Nothing / ''fail''<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Cryptography ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|[[OP_CODESEPARATOR]]<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|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.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|Nothing / ''fail''<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|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, an extra unused value (x) is removed from the stack. Script spenders must account for this by adding a junk value (typically zero) to the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|Nothing / ''fail''<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
=== Used NOP opcode identifiers ===<br />
In Bitcoin's history, new opcodes were added that used reserved NO_OP opcode identifiers. These opcodes have been reverted to the original OP_NOP functionality.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word <br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP2<br />
<br />
(previously OP_CHECKLOCKTIMEVERIFY)<br />
|177<br />
|0xb1<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|-<br />
|OP_NOP3<br />
<br />
(previously OP_CHECKSEQUENCEVERIFY)<br />
|178<br />
|0xb2<br />
|Nothing<br />
<br />
(Previously: x)<br />
|Nothing<br />
<br />
(Previously: x or fail)<br />
|NO OPERATION<br />
<br />
''Evaluation process for UTXOs that pre-date genesis: Mark 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]. ''<br />
|}<br />
<br />
===Pseudo-words===<br />
These words are used internally for assisting with transaction matching. They are invalid if used in actual scripts.<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Description<br />
|-<br />
|OP_PUBKEYHASH<br />
|253<br />
|0xfd<br />
|Represents a public key hashed with OP_HASH160.<br />
|-<br />
|OP_PUBKEY<br />
|254<br />
|0xfe<br />
|Represents a public key compatible with OP_CHECKSIG.<br />
|-<br />
|OP_INVALIDOPCODE<br />
|255<br />
|0xff<br />
|Matches any opcode that is not yet assigned.<br />
|}<br />
<br />
=== Reserved words ===<br />
Any opcode not assigned is also reserved. Using an unassigned opcode makes the transaction '''invalid'''.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!When used...<br />
|-<br />
|OP_RESERVED<br />
|80<br />
|0x50<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED1<br />
|137<br />
|0x89<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_RESERVED2<br />
|138<br />
|0x8a<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_NOP1, OP_NOP4-OP_NOP10<br />
|176, 179-185<br />
|0xb0, 0xb3-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
==Examples==<br />
<br />
For examples of common Bitcoin transaction scripts please see [[Bitcoin Transactions]]<br />
<br />
==Attribution==<br />
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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Simplified_Payment_Verification&diff=3072Simplified Payment Verification2022-08-14T01:01:42Z<p>Brendan: </p>
<hr />
<div>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 [[Blockchain]], 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.<br />
<br />
SPV allows users to securely transact with each other, peer-to-peer, while nodes act to form the settlement layer.<br />
<br />
===Advantages===<br />
The advantages of using SPV are clear in terms of the volume of data required:<br />
<br />
* 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).<br />
<br />
* contrast this with the '''hundreds of gigabytes''' which would be required to store the entire chain, if SPV were not being used.<br />
<br />
* The size of the data required for the '''[[merkle path]]s''' is of maximum <math>64log_{2}{n}</math> bytes, where <math>n</math> is the total number of transaction in one block. <br />
<br />
As explained in Section 8 of the [[Bitcoin whitepaper]]:<br />
{{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 ... }}<br />
<br />
And in Section 7:<br />
{{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 ..."''}} <br />
<br />
===Approach===<br />
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 network 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 [[confirmation|confirmed]] at least 6 times whatever the transaction type, amount or situation.<br />
<br />
The better approach is that transactions between SPV clients are negotiated peer-to-peer and settled on the ledger 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.<br />
<br />
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 ledger or even the [[UTXO]] set 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.<br />
<br />
===Merkle Trees, Merkle Roots, Merkle Paths and Merkle Proofs===<br />
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.<br />
<br />
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 transactions in the block.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* To '''create''' a Merkle proof, a user (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).<br />
<br />
* To '''validate''' a proof, a user (or their wallet) only needs the chain of block headers (as opposed to the whole blocks themselves). I.e. they need their own copy of the [[block header]] of each block, 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 was time stamped in a specific block, without examining every transaction in that block.<br />
<br />
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:<br />
<br />
[[File: Merkle_tree2.png|frameless|1000px|alt=Three transactions and the Merkle paths which can be used to relate them to blocks]]<br />
<br />
===SPV Wallet===<br />
An SPV wallet is a lightweight wallet that uses the mechanism of SPV to construct Bitcoin transactions and payments. <br />
<br />
To spend a UTXO, a user of a SPV wallet will pass on the following information to the receiver:<br />
# <math>Transaction_0</math> - the transaction that contains the UTXO as an output,<br />
# The Merkle path of <math>Transaction_0</math><br />
# The block header that contains the Merkle root derived from the Merkle path (or its identifier, e.g., block height)<br />
# <math>Transaction_1</math> - the transaction that spends the UTXO<br />
<br />
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.<br />
<br />
=== Offline Payment ===<br />
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>.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=OP_PUSH_TX&diff=2782OP PUSH TX2022-04-04T08:05:49Z<p>Brendan: </p>
<hr />
<div>OP_PUSH_TX is a catch-all name for techniques that use [[ECDSA]] signature messages to access and enforce transactional states and other conditions in [[Script|Bitcoin script]]. The technique requires the user or process that is using the UTXO to push the transaction pre-image message that is used to generate the signature onto the stack as part of the input scriptSig.<br />
<br />
This message can be pushed as a single contiguous blob, as multiple separate elements, or as a partial set, with the remaining elements of the message set via the output's scriptPubKey.<br />
<br />
The technique allows the process to enforce several elements of the transaction including (but not limited to):<br />
# The number of inputs in the transaction<br />
# The nSequence values of those inputs<br />
# The value of the input being spent<br />
# The value and script of any outputs being generated<br />
# The nLocktime condition set for the transaction<br />
<br />
In addition, the technique allows users to enforce the script into which the tokens the UTXO being spent will go, which is a crucial step in the creation of Turing complete machines. This is achieved by taking the current script (part of the message) and using it to build an image of the next script in the chain before re-inserting it into the message hash and performing an EC signature in script.<br />
When the signature is tested using OP_CHECKSIG or any of its variants, the interpreters in the consensus layer will validate that the message and its conditions are a true representation of the transaction being processed, enabling the enforcement of next state conditions at the consensus layer.<br />
<br />
A significant shortcut has been developed that generates a signature using the keypair that corresponds to a private key of 1. In this situation, the signature is simply the hashed message with some simple byte-wise transformations performed.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=OP_PUSH_TX&diff=2781OP PUSH TX2022-04-01T06:31:45Z<p>Brendan: </p>
<hr />
<div>OP_PUSH_TX is a catch-all name for techniques that use [[ECDSA]] signature messages to access and enforce transactional states and other conditions in [[Script|Bitcoin script]]. The technique requires the user or process that is using the UTXO to push the transaction pre-image message that is used to generate the signature onto the stack as part of the input scriptSig.<br />
<br />
This message can be pushed as a single contiguous blob, as multiple separate elements, or as a partial set, with the remaining elements of the message set via the output's scriptPubKey.<br />
<br />
The technique allows the process to check several elements of the transaction including (but not limited to):<br />
# The parent TXID and index<br />
# The number of inputs in the transaction<br />
# The nSequence values of those inputs<br />
# The value of the input being spent<br />
# The value and script of any outputs being generated<br />
# The nLocktime condition set for the transaction<br />
<br />
In addition, the technique allows users to enforce the script into which the tokens the UTXO being spent will go, which is a crucial step in the creation of Turing complete machines. This is achieved by taking the current script (part of the message) and using it to build an image of the next script in the chain before re-inserting it into the message hash and performing an EC signature in script.<br />
When the signature is tested using OP_CHECKSIG or any of its variants, the interpreters in the consensus layer will validate that the message and its conditions are a true representation of the transaction being processed, enabling the enforcement of next state conditions at the consensus layer.<br />
<br />
A significant shortcut has been developed that generates a signature using the keypair that corresponds to a private key of 1. In this situation, the signature is simply the hashed message with some simple byte-wise transformations performed.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Main_Page&diff=2780Main Page2022-04-01T01:19:00Z<p>Brendan: </p>
<hr />
<div>Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality.<br />
<br />
===Bitcoin===<br />
<br />
'''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 [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper] in October 2008, and the source code was [https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html released] in January 2009. The Bitcoin ledger and [[Blockchain]] were established with the generation of the [[Genesis block]] on the 3rd of January 2009 and the mining of Block 1 six days later on the 9th of January 2009.<br />
<br />
Bitcoin allows electronic payments to be sent directly from one party to another, without requiring a central institution or server to process transactions and/or store funds. <br />
<br />
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.<br />
<br />
===Applications===<br />
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. But developments such as [[Paymail]] and [[Simplified Payment Verification]] are changing the landscape and making it much easier for users to connect.<br />
<br />
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.<br />
<br />
Applications which make use of the immutable nature of the [[Blockchain|Bitcoin Ledger]] to store and retrieve data are emerging at an increasing rate. [[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.<br />
<br />
===Network===<br />
[[The Bitcoin Network]] is the network that all peers use to access the ledger. The network forms spontaneously over time as more peers access and use the system. There is no central governance that determines how peers on the network must connect, but the incentive structure that Bitcoin employs to bring enterprise miners into the system results in the formation of a small world network which is simple and resilient. <br />
<br />
Once the final restrictions on the [[protocol]] are removed in the [[Chronicle Update]] (expected early-mid 2021) network users will be able to create partitioned zones which employ specific rulesets particular to their requirements. This will be enabled by creating transactions that use [[OP_VER]] to give particular subsets of nodes specialised instructions, and will create the effect of layered network partitions over the core system which are referred to as [[Bitcoin Layered Networks]].<br />
<br />
===The Ledger===<br />
The Bitcoin ledger is a record of all valid transactions that have ever been transmitted to 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.<br />
<br />
<div class="img-responsive"><br />
[[File:Chain_of_Signatures.png|centre|alt=Electronic coins are defined as a chain of digital signatures]]<br />
</div><br />
<br />
Valid transactions that are broadcast on [[The Bitcoin Network]] are committed to the ledger by miners in [[Block|Blocks]]. A block consists of a [[Block hashing algorithm#Block_Header|header]] which contains a timestamp, a reference to the block it builds on, a valid [[Proof of Work]] and the double [[SHA-256]] hash of the root of a [[wikipedia:Merkle Tree|Merkle tree]] generated with a list of transactions, and the list of transactions. Most nodes use compact block propagation techniques which compress the list of transactions to a much smaller size rather than broadcasting the full block. Receiving Nodes must decompress the block using a list of validated transactions that they have also compacted.<br />
<br />
Blocks form a second layer DAG called the [[Blockchain]] 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 become 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]].<br />
<br />
<div class="img-responsive"><br />
[[File:Block_Chain.png|centre|alt=A chain of blocks]]<br />
</div><br />
<br />
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.<br />
<br />
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.<br />
<br />
<div class="img-responsive"><br />
[[File:Simplified_Payment_Verification.png|centre|alt=Simplified payment verification]]<br />
</div><br />
<br />
Users can exchange unfinalised transactions without sending them to the network to be mined creating what are called [[Payment Channels]].<br />
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.<br />
<br />
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 template, it is considered invalid. Transactions can be invalid for a variety of reasons such as being submitted with an invalid scriptSig, not adhering to [[Protocol|network or miner rules]], or not paying an adequate fee.<br />
<br />
===Transactions===<br />
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 [[VOUT|output]] via the creation of arbitrary spending conditions defined by scripts.<br />
<br />
Each transaction uses bitcoins stored in '[[UTXO|unspent transaction outputs]]' as the transaction inputs. The transaction process aggregates the [[satoshis]] held in each input and spends them into a new set of unspent transaction outputs. When UTXOs are spent in a transaction they are consumed.<br />
<br />
<div class="img-responsive"><br />
[[File:Transaction.png|centre|alt=Transaction inputs and outputs]]<br />
</div><br />
<br />
The Bitcoin scripting language is [[wikipedia:Turing_completeness|Turing complete]], and can be used to create [[wikipedia:Turing_machine|Turing machines]] that use the Bitcoin ledger as a tape, writing to and reading from the transaction graph as needed.<br />
<br />
The scripting language 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]].<br />
<br />
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 first transaction in the block's [[wikipedia:Merkle tree|Merkle tree]].<br />
<br />
===Nodes and Mining===<br />
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 enforce 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.<br />
<br />
<div class="img-responsive"><br />
[[File:Proof_of_Work.png|centre|alt=A chain of hash based proof of work]]<br />
</div><br />
<br />
During the [[mining]] process, a node gathers transactions from the network on a [[First seen rule|first seen]] basis 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. Hash operators continuously request new block templates through the [[Getminingcandidate]] interface to ensure they are getting up-to-date block data to hash against. 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.<br />
<br />
[[File:Merkle tree.png|centre|alt=The structure of a Merkle Tree]]<br />
<br />
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 each miner is connected to most of the other miners. Miners gather transactions from users who connect in a layered network over the nodes at the core forming something that closely resembles a [[Mandala Network]]. Peers operating in these shell-like layers use [[Simplified Payment Verification]] to form a much less densely packed structure where information is exchanged in [[Payment Channels]].<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Unit of account===<br />
[[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.<br />
<br />
Satoshis are distributed by miners to themselves as a [[Block subsidy|subsidy payment]] during the network establishment phase. As the network matures, 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.<br />
<br />
===Network rules===<br />
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.<br />
<br />
There are no limits in the [[Protocol|Bitcoin protocol]]. Any limits imposed 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.<br />
<br />
===History===<br />
[[Bitcoin until today|Bitcoin has a rich history]].<br />
<br />
===Tools and Building on Bitcoin===<br />
Bitcoin has a rich and diverse [[Building on Bitcoin|set of tools]] which are being added to all the time.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=OP_PUSH_TX&diff=2779OP PUSH TX2022-04-01T01:15:57Z<p>Brendan: </p>
<hr />
<div>OP_PUSH_TX is a catch-all name for techniques that use [[ECDSA]] signature messages to enforce stateful conditions in [[Script|Bitcoin script]]. The technique requires the user or process that is using the UTXO to push the message used to generate the signature onto the stack as part of the input scriptSig.<br />
<br />
This message can be pushed as a single contiguous blob, as multiple separate elements, or as a partial set, with the remaining elements of the message set via the output's scriptPubKey.<br />
<br />
The technique allows the process to check several elements of the transaction including (but not limited to):<br />
# The parent TXID and index<br />
# The number of inputs in the transaction<br />
# The nSequence values of those inputs<br />
# The value of the input being spent<br />
# The value and script of any outputs being generated<br />
# The nLocktime condition set for the transaction<br />
<br />
In addition, the technique allows users to enforce the script into which the tokens the UTXO being spent will go, which is a crucial step in the creation of Turing complete machines. This is achieved by taking the current script (part of the message) and using it to build an image of the next script in the chain before re-inserting it into the message hash and performing an EC signature in script.<br />
When the signature is tested using OP_CHECKSIG or any of its variants, the interpreters in the consensus layer will validate that the message and its conditions are a true representation of the transaction being processed, enabling the enforcement of next state conditions at the consensus layer.<br />
<br />
A significant shortcut has been developed that generates a signature using the keypair that corresponds to a private key of 1. In this situation, the signature is simply the hashed message with some simple byte-wise transformations performed.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=OP_PUSH_TX&diff=2778OP PUSH TX2022-04-01T01:10:44Z<p>Brendan: Created page with "OP_PUSH_TX is a catch-all name for techniques that use ECDSA signature messages to enforce stateful conditions in Bitcoin script. The technique requires the use..."</p>
<hr />
<div>OP_PUSH_TX is a catch-all name for techniques that use [[ECDSA]] signature messages to enforce stateful conditions in [[Script|Bitcoin script]]. The technique requires the user or process that is using the UTXO to push the message used to generate the signature onto the stack as part of the input scriptSig.<br />
<br />
This message can be pushed as a single contiguous blob, as multiple separate elements, or as a partial set, with the remaining elements of the message set via the output's scriptPubKey.<br />
<br />
The technique allows the process to check several elements of the transaction including (but not limited to):<br />
# The parent TXID and index<br />
# The number of inputs in the transaction<br />
# The nSequence values of those inputs<br />
# The value of the input being spent<br />
# The value and script of any outputs being generated<br />
# The nLocktime condition set for the transaction<br />
<br />
In addition, the technique allows users to enforce the script into which the tokens the UTXO being spent will go, which is a crucial step in the creation of Turing complete machines. This is achieved by taking the current script (part of the message) and using it to build an image of the next script in the chain before re-inserting it into the message hash and performing an EC signature in script.<br />
<br />
A significant shortcut has been developed that generates a signature using the keypair that corresponds to a private key of 1. In this situation, the signature is simply the hashed message with some simple byte-wise transformations performed.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Script&diff=2777Script2022-04-01T00:59:25Z<p>Brendan: </p>
<hr />
<div>Bitcoin uses a scripting system for [[Bitcoin_Transactions|transactions]]. Similar to [[Wikipedia:FORTH|Forth]], '''Script''' is simple, stack-based, and processed from left to right as a series of sequential instructions. Data is pushed onto the stack and [[opcodes]] are used to perform operations on the items on the stack.<br />
<br />
Script is [https://en.wikipedia.org/wiki/Turing_completeness Turing-complete] despite having no jump instructions. Finite state machines can be built which hold their current state in one or more [[UTXO|UTXOs]]. Among other methods, these machines can receive information from oracles, generate deterministic pseudo random values or look back to previous transactions on the ledger for the data needed to determine the next-state.<br />
A loop is formed by checking these input conditions and asserting a particular output state for the next UTXO holding the Turing machine. In this way, the Turing machine is held in a continually operating state until such a time as a transaction is created that determines that the process can halt.<br />
One such technique called [[OP_PUSH_TX|'OP_PUSH_TX']] uses the [[ECDSA]] message pre-image to enforce conditions for the next stages of each computation.<br />
Techniques that are considered Turing complete can be described as using the Bitcoin ledger as an unbounded ticker tape to store computational results and future instructions.<br />
<br />
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 requires the spending party to provide two things:<br />
# a public key that, when hashed, yields the destination [[address]] embedded in the script, and<br />
# a signature to prove ownership of the private key corresponding to the public key just provided.<br />
<br />
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 a file and 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.<br />
<br />
De facto, Bitcoin script is defined by the code run by the nodes building the [[Blockchain]]. Nodes collectively agree on the opcode set that is available for use, and how to process them. 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 removal of opcodes from the set. <br />
<br />
The nodes checking Bitcoin script, process transaction inputs in a script evaluation engine. The engine is comprised of two stacks which are:<br />
* The main stack<br />
* The alt stack<br />
<br />
In addition, the system also uses a subscript management system to track the depth of nested [[Scripts with Flow Control (Conditional Clauses)|If-Loops]]<br />
<br />
The main and alt stacks hold byte vectors which can be used by Bitcoin opcodes to process script outcomes. <br />
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.<br />
Thus 0x81 represents -1.<br />
0x80 is another representation of zero (so called negative 0).<br />
Positive 0 can be represented by a null-length vector or a string of hexadecimal zeros of any length.<br />
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.<br />
<br />
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 the amount of data being pushed onto the stack is only limited to the economic limits imposed by the miners. As services such as [[mAPI]] are rolled out further, users will be presented with further choice in how they use the network.<br />
<br />
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. <br />
<br />
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, nodes 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. Over time, network node operators will collectively agree on appropriate data limits.<br />
<br />
==More on Bitcoin Script==<br />
#[[Opcodes used in Bitcoin Script]]<br />
#[[Number Encoding in Bitcoin Script]]<br />
#[[Scripts with Flow Control (Conditional Clauses)]]<br />
#[[OP_CODESEPARATOR]]<br />
#[[OP_RETURN]]<br />
#[[OP_VER]]<br />
#[[Complex Script Examples]]<br />
<br />
==Attribution==<br />
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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Main_Page&diff=2776Main Page2022-04-01T00:35:47Z<p>Brendan: </p>
<hr />
<div>Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality.<br />
<br />
===Bitcoin===<br />
<br />
'''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 [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper] in October 2008, and the source code was [https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html released] in January 2009. The Bitcoin ledger and [[Blockchain]] were established with the generation of the [[Genesis block]] on the 3rd of January 2009 and the mining of Block 1 six days later on the 9th of January 2009.<br />
<br />
Bitcoin allows electronic payments to be sent directly from one party to another, without requiring a central institution or server to process transactions and/or store funds. <br />
<br />
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.<br />
<br />
===Applications===<br />
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. But developments such as [[Paymail]] and [[Simplified Payment Verification]] are changing the landscape and making it much easier for users to connect.<br />
<br />
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.<br />
<br />
Applications which make use of the immutable nature of the [[Blockchain|Bitcoin Ledger]] to store and retrieve data are emerging at an increasing rate. [[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.<br />
<br />
===Network===<br />
[[The Bitcoin Network]] is the network that all peers use to access the ledger. The network forms spontaneously over time as more peers access and use the system. There is no central governance that determines how peers on the network must connect, but the incentive structure that Bitcoin employs to bring enterprise miners into the system results in the formation of a small world network which is simple and resilient. <br />
<br />
Once the final restrictions on the [[protocol]] are removed in the [[Chronicle Update]] (expected early-mid 2021) network users will be able to create partitioned zones which employ specific rulesets particular to their requirements. This will be enabled by creating transactions that use [[OP_VER]] to give particular subsets of nodes specialised instructions, and will create the effect of layered network partitions over the core system which are referred to as [[Bitcoin Layered Networks]].<br />
<br />
===The Ledger===<br />
The Bitcoin ledger is a record of all valid transactions that have ever been transmitted to 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.<br />
<br />
<div class="img-responsive"><br />
[[File:Chain_of_Signatures.png|centre|alt=Electronic coins are defined as a chain of digital signatures]]<br />
</div><br />
<br />
Valid transactions that are broadcast on [[The Bitcoin Network]] are committed to the ledger by miners in [[Block|Blocks]]. A block consists of a [[Block hashing algorithm#Block_Header|header]] which contains a timestamp, a reference to the block it builds on, a valid [[Proof of Work]] and the double [[SHA-256]] hash of the root of a [[wikipedia:Merkle Tree|Merkle tree]] generated with a list of transactions, and the list of transactions. Most nodes use compact block propagation techniques which compress the list of transactions to a much smaller size rather than broadcasting the full block. Receiving Nodes must decompress the block using a list of validated transactions that they have also compacted.<br />
<br />
Blocks form a second layer DAG called the [[Blockchain]] 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 become 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]].<br />
<br />
<div class="img-responsive"><br />
[[File:Block_Chain.png|centre|alt=A chain of blocks]]<br />
</div><br />
<br />
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.<br />
<br />
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.<br />
<br />
<div class="img-responsive"><br />
[[File:Simplified_Payment_Verification.png|centre|alt=Simplified payment verification]]<br />
</div><br />
<br />
Users can exchange unfinalised transactions without sending them to the network to be mined creating what are called [[Payment Channels]].<br />
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.<br />
<br />
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 template, it is considered invalid. Transactions can be invalid for a variety of reasons such as being submitted with an invalid scriptSig, not adhering to [[Protocol|network or miner rules]], or not paying an adequate fee.<br />
<br />
===Transactions===<br />
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 [[VOUT|output]] via the creation of arbitrary spending conditions defined by scripts.<br />
<br />
Each transaction uses bitcoins stored in '[[UTXO|unspent transaction outputs]]' as the transaction inputs. The transaction process aggregates the [[satoshis]] held in each input and spends them into a new set of unspent transaction outputs. When UTXOs are spent in a transaction they are consumed.<br />
<br />
<div class="img-responsive"><br />
[[File:Transaction.png|centre|alt=Transaction inputs and outputs]]<br />
</div><br />
<br />
The Bitcoin scripting language is [[wikipedia:Turing_completeness|Turing complete]], and can be used to create [[wikipedia:Turing_machine|Turing machines]] that use the Bitcoin ledger as a tape, reading to and writing from the transaction graph as needed.<br />
<br />
The scripting language 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]].<br />
<br />
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 first transaction in the block's [[wikipedia:Merkle tree|Merkle tree]].<br />
<br />
===Nodes and Mining===<br />
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 enforce 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.<br />
<br />
<div class="img-responsive"><br />
[[File:Proof_of_Work.png|centre|alt=A chain of hash based proof of work]]<br />
</div><br />
<br />
During the [[mining]] process, a node gathers transactions from the network on a [[First seen rule|first seen]] basis 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. Hash operators continuously request new block templates through the [[Getminingcandidate]] interface to ensure they are getting up-to-date block data to hash against. 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.<br />
<br />
[[File:Merkle tree.png|centre|alt=The structure of a Merkle Tree]]<br />
<br />
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 each miner is connected to most of the other miners. Miners gather transactions from users who connect in a layered network over the nodes at the core forming something that closely resembles a [[Mandala Network]]. Peers operating in these shell-like layers use [[Simplified Payment Verification]] to form a much less densely packed structure where information is exchanged in [[Payment Channels]].<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Unit of account===<br />
[[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.<br />
<br />
Satoshis are distributed by miners to themselves as a [[Block subsidy|subsidy payment]] during the network establishment phase. As the network matures, 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.<br />
<br />
===Network rules===<br />
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.<br />
<br />
There are no limits in the [[Protocol|Bitcoin protocol]]. Any limits imposed 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.<br />
<br />
===History===<br />
[[Bitcoin until today|Bitcoin has a rich history]].<br />
<br />
===Tools and Building on Bitcoin===<br />
Bitcoin has a rich and diverse [[Building on Bitcoin|set of tools]] which are being added to all the time.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Elliptic_Curve_Digital_Signature_Algorithm&diff=2775Elliptic Curve Digital Signature Algorithm2022-03-15T07:00:49Z<p>Brendan: </p>
<hr />
<div>'''Elliptic Curve Digital Signature Algorithm''' or '''ECDSA''' is a cryptographic algorithm used by Bitcoin to ensure the effective and secure control of ownership of funds.<br />
<br />
A few concepts related to ECDSA:<br />
* [[Private Keys|private key]]: A secret number, known only to the person that generated it. A private key can be a randomly generated number but in 2019 most wallets use deterministic key schemes derived from [https://github.com/bitcoin/bips/tree/master/bip-0032 BIP 0032]. In Bitcoin, someone who can prove ownership of unspent outputs can use the private key to spend the funds. In Bitcoin, a private key is a single unsigned 256-bit integer (32 bytes). <br />
* public key: A coordinate that corresponds to a private key but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine by using ECDSA to validate that a signature was generated by the private key, that corresponds to the public key that has been proffered, without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called ''x''. Uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called ''x'' and ''y'' (2 * 32 bytes). The prefix of a compressed key allows for the ''y'' value to be derived from the ''x'' value.<br />
* [[Protocol#Signatures|signatures]]: A string of bytes proving that a private key was used to sign a message. A signature is mathematically generated from a [[SHA-256|hash]] of the message being signed and a private key. The signature itself is two numbers known as ''r'' and ''s'' and the message being signed is the Bitcoin transaction (minus the signature data). With the public key, a mathematical algorithm (signature verification) can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are usually 71, 72, or 73 bytes long, with probabilities approximately 25%, 50% and 25% respectively.<br />
<br />
In Bitcoin, elliptic curve signatures must sign a hash of a "transaction message" which can be reproduced easily by nodes validating the signature during the process of validating transactions.<br />
The message that is hashed for the signature contains the following elements concatenated into a single string:<br />
# <transaction version> (4 bytes)<br />
# Hash of Prevouts (concatenation of input source / sources) (32 byte null string if SIGHASH_ANYONECANPAY is used) (32 bytes)<br />
# Hash of Sequence (concatenation of input nSequence value / values) (defined by SIGHASH) (32 bytes)<br />
# Outpoint for input being spent (TXID / Vout) (32 bytes + 4 bytes)<br />
# Length of the locking script for input being spent ([[VarInt| VarInt format]], Transaction dependent, defined by OP_CODESEPARATOR)<br />
# Locking script for input being spent (Transaction dependent, defined by OP_CODESEPARATOR)<br />
# Value of input being spent (in satoshis) (8 bytes)<br />
# nSequence value for input being spent (4 bytes)<br />
# Hash of output / outputs being signed (defined by SIGHASH) (32 bytes)<br />
# Transaction nLocktime (4 bytes)<br />
# Sighash flag (4 bytes, XX000000 where XX is Sighash Flag)<br />
<br />
All signatures include [[SIGHASH flags]] which tell the transaction validator which parts of the message have been used in the construction of the message hash.<br />
<br />
==See also==<br />
* [[Secp256k1]]<br />
<br />
==External Links==<br />
* [https://en.wikipedia.org/wiki/Elliptic_Curve_DSA Elliptic Curve Digital Signature Algorithm - Wikipedia article]<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Elliptic_Curve_Digital_Signature_Algorithm&diff=2774Elliptic Curve Digital Signature Algorithm2022-03-15T07:00:27Z<p>Brendan: </p>
<hr />
<div>'''Elliptic Curve Digital Signature Algorithm''' or '''ECDSA''' is a cryptographic algorithm used by Bitcoin to ensure the effective and secure control of ownership of funds.<br />
<br />
A few concepts related to ECDSA:<br />
* [[Private Keys|private key]]: A secret number, known only to the person that generated it. A private key can be a randomly generated number but in 2019 most wallets use deterministic key schemes derived from [https://github.com/bitcoin/bips/tree/master/bip-0032 BIP 0032]. In Bitcoin, someone who can prove ownership of unspent outputs can use the private key to spend the funds. In Bitcoin, a private key is a single unsigned 256-bit integer (32 bytes). <br />
* public key: A coordinate that corresponds to a private key but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine by using ECDSA to validate that a signature was generated by the private key, that corresponds to the public key that has been proffered, without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called ''x''. Uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called ''x'' and ''y'' (2 * 32 bytes). The prefix of a compressed key allows for the ''y'' value to be derived from the ''x'' value.<br />
* [[Protocol#Signatures|signatures]]: A string of bytes proving that a private key was used to sign a message. A signature is mathematically generated from a [[SHA-256|hash]] of the message being signed and a private key. The signature itself is two numbers known as ''r'' and ''s'' and the message being signed is the Bitcoin transaction (minus the signature data). With the public key, a mathematical algorithm (signature verification) can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are usually 71, 72, or 73 bytes long, with probabilities approximately 25%, 50% and 25% respectively.<br />
<br />
In Bitcoin, elliptic curve signatures must sign a hash of a "transaction message" which can be reproduced easily by nodes validating the signature during the process of validating transactions.<br />
The message that is hashed for the signature contains the following elements concatenated into a single string:<br />
# <transaction version> (4 bytes)<br />
# Hash of Prevouts (concatenation of input source / sources) (32 byte null string if SIGHASH_ANYONECANPAY is used (32 bytes)<br />
# Hash of Sequence (concatenation of input nSequence value / values) (defined by SIGHASH) (32 bytes)<br />
# Outpoint for input being spent (TXID / Vout) (32 bytes + 4 bytes)<br />
# Length of the locking script for input being spent ([[VarInt| VarInt format]], Transaction dependent, defined by OP_CODESEPARATOR)<br />
# Locking script for input being spent (Transaction dependent, defined by OP_CODESEPARATOR)<br />
# Value of input being spent (in satoshis) (8 bytes)<br />
# nSequence value for input being spent (4 bytes)<br />
# Hash of output / outputs being signed (defined by SIGHASH) (32 bytes)<br />
# Transaction nLocktime (4 bytes)<br />
# Sighash flag (4 bytes, XX000000 where XX is Sighash Flag)<br />
<br />
All signatures include [[SIGHASH flags]] which tell the transaction validator which parts of the message have been used in the construction of the message hash.<br />
<br />
==See also==<br />
* [[Secp256k1]]<br />
<br />
==External Links==<br />
* [https://en.wikipedia.org/wiki/Elliptic_Curve_DSA Elliptic Curve Digital Signature Algorithm - Wikipedia article]<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Elliptic_Curve_Digital_Signature_Algorithm&diff=2773Elliptic Curve Digital Signature Algorithm2022-03-15T06:44:40Z<p>Brendan: </p>
<hr />
<div>'''Elliptic Curve Digital Signature Algorithm''' or '''ECDSA''' is a cryptographic algorithm used by Bitcoin to ensure the effective and secure control of ownership of funds.<br />
<br />
A few concepts related to ECDSA:<br />
* [[Private Keys|private key]]: A secret number, known only to the person that generated it. A private key can be a randomly generated number but in 2019 most wallets use deterministic key schemes derived from [https://github.com/bitcoin/bips/tree/master/bip-0032 BIP 0032]. In Bitcoin, someone who can prove ownership of unspent outputs can use the private key to spend the funds. In Bitcoin, a private key is a single unsigned 256-bit integer (32 bytes). <br />
* public key: A coordinate that corresponds to a private key but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine by using ECDSA to validate that a signature was generated by the private key, that corresponds to the public key that has been proffered, without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called ''x''. Uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called ''x'' and ''y'' (2 * 32 bytes). The prefix of a compressed key allows for the ''y'' value to be derived from the ''x'' value.<br />
* [[Protocol#Signatures|signatures]]: A string of bytes proving that a private key was used to sign a message. A signature is mathematically generated from a [[SHA-256|hash]] of the message being signed and a private key. The signature itself is two numbers known as ''r'' and ''s'' and the message being signed is the Bitcoin transaction (minus the signature data). With the public key, a mathematical algorithm (signature verification) can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are usually 71, 72, or 73 bytes long, with probabilities approximately 25%, 50% and 25% respectively.<br />
<br />
In Bitcoin, elliptic curve signatures must sign a hash of a "transaction message" which can be reproduced easily by nodes validating the signature during the process of validating transactions.<br />
The message that is hashed for the signature contains the following elements concatenated into a single string:<br />
# <transaction version> (4 bytes)<br />
# Hash of Prevouts (concatenation of input source / sources) (defined by SIGHASH) (32 bytes)<br />
# Hash of Sequence (concatenation of input nSequence value / values) (defined by SIGHASH) (32 bytes)<br />
# Outpoint for input being spent (TXID / Vout) (32 bytes + 4 bytes)<br />
# Length of the locking script for input being spent ([[VarInt| VarInt format]], Transaction dependent, defined by OP_CODESEPARATOR)<br />
# Locking script for input being spent (Transaction dependent, defined by OP_CODESEPARATOR)<br />
# Value of input being spent (in satoshis) (8 bytes)<br />
# nSequence value for input being spent (4 bytes)<br />
# Hash of output / outputs being signed (defined by SIGHASH) (32 bytes)<br />
# Transaction nLocktime (4 bytes)<br />
# Sighash flag (4 bytes, XX000000 where XX is Sighash Flag)<br />
<br />
All signatures include [[SIGHASH flags]] which tell the transaction validator which parts of the message have been used in the construction of the message hash.<br />
<br />
==See also==<br />
* [[Secp256k1]]<br />
<br />
==External Links==<br />
* [https://en.wikipedia.org/wiki/Elliptic_Curve_DSA Elliptic Curve Digital Signature Algorithm - Wikipedia article]<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Elliptic_Curve_Digital_Signature_Algorithm&diff=2772Elliptic Curve Digital Signature Algorithm2022-03-15T06:44:18Z<p>Brendan: </p>
<hr />
<div>'''Elliptic Curve Digital Signature Algorithm''' or '''ECDSA''' is a cryptographic algorithm used by Bitcoin to ensure the effective and secure control of ownership of funds.<br />
<br />
A few concepts related to ECDSA:<br />
* [[Private Keys|private key]]: A secret number, known only to the person that generated it. A private key can be a randomly generated number but in 2019 most wallets use deterministic key schemes derived from [https://github.com/bitcoin/bips/tree/master/bip-0032 BIP 0032]. In Bitcoin, someone who can prove ownership of unspent outputs can use the private key to spend the funds. In Bitcoin, a private key is a single unsigned 256-bit integer (32 bytes). <br />
* public key: A coordinate that corresponds to a private key but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine by using ECDSA to validate that a signature was generated by the private key, that corresponds to the public key that has been proffered, without requiring the private key to be divulged. In Bitcoin, public keys are either compressed or uncompressed. Compressed public keys are 33 bytes, consisting of a prefix either 0x02 or 0x03, and a 256-bit integer called ''x''. Uncompressed keys are 65 bytes, consisting of constant prefix (0x04), followed by two 256-bit integers called ''x'' and ''y'' (2 * 32 bytes). The prefix of a compressed key allows for the ''y'' value to be derived from the ''x'' value.<br />
* [[Protocol#Signatures|signatures]]: A string of bytes proving that a private key was used to sign a message. A signature is mathematically generated from a [[SHA-256|hash]] of the message being signed and a private key. The signature itself is two numbers known as ''r'' and ''s'' and the message being signed is the Bitcoin transaction (minus the signature data). With the public key, a mathematical algorithm (signature verification) can be used on the signature to determine that it was originally produced from the hash and the private key, without needing to know the private key. Signatures are usually 71, 72, or 73 bytes long, with probabilities approximately 25%, 50% and 25% respectively.<br />
<br />
In Bitcoin, elliptic curve signatures must sign a hash of a "transaction message" which can be reproduced easily by nodes validating the signature during the process of validating transactions.<br />
The message that is hashed for the signature contains the following elements concatenated into a single string:<br />
# <transaction version> (4 bytes)<br />
# Hash of Prevouts (concatenation of input source / sources) (defined by SIGHASH) (32 bytes)<br />
# Hash of Sequence (concatenation of input nSequence value / values) (defined by SIGHASH) (32 bytes)<br />
# Outpoint for input being spent (TXID / Vout) (32 bytes + 4 bytes)<br />
# Length of the locking script for input being spent ([[VarInt format|Varint]], Transaction dependent, defined by OP_CODESEPARATOR)<br />
# Locking script for input being spent (Transaction dependent, defined by OP_CODESEPARATOR)<br />
# Value of input being spent (in satoshis) (8 bytes)<br />
# nSequence value for input being spent (4 bytes)<br />
# Hash of output / outputs being signed (defined by SIGHASH) (32 bytes)<br />
# Transaction nLocktime (4 bytes)<br />
# Sighash flag (4 bytes, XX000000 where XX is Sighash Flag)<br />
<br />
All signatures include [[SIGHASH flags]] which tell the transaction validator which parts of the message have been used in the construction of the message hash.<br />
<br />
==See also==<br />
* [[Secp256k1]]<br />
<br />
==External Links==<br />
* [https://en.wikipedia.org/wiki/Elliptic_Curve_DSA Elliptic Curve Digital Signature Algorithm - Wikipedia article]<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Main_Page&diff=2771Main Page2022-01-11T05:25:00Z<p>Brendan: /* Network */</p>
<hr />
<div>Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality.<br />
<br />
===Bitcoin===<br />
<br />
'''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 [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper] in October 2008, and the source code was [https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html released] in January 2009. The Bitcoin ledger and [[Blockchain]] were established with the generation of the [[Genesis block]] on the 3rd of January 2009 and the mining of Block 1 six days later on the 9th of January 2009.<br />
<br />
Bitcoin allows electronic payments to be sent directly from one party to another, without requiring a central institution or server to process transactions and/or store funds. <br />
<br />
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.<br />
<br />
===Applications===<br />
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. But developments such as [[Paymail]] and [[Simplified Payment Verification]] are changing the landscape and making it much easier for users to connect.<br />
<br />
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.<br />
<br />
Applications which make use of the immutable nature of the [[Blockchain|Bitcoin Ledger]] to store and retrieve data are emerging at an increasing rate. [[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.<br />
<br />
===Network===<br />
[[The Bitcoin Network]] is the network that all peers use to access the ledger. The network forms spontaneously over time as more peers access and use the system. There is no central governance that determines how peers on the network must connect, but the incentive structure that Bitcoin employs to bring enterprise miners into the system results in the formation of a small world network which is simple and resilient. <br />
<br />
Once the final restrictions on the [[protocol]] are removed in the [[Chronicle Update]] (expected early-mid 2021) network users will be able to create partitioned zones which employ specific rulesets particular to their requirements. This will be enabled by creating transactions that use [[OP_VER]] to give particular subsets of nodes specialised instructions, and will create the effect of layered network partitions over the core system which are referred to as [[Bitcoin Layered Networks]].<br />
<br />
===The Ledger===<br />
The Bitcoin ledger is a record of all valid transactions that have ever been transmitted to 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.<br />
<br />
<div class="img-responsive"><br />
[[File:Chain_of_Signatures.png|centre|alt=Electronic coins are defined as a chain of digital signatures]]<br />
</div><br />
<br />
Valid transactions that are broadcast on [[The Bitcoin Network]] are committed to the ledger by miners in [[Block|Blocks]]. A block consists of a [[Block hashing algorithm#Block_Header|header]] which contains a timestamp, a reference to the block it builds on, a valid [[Proof of Work]] and the double [[SHA-256]] hash of the root of a [[wikipedia:Merkle Tree|Merkle tree]] generated with a list of transactions, and the list of transactions. Most nodes use compact block propagation techniques which compress the list of transactions to a much smaller size rather than broadcasting the full block. Receiving Nodes must decompress the block using a list of validated transactions that they have also compacted.<br />
<br />
Blocks form a second layer DAG called the [[Blockchain]] 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 become 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]].<br />
<br />
<div class="img-responsive"><br />
[[File:Block_Chain.png|centre|alt=A chain of blocks]]<br />
</div><br />
<br />
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.<br />
<br />
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.<br />
<br />
<div class="img-responsive"><br />
[[File:Simplified_Payment_Verification.png|centre|alt=Simplified payment verification]]<br />
</div><br />
<br />
Users can exchange unfinalised transactions without sending them to the network to be mined creating what are called [[Payment Channels]].<br />
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.<br />
<br />
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 template, it is considered invalid. Transactions can be invalid for a variety of reasons such as being submitted with an invalid scriptSig, not adhering to [[Protocol|network or miner rules]], or not paying an adequate fee.<br />
<br />
===Transactions===<br />
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 [[VOUT|output]] via the creation of arbitrary spending conditions defined by scripts.<br />
<br />
Each transaction uses bitcoins stored in '[[UTXO|unspent transaction outputs]]' as the transaction inputs. The transaction process aggregates the [[satoshis]] held in each input and spends them into a new set of unspent transaction outputs. When UTXOs are spent in a transaction they are consumed.<br />
<br />
<div class="img-responsive"><br />
[[File:Transaction.png|centre|alt=Transaction inputs and outputs]]<br />
</div><br />
<br />
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.<br />
<br />
The scripting language 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]].<br />
<br />
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 first transaction in the block's [[wikipedia:Merkle tree|Merkle tree]].<br />
<br />
===Nodes and Mining===<br />
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 enforce 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.<br />
<br />
<div class="img-responsive"><br />
[[File:Proof_of_Work.png|centre|alt=A chain of hash based proof of work]]<br />
</div><br />
<br />
During the [[mining]] process, a node gathers transactions from the network on a [[First seen rule|first seen]] basis 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. Hash operators continuously request new block templates through the [[Getminingcandidate]] interface to ensure they are getting up-to-date block data to hash against. 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.<br />
<br />
[[File:Merkle tree.png|centre|alt=The structure of a Merkle Tree]]<br />
<br />
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 each miner is connected to most of the other miners. Miners gather transactions from users who connect in a layered network over the nodes at the core forming something that closely resembles a [[Mandala Network]]. Peers operating in these shell-like layers use [[Simplified Payment Verification]] to form a much less densely packed structure where information is exchanged in [[Payment Channels]].<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Unit of account===<br />
[[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.<br />
<br />
Satoshis are distributed by miners to themselves as a [[Block subsidy|subsidy payment]] during the network establishment phase. As the network matures, 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.<br />
<br />
===Network rules===<br />
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.<br />
<br />
There are no limits in the [[Protocol|Bitcoin protocol]]. Any limits imposed 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.<br />
<br />
===History===<br />
[[Bitcoin until today|Bitcoin has a rich history]].<br />
<br />
===Tools and Building on Bitcoin===<br />
Bitcoin has a rich and diverse [[Building on Bitcoin|set of tools]] which are being added to all the time.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Block&diff=2770Block2022-01-11T01:54:33Z<p>Brendan: /* Description */</p>
<hr />
<div>Bitcoin transaction data is immutably recorded by Miners into files called '''blocks'''. Blocks can be thought of as the individual pages of a city recorder's record book (where changes to title to real estate are recorded) or a stock transaction ledger. Each block references the previous block that it was built upon allowing the record of history to form a linear sequence over time, known as the [[blockchain]]. New transactions are constantly being processed by [[Mining|Miners]] into new blocks which are added to the end of the chain. As new blocks are added to the tip of the chain, blocks are [[Confirmation|buried deeper and deeper]] and become [[Proof_of_Work|harder]] to change or remove, forming part of the Bitcoin network's security model. <br />
<br />
===Block message structure===<br />
{| class="wikitable"<br />
|-<br />
! Field<br />
! Description<br />
! Size<br />
|-<br />
|Magic no<br />
|Data field indicating that this data packet contains a BitcoinSV block. Value always 0xD9B4BEF9<br />
|4 bytes<br />
|-<br />
|Block size<br />
|number of bytes remaining in the packet up to end of block<br />
|4 bytes<br />
|-<br />
|[[Block header]]<br />
|[[Block header| consists of 6 items]]<br />
| 80 bytes<br />
|-<br />
|Transaction counter<br />
| positive integer VI = [[VarInt]]<br />
| 1 - 9 bytes<br />
|-<br />
|[[Transactions]]<br />
|the (non empty) list of transactions<br />
|<Transaction counter>-many transactions<br />
|}<br />
<br />
==Description==<br />
Each block contains, among other things, the [[Block timestamp|current time]], a record of some or all recent [[Bitcoin_Transactions|transactions]], and a reference to the block that came immediately before it. It also contains an answer to a hash puzzle which is unique to each block. The [[Block hashing algorithm]] requires that Miners pre-build their block candidate before trying to solve the puzzle. New blocks cannot be submitted to the network without the correct answer - the process of "[[mining]]" is essentially the process of competing to be the next to find the answer that "solves" the current block. The hash puzzle in each block is [[difficulty|difficult]] to solve, but once a valid solution is found, it is very easy for the rest of the network to confirm that the solution is correct. There are multiple valid solutions for any given block - only one of the solutions needs to be found for the block to be solved.<br />
<br />
As a reward for building and performing work on a block and successfully propagating it to the network, the winning Miner awards themselves the [[block subsidy]] and any [[Transaction fees]] that have been included in the transactions. The winning Miner pays this reward out to themselves in the first transaction in the block which is known as a generation transaction, or a [[coinbase]] transaction. The block subsidy started at 50 bitcoins per block and is halved every 210,000 blocks, or about every four years.<br />
<br />
When Bitcoin transactions are broadcast to the [[network]] by the sender, nodes who compete to build blocks collect the transactions and add them to the block they are working to solve. Miners' incentive to include transactions in their blocks is the attached [[Transaction fees]].<br />
<br />
The [[difficulty]] of the mathematical problem is automatically adjusted by the network, such that it targets a goal of solving an average of 6 blocks per hour. In the original design this rate was adjusted every 2016 blocks which is around 2 weeks. Currently (November 2019) the BitcoinSV network follows a 'Difficulty Adjustment Algorithm' (DAA) which adjusts the difficulty every block.<br />
<br />
Because each block contains a reference to the prior block, the collection of all blocks in existence can be said to form a chain. However, it's possible for the chain to have temporary splits - for example, if two Miners arrive at two different valid solutions for the same block at the same time, unbeknownst to one another. The peer-to-peer network is designed to resolve these splits within a short period of time, so that only one branch of the chain survives.<br />
<br />
The client accepts the 'longest' chain of blocks as valid. The 'length' of the entire [[blockchain]] refers to the chain with the most blocks at the required difficulty.<br />
<br />
==See Also==<br />
<br />
* [[Block header]]<br />
* [[Blockchain]]<br />
* [[Block hashing algorithm]]<br />
* [[Block timestamp]]<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Block 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=OP_RETURN&diff=2769OP RETURN2022-01-11T01:52:37Z<p>Brendan: /* Commentary: Is storing data in the blockchain acceptable? */</p>
<hr />
<div>'''OP_RETURN''' is a [[Opcodes_used_in_Bitcoin_Script|script]] opcode used to terminate the script and return the top value on the stack. This opcode is analogous to the return function in programming languages. The OP_RETURN opcode has seen its functionality modified several times in its [[History_of_OP_RETURN|history]] in Bitcoin and as a result, has been primarily used as a means of storing data on the ledger.<br />
<br />
===OP_RETURN Functionality===<br />
OP_RETURN terminates the script leaving the stack as-is and letting the result on top of the stack determine the success or failure of the script. Note that if the top stack is non-empty and non-zero (zero including a string of zeros, of zero bytes), then it is considered as successful. Otherwise, it is considered as fail.<br />
<br />
=== False Return ===<br />
One of the most common uses of OP_RETURN is to create [[False Return]] scripts that can be used to generate provably unspendable transaction outputs. The most common usage of these scripts is to hold arbitrary formatted data for use in [[Application Layer Protocols]]. False Return outputs can be used to hold data, information pertaining to ownership rights, software elements, art and more.<br />
<br />
=== Use in conditional logic ===<br />
OP_RETURN can be used in combination with [[Opcodes_used_in_Bitcoin_Script#Flow_control|flow control]] opcodes to implement branching and other conditional logic in scripts. The insertion of an OP_RETURN opcode in an IF loop, can allow a script to terminate without having to exit the IF loop, saving computation and reducing the cost of processing the transaction.<br />
<br />
=== Commentary: Is storing data in the blockchain acceptable? ===<br />
In a word, yes. The Bitcoin ledger and the [[blockchain]] that secures it, operate on the free market premise of user pays. If a user wishes to use the ledger to store data of any type, the only requirement upon them is they must pay for the space needed to store it.<br />
This mechanism guards the ledger from abuse by allowing node operators to set a floor in the price of ledger space, while also allowing nodes to compete to provide users with lower cost services.<br />
It is node operators who decide which transactions they will accept into the blocks they append to the blockchain, and as such anyone seeking to use the ledger as a data storage medium, must meet the market in terms of the price they pay. Over time it is expected that the cost of ledger space will fall, not just in terms of the price in [[satoshis]], but in dollar terms as well. The ledger scales with technology and commensurate falls in price that comes with the unlocking of new and lower cost storage media, which will translate to larger swathes of ledger space becoming available for less fees.<br />
<br />
===Example=== <br />
The below script is a Metanet node that attaches the Metanet data to a UTXO with funds. This can be used to ensure that Metanet nodes are left in the UTXO set.<br />
<br />
{| class="wikitable" <br />
|-<br />
! colspan="2"| ๐๐ฅ๐ผ๐ท<sub>๐๐๐๐</sub><br />
|-<br />
| ''Inputs''<br />
| ''Outputs''<br />
|-<br />
| <sig<sub>metaParent</sub>> <pubKey<sub>metaParent</sub>> <sig<sub>script</sub>> <pubKey<sub>script</sub>> <br />
| DUP HASH160 <pkh<sub>script</sub>> EQUALVERIFY CHECKSIG RETURN <meta> <pk<sub>metaNode</sub>> <txid<sub>metaParent</sub>> <metanetData><br />
|}<br />
<br />
{{DISPLAYTITLE:OP_RETURN}}</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Payment_Channels&diff=2768Payment Channels2022-01-11T01:52:12Z<p>Brendan: </p>
<hr />
<div>''Payment Channels'' are a mechanism where two or more parties can directly exchange and update a transaction. The mechanism includes methods for establishing, or opening a payment channel, updating the channel, and finalising, or closing the payment channel. The mechanism also covers the possibility of any of the parties becoming unresponsive, usually by enabling the recovery of funds after a fixed time.<br />
<br />
Payment channels support extremely rapid transaction updates with only the final closing transaction being timestamped on the blockchain.<br />
<br />
Payment channels can be useful for streaming data, operating a sequence of events, or operating with a live dataset in applications such as gaming and more.<br />
<br />
==Properties==<br />
*Payment channels can be opened and closed arbitrarily.<br />
*Payment channels can be opened directly with the participating peers, without needing a third party.<br />
*It is possible to open a payment channel with or without an on-chain action.<br />
*Payment channels can be private or public.<br />
*You can have many peers in a channel.<br />
*You can add and remove peers from a channel.<br />
*Payment channels are data conduits.<br />
*Channels are typically closed with an on-chain payment, however an on-chain payment can be made outside the channel which causes it to update.<br />
<br />
==Overview of the Mechanism==<br />
A payment channel uses a transaction that has an [[nSequence]] that is less than 0xFFFFFFFF, and a nLocktime set to a time or block height in the future. The transaction can be updated many times between the peers until either, the nLocktime is reached, or nSequence is finalised and one of the parties transmits the transaction to the blockchain.<br />
<br />
==Example - Streaming Movie==<br />
The following goes through the sequence of opening, using, and closing a payment channel for the purposes of serving streamed content.<br />
<br />
===STEP 1===<br />
User browses catalog for titles to watch. Content can be on-chain or off-chain. <br />
<br />
===Step 2===<br />
User selects the content. At this point, there can be a few ways to manage the channel:<br />
*In public via mining network.<br />
*In private with pre-funded UTXO per channel.<br />
*In private with separate channels for content purchase and service delivery per user.<br />
<br />
===Step 3===<br />
In this example, peers will use a timelocked UTXO in a public channel managed by Miners to serve the content.<br />
For the sake of this example we will assume a single UTXO is being used. This UTXO goes into a double spend monitoring pool.<br />
<br />
The viewer sends a transaction with the following output script to the provider to initiate the channel:<br />
<br />
Where:<br />
* S<sub>vn</sub> is the Viewer's nth iteration of the channel signature.<br />
* P<sub>v</sub> is the Viewer's pubkey.<br />
* H<sub>v</sub> is the Viewer's PKH.<br />
<br />
* S<sub>pn</sub> is the service provider's nth iteration of the channel signature.<br />
* P<sub>p</sub> is the service provider's pubkey.<br />
* H<sub>p</sub> is the service provider's PKH.<br />
* H<sub>c0</sub> is the hash of the merkle root of the content being selected.<br />
* H<sub>cn</sub> is the hash of each content frame with H<sub>c1</sub> being the hash of the first frame.<br />
* C<sub>n</sub> is the content frame with C<sub>1</sub> being the first frame data.<br />
* H<sub>fm</sub> is the hash of a message the user can trigger to prematurely end or pause the stream.<br />
* F<sub>m</sub> is a message that the provider uses to end the stream.<br />
<br />
The sequence no. for the input being spent is still 1.<br />
<br />
The transaction iterates between the two scripts as as follows:<br />
<br />
==Iteration 1==<br />
<br />
The user signs the inputs they want to spend in, as payment using SIGHASH_ALL with the following outputs:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Script No.<br />
! Purpose<br />
! Script<br />
! Amount<br />
|-<br />
| 1<br />
| Iteration 1: Content Request<br />
| H<sub>c0</sub> DROP DUP HASH160 H<sub>p</sub> EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H<sub>v</sub> EQUALVERIFY CHECKSIG<br />
| Price of first frame<br />
|-<br />
| 2<br />
| Change<br />
| Viewer's change script<br />
| Change amount<br />
|}<br />
<br />
The Viewer also supplies the following data allowing the content provider to spend the payment channel output if the payment channel is closed:<br />
<br />
*''S<sub>v0</sub> P<sub>v</sub>'' where the signature is signed as SIGHASH_ANYONECANPAY | SIGHASH_NONE. The user can do this as the payment channel's current TXID can be generated allowing the user to sign the output against the most recent revision of the payment channel.<br />
<br />
This would allow the service provider to close the channel by countersigning the tx and settling on the network, guaranteeing payment for the first frame.<br />
<br />
The transaction pays out the price of the first frame to the service provider and the remainder is returned to the viewer as change. If the viewer cancels their session without watching, the transaction can still be processed on the network, and using the provided second signature the service provider can claim their money.<br />
<br />
===Step 4===<br />
The provider responds with a new version of the transaction that modifies the output as shown:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Script No.<br />
! Purpose<br />
! Script<br />
! Amount<br />
|-<br />
| 1<br />
| Iteration 2: First frame<br />
| SHA256 H<sub>c1</sub> EQUALVERIFY DUP HASH160 H<sub>p</sub> EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H<sub>v</sub> EQUALVERIFY CHECKSIG<br />
| Price of second frame<br />
|-<br />
| 2<br />
| Change<br />
| Viewer's change script<br />
| Change amount<br />
|} <br />
<br />
They also provide a new signature ''S<sub>p0</sub>'' for this output, allowing the user to countersign and broadcast the previous iteration should they wish to close the channel.<br />
<br />
When the user receives this new output, they sign the inputs against the updated content to indicate they have received the first frame and provide the streaming service with payment for the second frame. The amounts can be optimised for the service provider's fee model.<br />
<br />
If the payment channel were closed, this output could be subsequently spent by providing the second packet of movie data as part of the input. This is not the ideal way for the output to be created on-chain, as there are higher transaction fees involved, but is done this way to allow both parties to acknowledge the progression through the content.<br />
<br />
===Step 5===<br />
The viewer completes the transaction as shown:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Script No.<br />
! Purpose<br />
! Script<br />
! Amount<br />
|-<br />
| 1<br />
| Iteration 3: Second frame<br />
| SHA256 ''H<sub>c2</sub>'' EQUALVERIFY DUP HASH160 H<sub>p</sub> EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H<sub>v</sub> EQUALVERIFY CHECKSIG<br />
| Price of second frame<br />
|-<br />
| 2<br />
| Change<br />
| Viewer's change script<br />
| Change amount<br />
|}<br />
As in the previous iteration, they sign to indicate they have received the frame and provide the streaming service with payment for the next frame. This can be optimised for each service provider's fee model. <br />
<br />
They also provide a new signature for this output, ''S<sub>v1</sub>'', allowing the service provider to countersign should they need to close the channel. In this example, the keypairs being used don't need to change for each iteration, but they could.<br />
<br />
===Step N===<br />
The user can request that the provider close the channel. Streams can also be paused, or take place at any framerate, or even use larger transactions to move chunks at a time. <br />
In this case the user is deciding to close it.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Script No.<br />
! Purpose<br />
! Script<br />
! Amount<br />
|-<br />
| 1<br />
| Iteration N: Final frame<br />
| SHA256 H<sub>fm</sub> EQUALVERIFY DUP HASH160 H<sub>p</sub> EQUALVERIFY CHECKSIGVERIFY EQUALVERIFY DUP HASH160 H<sub>v</sub> EQUALVERIFY CHECKSIG<br />
| Price of second frame<br />
|-<br />
| 2<br />
| Change<br />
| Viewer's change script<br />
| Change amount<br />
|}<br />
<br />
The user puts the finish message hash at the front of the output. The streaming provider sees this and knows the customer wants to close the channel. <br />
The user provides a new signature for this output, ''S<sub>vn</sub>''. This allows the streaming service provider to finalise the channel.<br />
<br />
===Step N+1===<br />
<br />
The provider broadcasts the final transaction and spends their payment with the following script:<br />
<br />
''S<sub>vn</sub> P<sub>v</sub> S<sub>pn</sub> P<sub>p</sub> F<sub>m</sub>''<br />
<br />
In this way, rather than closing the transaction with a potentially large blob of content data at the front, just a short code need be used.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Protocol&diff=2767Protocol2022-01-11T01:51:52Z<p>Brendan: /* Immutable Rules */</p>
<hr />
<div>==Bitcoin Protocol Rules==<br />
The rules of the Bitcoin protocol are the rules that precisely define the Bitcoin system.<br />
<br />
There are different classes of rule in the Bitcoin system including:<br />
*Immutable rules<br />
*Mutable rules<br />
**Local Policies<br />
**Standard Policies<br />
*Communication rules<br />
<br />
== Immutable Rules ==<br />
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 simultaneous, network wide changes to the rules used by all node client and can result in a ledger duplication in cases where disparate groups of Miners enforce different sets of changes. As Bitcoin is defined by these rules, a network that extends a chain in which they are altered might share the history of the ledger but cannot be considered to be Bitcoin, rather it is a new blockchain starting at the block where the rule change was enacted.<br />
<br />
These include:<br />
<br />
*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.<br />
*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]] per block from the genesis block.<br />
*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.<br />
*Only blocks that add to the [[blockchain]] formed by building upon the [[Genesis block]] are valid.<br />
*The structure of the Bitcoin database as a timestamp server validating chains of transaction outputs.<br />
*Transaction data formatting, including sizes of certain fields and their encoding schema.<br />
*Block structure and header information including sizes of certain fields and their encoding schema.<br />
* The [[Advanced Bitcoin Scripting|Bitcoin scripting language]] and its specification including:<br />
**Lists of opcodes that are usable in script and the exact outcome of their execution<br />
<br />
Forced changes to these protocol rules in the past have resulted in duplications of the Bitcoin database. In doing so, creating BTC which implemented 'Segregated Witness', removing the requirement for Bitcoin to be a chain of digital signatures. BCH enforced a transaction ordering schema onto the timestamping function of the system, and modified the scripting language to add op codes, with functionality outside the scope of the original design.<br />
<br />
The Bitcoin SV philosophy is, 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โ. Only changes needed to protect the security of the network such as, the migration to a new hash function should SHA256 be broken, will be allowed, with this rule being enforced through [[Nakamoto Consensus]].<br />
<br />
== Mutable Rules ==<br />
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.<br />
Examples of these include:<br />
*The maximum script memory usage rule which governs how much memory a transaction can consume during the execution of its script.<br />
*The maximum block-size rule.<br />
*Transaction script rules such as the rule preventing the use of opcodes other than pushdata in ScriptSig.<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
===Local rules===<br />
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.<br />
Local rules include:<br />
*The โminimum feeโ rule, which specifies that the node will only accept and/or relay unconfirmed transactions that pay above a certain fee.<br />
*Dust rules which specify the smallest value output a transaction can contain that the node will accept and/or relay.<br />
*Rules relating to inbound and outbound connections on the network, such as RPC responses, specific IP addresses to connect to, and more.<br />
<br />
===Standard Policies===<br />
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.<br />
<br />
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.<br />
<br />
==Communication Rules==<br />
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 communication 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.<br />
<br />
==See Also==<br />
* [[The Bitcoin Network]]<br />
* [[Nakamoto Consensus]]<br />
* [[P2P Network]]<br />
<br />
==References==<br />
[1] - https://github.com/bitcoin-sv-specs/protocol/blob/master/updates/genesis-spec.md</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Proof_of_Work&diff=2766Proof of Work2022-01-11T01:51:27Z<p>Brendan: /* Proof of Work in Bitcoin */</p>
<hr />
<div>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. <br />
<br />
== Proof of Work in Bitcoin ==<br />
<br />
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 [[blockchain]] to one block every 10 minutes.<br />
<br />
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 blockchain from tampering.<br />
<br />
=== Summary ===<br />
<br />
1. Proof of work is part of the Bitcoin consensus mechanism.<br />
<br />
2. The Bitcoin proof of work algorithm attempts to solve a puzzle with a low probability of success per trial.<br />
<br />
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.<br />
<br />
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 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 computer will generate the next block.<br />
<br />
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.<br />
<br />
==Attribution==<br />
This content is based on content sourced from https://en.bitcoin.it/wiki/Proof_of_work 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.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Home_Page&diff=2765Home Page2022-01-11T01:49:44Z<p>Brendan: </p>
<hr />
<div>Here we aim to provide a correct and up-to date set of information on the Bitcoin network and its features and functionality.<br />
<br />
===What is Bitcoin?===<br />
<br />
'''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 [https://bitcoinsv.io/bitcoin.pdf Bitcoin Whitepaper] in October 2008, and the source code was [https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html released] in January 2009. The Bitcoin ledger and [[Blockchain]] were established with the generation of the [[Genesis block]] on the 3rd of January 2009 and the mining of Block 1 six days later on the 9th of January 2009.<br />
<br />
Bitcoin allows electronic payments to be sent directly from one party to another, without requiring a central institution or server to process transactions and/or store funds. <br />
<br />
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.<br />
<br />
Bitcoin Satoshi Vision (Bitcoin SV) was created to maintain the integrity of the Bitcoin public ledger by reverting back to the original Bitcoin protocol with the intention of keeping it stable and secure, and allowing it to scale massively in order to accommodate global demand for open public ledger technology.<br />
<br />
BitcoinSV will maintain the vision set out by Satoshi Nakamotoโs visionary 2008 white paper titled Bitcoin: A Peer-to-Peer Electronic Cash System which includes:<br />
*Scaling network systems and developing robust mining client software in order to accommodate global demand for ledger space.<br />
<br />
*Allowing a distributed small world network to form at the center of a Mandala network connecting billions of people through their devices.<br />
<br />
*Elevating Miners into their role as service provider.<br />
<br />
*Generating on-chain economic activity sufficient to allow transaction fees to supplant block subsidies as their primary funding mechanism.<br />
<br />
*Driving a culture of using transaction fees to price transactions as a service.<br />
<br />
*Leveraging economic incentives to build network security.<br />
<br />
*Allowing the Bitcoin network to become a global infrastructure platform for financial and information exchange processes.<br />
<br />
<br />
<br />
{| id="mp-right" style="width:100%; vertical-align:top; background:#ffdb65;"<br />
! style="padding:2px" | <h2 id="mp-otd-h2" style="margin:3px; background:#eab300; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:center; color:#000; padding:0.2em 0.4em;">Topic central</h2><br />
|-<br />
| style="color:#000;padding:2px 5px 5px" | <div id="mp-otd"><br />
{|cellpadding="2" style="background-color: inherit;"<br />
|-<br />
| scope="col" style="width: 750px;" |<br />
* '''Wallets<br />
** Handcash<br />
** Moneybutton<br />
** Centbee<br />
** RelayX<br />
** Simply Cash<br />
** ElectrumSV<br />
* '''Node Software<br />
** [https://bitcoinsv.io Bitcoin SV]<br />
* '''Development Tools<br />
** bsv JS library<br />
** gobitcoinsv.com<br />
| scope="col" style="width: 750px;" |<br />
* '''Helpful Links<br />
** [[Opcodes used in Bitcoin Script]]<br />
** [[Bitcoin Transactions]]<br />
** Bitcoin Whitepaper<br />
** Block Explorers<br />
*** Whatsonchain<br />
<br />
|}<br />
</div></div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Timechain&diff=2764Timechain2022-01-11T01:49:09Z<p>Brendan: </p>
<hr />
<div>The word Timechain can be used to refer to the nature of the Bitcoin [[Blockchain]] 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 in the format used in the transaction payload.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Bitcoin_wallet_libraries&diff=2763Bitcoin wallet libraries2022-01-11T01:48:37Z<p>Brendan: </p>
<hr />
<div>=== Introduction ===<br />
Many node software libraries have been created enabling developers experienced with any programming language to start interacting with the Bitcoin [[blockchain]].<br />
<br />
Bitcoin SV's locked down consensus protocol enables fast-paced development of blockchain infrastructure, including base wallet libraries. Wallet applications can therefore be built without fear of future dependency risk and developers can be assured that changes that result their software becoming incompatible with Bitcoin SV will not be made.<br />
<br />
=== Node software libraries ===<br />
* [https://nakasendoproject.org/ The Nakasendo SDK] serves to abstract not only lower level Bitcoin protocol functions but advanced cryptographic techniques such as encryption and threshold signatures so that developers can implement this functionality more easily. The SDK will be available in C++, JavaScript, and python.<br />
<br />
* [https://github.com/moneybutton/bsv bsv] is a JavaScript library is a comprehensive toolset for managing, building, signing and broadcasting Bitcoin SV transactions.<br />
<br />
* [https://github.com/AustEcon/bitsv Bitsv] is a library for similar functionality as the BSV library, implemented in python.<br />
<br />
* [https://gitlab.com/bitcoinj-sv/bitcoinj-sv/ bitcoinj-sv] is a Java implementation of the Bitcoin SV protocol.<br />
<br />
* [https://github.com/brentongunning/rust-sv Rust-SV] is a Rust implementation of the Bitcoin SV protocol.<br />
<br />
* [https://github.com/bitcoinsv/bsvd bsvd] is a Golang implementation of the Bitcoin SV protocol.<br />
<br />
* [https://github.com/ordishs/go-bitcoin go-bitcoin] is a wrapper library to the Bitcoin SV RPC implemented in Golang.<br />
<br />
* [https://github.com/kzbsv/KzBsv KzBsv] is a work in progress C# library for Bitcoin SV.<br />
<br />
* [https://github.com/nextcashtech/bitcoin Nextcash] is a C++ BSV implementation.<br />
<br />
* [https://hexdocs.pm/bsv/BSV.html BSV-ex] is a Bitcoin SV library implemented in Elixir.<br />
<br />
* [https://github.com/kevinejohn/bsv-minimal bsv-minimal] is a lean re-implementation of the BSV library in Javascript, optimized to process big blocks efficiently.<br />
<br />
* Contact the Bitcoin Association to have your Bitcoin node or wallet code library added.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Peer-to-Peer_Network_Architecture&diff=2762Peer-to-Peer Network Architecture2022-01-11T01:47:55Z<p>Brendan: </p>
<hr />
<div>Peer-to-Peer computing or networking is a distributed application network architecture that shares resources amongst the participants. Participants are called nodes and are said to form a Peer-to-Peer network [1]. A distributed network architecture is classified as a "Pure" Peer-to-Peer if the removal of any single, arbitrarily chosen, node will not result in the loss of network service.<br />
<br />
==The Bitcoin Peer-to-Peer Network==<br />
<br />
Formally, the Bitcoin network is a Pure Peer-to-Peer network built on top of the internet. In the early days of Bitcoin the network had a flat topological structure, in which users were capable of running full nodes that could perform all of Bitcoin's main functions: transaction creation, transaction validation and [[Mining |mining]] (see [https://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html bitcoinv0.1]). However, as the network has grown, the requirements needed to perform each function on the network have evolved creating a necessity for nodes to specialize. Currently, the 3 main functions of the Bitcoin system are, in general, performed by separate actors within the ecosystem. Transaction creation is done by [[Simplified Payment Verification|SPV]] wallets. Transaction validation is done by the Bitcoin SV node client software and mining is a separate function performed using purpose built mining software.<br />
<br />
==Peer-to-Peer Architecture and the Bitcoin Scalability Dispute==<br />
<br />
Peer-to-peer is a term often misused and misunderstood, partly due the philosophical significance of ''decentralization'' which is seen as a key feature of "blockchain technology". It has also been at the heart of disputes within the Bitcoin community that have lead to contentious ledger duplications that have resulted in the creation of competing [[blockchain|blockchains]] on two occasions as well as generally delayed the development of the technology. <br />
<br />
The role of transaction validation and mining cannot be dominated by a single entity as the network would cease to provide any cryptographic or game theoretic advantages over existing centralized digital money systems. It is the firm belief of the Bitcoin SV community that scalability can be achieved through specialization whilst maintaining strong security and distribution of the network in a leaderless manner.<br />
<br />
==References==<br />
1. Rรผdiger Schollmeier, [https://www.researchgate.net/publication/3940901_A_Definition_of_Peer-to-Peer_Networking_for_the_Classification_of_Peer-to-Peer_Architectures_and_Applications A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications], Proceedings of the First International Conference on Peer-to-Peer Computing, IEEE (2002).</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Simplified_Payment_Verification&diff=2761Simplified Payment Verification2022-01-11T01:46:46Z<p>Brendan: </p>
<hr />
<div>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 [[Blockchain]], 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.<br />
<br />
SPV allows users to securely transact with each other, peer-to-peer, while nodes act to form the settlement layer.<br />
<br />
===Advantages===<br />
The advantages of using SPV are clear in terms of the volume of data required:<br />
<br />
* 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).<br />
<br />
* contrast this with the '''hundreds of gigabytes''' which would be required to store the entire chain, if SPV were not being used.<br />
<br />
* 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. <br />
<br />
As explained in Section 8 of the [[Bitcoin whitepaper]]:<br />
{{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 ... }}<br />
<br />
And in Section 7:<br />
{{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 ..."''}} <br />
<br />
===Approach===<br />
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 network 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 [[confirmation|confirmed]] at least 6 times whatever the transaction type, amount or situation.<br />
<br />
The better approach is that transactions between SPV clients are negotiated peer-to-peer and settled on the ledger 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.<br />
<br />
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 ledger or even the [[UTXO]] set 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.<br />
<br />
===Merkle Trees, Merkle Roots, Merkle Paths and Merkle Proofs===<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
* 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).<br />
<br />
* To '''validate''' a proof, a user (or their wallet) only needs the chain of block headers (as opposed to the whole blocks themselves). I.e. they need their own copy of the [[block header]] of each block, 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 was time stamped in a specific block, without examining every transaction in that block.<br />
<br />
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:<br />
<br />
[[File: Merkle_tree2.png|frameless|1000px|alt=Three transactions and the Merkle paths which can be used to relate them to blocks]]<br />
<br />
===SPV Wallet===<br />
An SPV wallet is a lightweight wallet that uses the mechanism of SPV to construct Bitcoin transactions and payments. <br />
<br />
To spend a UTXO, a user of a SPV wallet will pass on the following information to the receiver:<br />
# <math>Transaction_0</math> - the transaction that contains the UTXO as an output,<br />
# The Merkle path of <math>Transaction_0</math><br />
# The block header that contains the Merkle root derived from the Merkle path (or its identifier, e.g., block height)<br />
# <math>Transaction_1</math> - the transaction that spends the UTXO<br />
<br />
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.<br />
<br />
=== Offline Payment ===<br />
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>.</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=OP_RETURN&diff=2760OP RETURN2022-01-11T01:45:06Z<p>Brendan: </p>
<hr />
<div>'''OP_RETURN''' is a [[Opcodes_used_in_Bitcoin_Script|script]] opcode used to terminate the script and return the top value on the stack. This opcode is analogous to the return function in programming languages. The OP_RETURN opcode has seen its functionality modified several times in its [[History_of_OP_RETURN|history]] in Bitcoin and as a result, has been primarily used as a means of storing data on the ledger.<br />
<br />
===OP_RETURN Functionality===<br />
OP_RETURN terminates the script leaving the stack as-is and letting the result on top of the stack determine the success or failure of the script. Note that if the top stack is non-empty and non-zero (zero including a string of zeros, of zero bytes), then it is considered as successful. Otherwise, it is considered as fail.<br />
<br />
=== False Return ===<br />
One of the most common uses of OP_RETURN is to create [[False Return]] scripts that can be used to generate provably unspendable transaction outputs. The most common usage of these scripts is to hold arbitrary formatted data for use in [[Application Layer Protocols]]. False Return outputs can be used to hold data, information pertaining to ownership rights, software elements, art and more.<br />
<br />
=== Use in conditional logic ===<br />
OP_RETURN can be used in combination with [[Opcodes_used_in_Bitcoin_Script#Flow_control|flow control]] opcodes to implement branching and other conditional logic in scripts. The insertion of an OP_RETURN opcode in an IF loop, can allow a script to terminate without having to exit the IF loop, saving computation and reducing the cost of processing the transaction.<br />
<br />
=== Commentary: Is storing data in the blockchain acceptable? ===<br />
In a word, yes. The Bitcoin ledger and the [[blockchain]] that secures it, operate on the free market premise of user pays. If a user wishes to use the ledger to store data of any type, the only requirement upon them is they must pay for the space needed to store it.<br />
This mechanism guards the ledger from abuse by allowing node operators to set a floor in the price of ledger space, while also allowing nodes to compete to provide users with lower cost services.<br />
It is node operators who decide which transactions they will accept into the blocks they append to the block chain, and as such anyone seeking to use the ledger as a data storage medium, must meet the market in terms of the price they pay. Over time it is expected that the cost of ledger space will fall, not just in terms of the price in [[satoshis]], but in dollar terms as well. The ledger scales with technology and commensurate falls in price that comes with the unlocking of new and lower cost storage media, which will translate to larger swathes of ledger space becoming available for less fees.<br />
<br />
===Example=== <br />
The below script is a Metanet node that attaches the Metanet data to a UTXO with funds. This can be used to ensure that Metanet nodes are left in the UTXO set.<br />
<br />
{| class="wikitable" <br />
|-<br />
! colspan="2"| ๐๐ฅ๐ผ๐ท<sub>๐๐๐๐</sub><br />
|-<br />
| ''Inputs''<br />
| ''Outputs''<br />
|-<br />
| <sig<sub>metaParent</sub>> <pubKey<sub>metaParent</sub>> <sig<sub>script</sub>> <pubKey<sub>script</sub>> <br />
| DUP HASH160 <pkh<sub>script</sub>> EQUALVERIFY CHECKSIG RETURN <meta> <pk<sub>metaNode</sub>> <txid<sub>metaParent</sub>> <metanetData><br />
|}<br />
<br />
{{DISPLAYTITLE:OP_RETURN}}</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Orphan_Block&diff=2759Orphan Block2022-01-11T01:44:48Z<p>Brendan: </p>
<hr />
<div>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 chain of proof of work. 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 well-formed [[Blockchain]]. This phenomenon must be taken into account by mining pools that use any payout strategy other than "proportional". <br />
<br />
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, 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.<br />
<br />
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 utilisation 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.<br />
<br />
==See Also==<br />
* [[Miner subsidy]]</div>Brendanhttps://wiki.bitcoinsv.io/index.php?title=Nakamoto_Consensus&diff=2758Nakamoto Consensus2022-01-11T01:44:30Z<p>Brendan: </p>
<hr />
<div>Nakamoto consensus is 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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
By choosing which chain to build upon, the nodes vote to enforce the rules that govern the protocol, and use of the [[Blockchain]] as a global financial ledger with legal and regulatory oversight.<br />
<br />
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. <br />
<br />
The security of Nakamoto consensus has been studied by academia and tested in the real world since 2009.</div>Brendan