https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Dionyziz&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T18:48:08ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=OP_RETURN&diff=65736OP RETURN2018-09-20T15:30:23Z<p>Dionyziz: The recommendation for BIPs is outdated. No such BIPs exist and the practice has been discouraged on the mailing list.</p>
<hr />
<div>'''OP_RETURN''' is a [[script]] opcode used to mark a transaction output as invalid. Since any outputs with OP_RETURN are provably unspendable, OP_RETURN outputs can be used to [[Proof of burn|burn]] bitcoins.<br />
<br />
== Is storing data in the blockchain acceptable? ==<br />
Many members of the Bitcoin community believe that use of OP_RETURN is irresponsible in part because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data. Additionally, it is trivially obvious that the demand for external, massively-replicated data store is essentially infinite. Despite this, OP_RETURN has the advantage of not creating bogus UTXO entries, compared to some other ways of storing data in the blockchain.<br />
<br />
From [https://bitcoin.org/en/release/v0.9.0#opreturn-and-data-in-the-block-chain Bitcoin Core release 0.9.0]:<br />
<blockquote><br />
This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin's UTXO database.<br />
<br />
Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.<br />
</blockquote><br />
<br />
== OP_RETURN applications ==<br />
OP_RETURN can be used for digital asset proof-of-ownership, and has at times been used to convey additional information needed to send transactions (see [[stealth address]]).<br />
<br />
<br />
{{DISPLAYTITLE:OP_RETURN}}</div>Dionyzizhttps://tests.bitcoin.it/w/index.php?title=Script&diff=62366Script2017-03-04T22:41:06Z<p>Dionyziz: notif and if are two different ops</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.<br />
<br />
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to show evidence 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, or even no keys at all.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).<br />
<br />
This document is for information purposes only. Officially Bitcoin script is defined by [https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp its reference implementation].<br />
<br />
The stacks hold byte vectors.<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 is represented by a null-length vector.<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 />
== Words ==<br />
This is a list of all Script words, also known as opcodes, commands, or functions.<br />
<br />
There are some words which existed in very early versions of Bitcoin but were removed out of a concern that the client might have a bug in their implementation. This fear was motivated by a bug found in OP_LSHIFT which could crash any Bitcoin node if exploited, and by other bugs in how Script worked which allowed anyone to spend anyone's bitcoins. The removed opcodes are sometimes said to be "disabled" opcodes, but this is something of a misnomer because there is ''absolutely no way'' for anyone using Bitcoin to use these opcodes (they simply ''do not exist anymore'' in the protocol), and there are also no solid plans to ever re-enable all of these opcodes. They are listed here only for historical interest.<br />
<br />
New opcodes can be added by means of a carefully designed and executed [[softfork]] using OP_NOP1-OP_NOP10.<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 />
|N/A<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 />
|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 />
|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.<br />
|-<br />
|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.<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_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not False, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> notif [statements] [else [statements]]* endif<br />
|If the top stack value is False, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not. <br />
|-<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 OP_IF earlier 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.<br />
|-<br />
|[[OP_RETURN]]<br />
|106<br />
|0x6a<br />
|Nothing<br />
|''fail''<br />
|'''Marks transaction as invalid'''. A standard way of attaching extra data to transactions is to add a zero-value output with a scriptPubKey consisting of OP_RETURN followed by exactly one pushdata op. Such outputs are provably unspendable, reducing their cost to the network. Currently it is usually considered non-standard (though valid) for a transaction to have more than one OP_RETURN output or an OP_RETURN output with more than one pushdata op.<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_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 />
|Puts the number of stack items onto the stack.<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 />
|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 />
<br />
=== Splice ===<br />
<br />
If any opcode marked as disabled is present in a script, it must abort and fail.<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 />
|style="background:#D97171;"|Concatenates two strings. ''disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''<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 />
If any opcode marked as disabled is present in a script, it must abort and fail.<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 />
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''<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 />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script must abort and fail. <br />
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.<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<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''disabled.''<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 />
|style="background:#D97171;"|a is multiplied by b. ''disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''<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 />
=== Crypto ===<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, one extra unused value is removed from 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 />
=== Locktime ===<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)<br />
|177<br />
|0xb1<br />
|x<br />
|x / ''fail''<br />
|'''Marks transaction as invalid''' if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in [[BIP 0065]]<br />
|-<br />
|OP_CHECKSEQUENCEVERIFY (previously OP_NOP3)<br />
|178<br />
|0xb2<br />
|x<br />
|x / ''fail''<br />
|'''Marks transaction as invalid''' if the relative lock time of the input (enforced by [[BIP 0068]] with nSequence) is not equal to or longer than the value of the top stack item. The precise semantics are described in [[BIP 0112]].<br />
|}<br />
<br />
<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_VER<br />
|98<br />
|0x62<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|'''Transaction is invalid even when 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, 0xb2-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
== Scripts ==<br />
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Obsolete pay-to-pubkey transaction ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key.<br />
This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced.<br />
scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core.<br />
The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. [http://blockexplorer.com/tx/eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29] is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; [[P2Pool]] does this with the share chain hash txout in the coinbase of blocks it creates.<br />
<br />
=== Anyone-Can-Spend Outputs ===<br />
<br />
Conversely a transaction can be made spendable by anyone at all:<br />
<br />
scriptPubKey: (empty)<br />
scriptSig: OP_TRUE<br />
<br />
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.<br />
<br />
Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
== External Links ==<br />
*[https://www.cs.princeton.edu/~tongbinw/bitcoinIDE/build/editor.html Bitcoin IDE]: Bitcoin Script for dummies<br />
*[https://webbtc.com/script Bitcoin Debug Script Execution]<br />
*[http://www.crmarsh.com/script-playground/ Script Playground] — convert Script to JavaScript<br />
<sup>(cf. "[http://bitcoin.stackexchange.com/q/42576/4334 Online Bitcoin Script simulator or debugger?]")</sup><br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]<br />
<br />
{{Bitcoin Core documentation}}</div>Dionyzizhttps://tests.bitcoin.it/w/index.php?title=Target&diff=59996Target2016-01-15T01:47:25Z<p>Dionyziz: rm dead link</p>
<hr />
<div>See also [[Difficulty]]<br />
<br />
The '''target''' is a 256-bit number (extremely large) that all Bitcoin clients share. The SHA-256 [[hash]] of a [[block]]'s header must be lower 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 realize that block generation is not a long, set problem (like doing a million hashes), but more like a lottery. Each hash basically gives you a random number between 0 and the maximum value of a 256-bit number (which is huge). If your hash is below the target, then you win. If not, you increment the nonce (completely changing the hash) and try again. <br />
<br />
For reasons of stability and low latency in transactions, the network tries to produce one block every 10 minutes. Every 2016 blocks (which should take two weeks if this goal is kept perfectly), every Bitcoin client compares the actual time it took to generate these blocks with the two week goal and modifies the target by the percentage difference. This makes the proof-of-work problem more or less difficult. A single retarget never changes the target by more than a factor of 4 either way to prevent large changes in difficulty.<br />
<br />
=== What is the target now? === <br />
* [http://blockexplorer.com/q/getdifficulty Current difficulty], as output by Bitcoin's getDifficulty<br />
<br />
=== When does the target change next? ===<br />
<br />
* [http://blockexplorer.com/q/nextretarget Next retarget]<br />
<br />
=== What has the target been in the past? ===<br />
<br />
* [http://blockexplorer.com/q/nethash Difficulty history, (at column 5)]<br />
* [http://www.bitcointalk.org/index.php?topic=2345.msg31405#msg31405 Re: difficulty over time data?]<br />
* [http://bitcoin.sipa.be/ Bitcoin network graphs] <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 />
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 />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Dionyzizhttps://tests.bitcoin.it/w/index.php?title=Controlled_supply&diff=59994Controlled supply2016-01-15T00:11:24Z<p>Dionyziz: Fix finite supply denominator to be 10^8 instead of the incorrect 10^7</p>
<hr />
<div><blockquote>A fixed money supply, or a supply altered only in accord with objective and calculable criteria, is a necessary condition to a meaningful just price of money.<ref>[https://www.scribd.com/doc/138347161/Bernard-W-Dempsey-1903-1960-Interest-and-Usury-With-an-Introduction-by-Joseph-a-Schumpeter-1948#page220 <i>Interest and Usury</i> p. 220] by [https://www.jstor.org/stable/29769582 Fr. Bernard W. Dempsey, S.J.] (1903-1960); cf. John Horvat II [http://returntoorder.org/ <i>Return to Order</i>] ch. 37 "The Backing of Money"</ref><br />
<p align="right">—[https://www.jstor.org/stable/29769582 Fr. Bernard W. Dempsey, S.J.] (1903-1960)</p></blockquote><br />
<br />
In a centralized economy, currency is issued by a central bank at a rate that is supposed to match the growth of the amount of goods that are exchanged so that these goods can be traded with stable prices. The <br />
[[wikipedia:monetary base|monetary base]] is controlled by a central bank. In the United States, the [[wikipedia:Federal Reserve System|Fed]] increases the monetary base by issuing currency, increasing the amount banks have on reserve, and more recently, printing money electronically in a process called [[wikipedia:Quantitative Easing|Quantitative Easing]].<br />
<br />
In a fully decentralized monetary system, there is no central authority that regulates the monetary base. Instead, currency is created by the nodes of a peer-to-peer network. The Bitcoin generation algorithm defines, in advance, how currency will be created and at what rate. Any currency that is generated by a malicious user that does not follow the rules will be rejected by the network and thus is worthless.<br />
<br />
==Currency with Finite Supply==<br />
[[Image:Controlled supply-block reward halving.png|160px|thumb|right| Block reward halving]]<br />
[[Image:Controlled supply-supply over block height.png|160px|thumb|right| Controlled supply]]<br />
Bitcoins are created each time a user discovers a new [[block]]. <br />
The rate of block creation is adjusted every 2016 blocks to aim for a constant two week adjustment period (equivalent to 6 per hour.) The number of bitcoins generated per block is set to decrease geometrically, with a 50% reduction every 210,000 blocks, or approximately four years. The result is that the number of bitcoins in existence is not expected to exceed 21 million.<ref>[http://www.bitcointalk.org/index.php?topic=3366.msg47522#msg47522 21 million cap]</ref> Speculated justifications for the unintuitive value "21 million" are that it matches a 4-year reward halving schedule; or the ultimate total number of Satoshis that will be mined is close to the maximum capacity of a 64-bit floating point number. Satoshi has never really justified or explained many of these constants.<br />
<br />
[[File:ControlledSupply.png]]<br />
<br />
This decreasing-supply algorithm was chosen because it approximates the rate at which commodities like gold are mined. Users who use their computers to perform calculations to try and discover a block are thus called [[Mining|''Miners'']].<br />
<br />
==Projected Bitcoins Short Term ==<br />
This chart shows the number of bitcoins that will exist in the near future. The ''Year'' is a forecast and may be slightly off.<br />
{| class="wikitable"<br />
|-<br />
! Date reached!!Block!!Reward Era!! BTC/block!! Year (estimate)!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit<br />
|-<br />
|2009-01-03||0||1||50.00||2009||0||2625000||2625000||infinite||12.500%<br />
|-<br />
|2010-04-22||52500||1||50.00||2010||2625000||2625000||5250000||100.00%||25.000%<br />
|-<br />
|2011-01-28||105000||1||50.00||2011*||5250000||2625000||7875000||50.00%||37.500%<br />
|-<br />
|2011-12-14||157500||1||50.00||2012||7875000||2625000||10500000||33.33%||50.000%<br />
|-<br />
|[[Halving day 2012|2012-11-28]]||210000||2||25.00||2013||10500000||1312500||11812500||12.50%||56.250%<br />
|-<br />
|2013-10-09||262500||2||25.00||2014||11812500||1312500||13125000||11.11%||62.500%<br />
|-<br />
|2014-08-11||315000||2||25.00||2015||13125000||1312500||14437500||10.00%||68.750%<br />
|-<br />
|2015-07-29||367500||2||25.00||2016||14437500||1312500||15750000||9.09%||75.000%<br />
|-<br />
|||420000||3||12.50||2017||15750000||656250||16406250||4.17%||78.125%<br />
|-<br />
|||472500||3||12.50||2018||16406250||656250||17062500||4.00%||81.250%<br />
|-<br />
|||525000||3||12.50||2019||17062500||656250||17718750||3.85%||84.375%<br />
|-<br />
|||577500||3||12.50||2020||17718750||656250||18375000||3.70%||87.500%<br />
|-<br />
|||630000||4||6.25||2021||18375000||328125||18703125||1.79%||89.063%<br />
|-<br />
|||682500||4||6.25||2022||18703125||328125||19031250||1.75%||90.625%<br />
|-<br />
|||735000||4||6.25||2023||19031250||328125||19359375||1.72%||92.188%<br />
|-<br />
|||787500||4||6.25||2024||19359375||328125||19687500||1.69%||93.750%<br />
|}<br />
''* In Block 124724, user midnightmagic mined a solo block to himself which underpaid the reward by a single Satoshi and simultaneously destroyed the block's fees. This the the only known reduction in the total mined supply of Bitcoin. Therefore, from block 124724 onwards, all total supply estimates must technically be reduced by 1 Satoshi.<br />
<br />
==Projected Bitcoins Long Term ==<br />
[[Image:Controlled supply-timeline estimation.png|160px|thumb|right| Supply timeline estimation]]<br />
Because the number of bitcoins created each time a user discovers a new block - the block reward - is halved based on a fixed interval of blocks, and the time it takes on average to discover a block can vary based on [[mining]] power and the network [[difficulty]], the exact time when the block reward is halved can vary as well. Consequently, the time the last Bitcoin will be created will also vary, and is subject to speculation based on assumptions.<br />
<br />
If the mining power had remained constant since the first Bitcoin was mined, the last Bitcoin would have been mined somewhere near October 8th, 2140. Due to the mining power having increased overall over time, as of block 367,500 - assuming mining power remained constant from that block forward - the last Bitcoin will be mined on May 7th, 2140.<br />
<br />
As it is very difficult to predict how mining power will evolve into the future - i.e. whether technological progress will continue to make hardware faster or whether mining will hit a a technological wall; or whether or not faster methods of SHA2 calculation will be discovered - putting an exact date or even year on this event is difficult.<br />
<br />
The total number of bitcoins, as mentioned earlier, has an asymptote at 21 million, due to a technical limitation in the data structure of the blockchain - specifically the integer storage type of the [[Transaction#general_format_.28inside_a_block.29_of_each_output_of_a_transaction_-_Txout|transaction output]], this exact value would have been 20,999,999.9769 bitcoin. Should this technical limitation be adjusted by changing the width of the field, the total number will still only approach or be a maximum of 21 million.<br />
<br />
{| class="wikitable" style="text-align:right"<br />
|-<br />
! Block!!Reward Era!! BTC/block!! Start BTC!! BTC Added!! End BTC!! BTC Increase|| End BTC % of Limit<br />
|-<br />
| 0|| 1|| 50.00000000|| 0.00000000|| 10500000.00000000|| 10500000.00000000*|| infinite|| 50.00000006%<br />
|-<br />
| 210000|| 2|| 25.00000000|| 10500000.00000000|| 5250000.00000000|| 15750000.00000000|| 50.00000000%|| 75.00000008%<br />
|-<br />
| 420000|| 3|| 12.50000000|| 15750000.00000000|| 2625000.00000000|| 18375000.00000000|| 16.66666667%|| 87.50000010%<br />
|-<br />
| 630000|| 4|| 6.25000000|| 18375000.00000000|| 1312500.00000000|| 19687500.00000000|| 7.14285714%|| 93.75000010%<br />
|-<br />
| 840000|| 5|| 3.12500000|| 19687500.00000000|| 656250.00000000|| 20343750.00000000|| 3.33333333%|| 96.87500011%<br />
|-<br />
| 1050000|| 6|| 1.56250000|| 20343750.00000000|| 328125.00000000|| 20671875.00000000|| 1.61290323%|| 98.43750011%<br />
|-<br />
| 1260000|| 7|| 0.78125000|| 20671875.00000000|| 164062.50000000|| 20835937.50000000|| 0.79365079%|| 99.21875011%<br />
|-<br />
| 1470000|| 8|| 0.39062500|| 20835937.50000000|| 82031.25000000|| 20917968.75000000|| 0.39370079%|| 99.60937511%<br />
|-<br />
| 1680000|| 9|| 0.19531250|| 20917968.75000000|| 41015.62500000|| 20958984.37500000|| 0.19607843%|| 99.80468761%<br />
|-<br />
| 1890000|| 10|| 0.09765625|| 20958984.37500000|| 20507.81250000|| 20979492.18750000|| 0.09784736%|| 99.90234386%<br />
|-<br />
| 2100000|| 11|| 0.04882812|| 20979492.18750000|| 10253.90520000|| 20989746.09270000|| 0.04887585%|| 99.95117198%<br />
|-<br />
| 2310000|| 12|| 0.02441406|| 20989746.09270000|| 5126.95260000|| 20994873.04530000|| 0.02442599%|| 99.97558604%<br />
|-<br />
| 2520000|| 13|| 0.01220703|| 20994873.04530000|| 2563.47630000|| 20997436.52160000|| 0.01221001%|| 99.98779307%<br />
|-<br />
| 2730000|| 14|| 0.00610351|| 20997436.52160000|| 1281.73710000|| 20998718.25870000|| 0.00610426%|| 99.99389658%<br />
|-<br />
| 2940000|| 15|| 0.00305175|| 20998718.25870000|| 640.86750000|| 20999359.12620000|| 0.00305194%|| 99.99694833%<br />
|-<br />
| 3150000|| 16|| 0.00152587|| 20999359.12620000|| 320.43270000|| 20999679.55890000|| 0.00152592%|| 99.99847420%<br />
|-<br />
| 3360000|| 17|| 0.00076293|| 20999679.55890000|| 160.21530000|| 20999839.77420000|| 0.00076294%|| 99.99923713%<br />
|-<br />
| 3570000|| 18|| 0.00038146|| 20999839.77420000|| 80.10660000|| 20999919.88080000|| 0.00038146%|| 99.99961859%<br />
|-<br />
| 3780000|| 19|| 0.00019073|| 20999919.88080000|| 40.05330000|| 20999959.93410000|| 0.00019073%|| 99.99980932%<br />
|-<br />
| 3990000|| 20|| 0.00009536|| 20999959.93410000|| 20.02560000|| 20999979.95970000|| 0.00009536%|| 99.99990468%<br />
|-<br />
| 4200000|| 21|| 0.00004768|| 20999979.95970000|| 10.01280000|| 20999989.97250000|| 0.00004768%|| 99.99995236%<br />
|-<br />
| 4410000|| 22|| 0.00002384|| 20999989.97250000|| 5.00640000|| 20999994.97890000|| 0.00002384%|| 99.99997620%<br />
|-<br />
| 4620000|| 23|| 0.00001192|| 20999994.97890000|| 2.50320000|| 20999997.48210000|| 0.00001192%|| 99.99998812%<br />
|-<br />
| 4830000|| 24|| 0.00000596|| 20999997.48210000|| 1.25160000|| 20999998.73370000|| 0.00000596%|| 99.99999408%<br />
|-<br />
| 5040000|| 25|| 0.00000298|| 20999998.73370000|| 0.62580000|| 20999999.35950000|| 0.00000298%|| 99.99999706%<br />
|-<br />
| 5250000|| 26|| 0.00000149|| 20999999.35950000|| 0.31290000|| 20999999.67240000|| 0.00000149%|| 99.99999855%<br />
|-<br />
| 5460000|| 27|| 0.00000074|| 20999999.67240000|| 0.15540000|| 20999999.82780000|| 0.00000074%|| 99.99999929%<br />
|-<br />
| 5670000|| 28|| 0.00000037|| 20999999.82780000|| 0.07770000|| 20999999.90550000|| 0.00000037%|| 99.99999966%<br />
|-<br />
| 5880000|| 29|| 0.00000018|| 20999999.90550000|| 0.03780000|| 20999999.94330000|| 0.00000018%|| 99.99999984%<br />
|-<br />
| 6090000|| 30|| 0.00000009|| 20999999.94330000|| 0.01890000|| 20999999.96220000|| 0.00000009%|| 99.99999993%<br />
|-<br />
| 6300000|| 31|| 0.00000004|| 20999999.96220000|| 0.00840000|| 20999999.97060000|| 0.00000004%|| 99.99999997%<br />
|-<br />
| 6510000|| 32|| 0.00000002|| 20999999.97060000|| 0.00420000|| 20999999.97480000|| 0.00000002%|| 99.99999999%<br />
|-<br />
| 6720000|| 33|| 0.00000001|| 20999999.97480000|| 0.00210000|| 20999999.97690000|| 0.00000001%|| 100.00000000%<br />
|-<br />
| 6930000|| 34|| 0.00000000|| 20999999.97690000|| 0.00000000|| 20999999.97690000|| 0.00000000%|| 100.00000000%<br />
|}<br />
''Note: The number of bitcoins are presented in a floating point format. However, these values are based on the number of satoshi per block originally in integer format to prevent compounding error.''<br />
<br />
''* In block 124724, user midnightmagic solo mined a block which caused one less Satoshi to be created than would otherwise have come into existence. Therefore, all calculations from this block onwards must now, to be accurate, include this underpay in total Bitcoins in existence.''<br />
<br />
==Spendable Supply==<br />
The theoretical total number of bitcoins, 21 million, should not be confused with the total spendable supply. The total spendable supply is always lower than the theoretical total supply, and is subject to accidental loss, willful destruction, and technical peculiarities.<br />
<br />
One way to see a part of the destruction of coin is by collecting a sum of all unspent transaction outputs, using a [[API reference (JSON-RPC)|Bitcoin RPC]] command <code>gettxoutsetinfo</code>. The ''total_amount'' value returned is the sum of all outputs that the client deems technically spendable but not currently spent. Note however that this does not take into account outputs that are exceedingly unlikely to be spent as is the case in loss and destruction via constructed addresses, for example.<br />
===Miner Underpay===<br />
<br />
The algorithm which decides whether a block is valid only checks to verify whether the total amount of the reward '''exceeds''' the reward plus available fees. Therefore it is possible for a miner to deliberately choose to underpay himself by any value: not only can this destroy the fees involved, but also the reward itself, which can prevent the total possible bitcoins that can come into existence from reaching its theoretical meximum. This is a form of underpay which the reference implementation recognises as impossible to spend. Some of the other types below are not recognised as officially destroying Bitcoins; it is possible for example to spend the 1BitcoinEaterAddressDontSendf59kuE if a corresponding private key is used (although this would imply that Bitcoin has been broken.)<br />
<br />
===Loss of bitcoin===<br />
Bitcoins may be lost if the conditions required to spend them are no longer known. For example, if you made a transaction to an [[address]] that requires a private key in order to spend those bitcoins further, had written that private key down on a piece of paper, but that piece of paper was lost. In this case, that bitcoin may also be considered lost, as the odds of randomly finding a matching private key are such that it is generally considered impossible.<br />
<br />
===Willful destruction of bitcoin===<br />
Bitcoins may also be willfully 'destroyed' - for example by attaching conditions that make it impossible to spend them.<br />
<br />
A common method is to send bitcoin to an address that was constructed and only made to pass validity checks, but for which no private key is actually known. An example of such an address is "1BitcoinEaterAddressDontSendf59kuE", where the last "f59kuE" is text to make the preceding constructed text pass validation. Finding a matching private key is, again, generally considered impossible. For an example of how difficult this would be, see [[Vanitygen#Use_of_vanitygen_to_try_to_attack_addresses|Vanitygen]].<br />
<br />
Another common method is to send bitcoin in a transaction where the conditions for spending are not just unfathomably unlikely, but literally impossible to meet. For example, a transaction that is made [[Script#Provably_Unspendable.2FPrunable_Outputs|provably unspendable using OP_RETURN]], or uses script operations that requires the user to prove that 1+1 equals 3.<br />
<br />
A lesser known method is to send bitcoin to an address based on private key that is outside the [[Private_key#Range_of_valid_ECDSA_private_keys|range of valid ECDSA private keys]]. For example, the address 16QaFeudRUt8NYy2yzjm3BMvG4xBbAsBFM has a known matching private key of value 0 (zero), which is outside the valid range.<br />
<br />
===Technical peculiarities preventing spending of bitcoin===<br />
There are also technical peculiarities that prevent the spending of some bitcoin.<br />
<br />
The first {{btc}}50, included in the [[genesis block]], cannot be spent as its transaction is not in the global database.<br />
<br />
In older versions of the bitcoin reference code, a miner could make their coinbase transaction (block reward) have the exact same ID as used in a previous block<ref>https://github.com/bitcoin/bitcoin/issues/612</ref>. This effectively caused the previous block reward to become unspendable. Two known such cases<ref>{{cite tx|e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468|used in blocks 91722 and 91880}}</ref><ref>{{cite tx|d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599|used in blocks 91812 and 91842</ref> are left as special cases in the code<ref>https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514</ref> as part of [[BIP 0030]] changes that fixed this issue. These transactions were {{btc}}50 each.<br />
<br />
==Money Supply==<br />
While the number of bitcoins in existence will never exceed 21 million, the [[wikipedia:money supply|money supply]] of bitcoins can exceed 21 million due to [[wikipedia:Fractional-reserve Banking|Fractional-reserve Banking]]<sup>[How?]</sup>.<br />
<br />
==Deflation==<br />
<br />
Because the monetary base of bitcoins cannot be expanded, the currency would be subject to severe deflation if it becomes widely used. <br />
Keynesian economists argue that [[Deflationary spiral|deflation]] is bad for an economy because it incentivises individuals and businesses to save money rather than invest in businesses and create jobs. The [[wikipedia:Austrian school|Austrian school]] of thought counters this criticism, claiming that as deflation occurs in all stages of production, entrepreneurs who invest benefit from it. As a result, profit ratios tend to stay the same and only their magnitudes change. In other words, in a deflationary environment, goods and services decrease in price, but at the same time the cost for the production of these goods and services tend to decrease proportionally, effectively not affecting profits. Price deflation encourages an increase in hoarding &mdash; hence savings &mdash; which in turn tends to lower interest rates and increase the incentive for entrepreneurs to invest in projects of longer term.<br />
<br />
==See also==<br />
<br />
* [http://www.econlib.org/library/Columns/y2006/Friedmantranscript.html Milton Friedman interview], where he proposed to replace the central bank with a computer, and to fix the money supply growth at 4% annually<br />
* [[Deflationary spiral]]<br />
* [http://blockchain.info/charts/total-bitcoins Chart of total bitcoins in circulation]<br />
* [[Inflation]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[Category:Economics]]</div>Dionyzizhttps://tests.bitcoin.it/w/index.php?title=File:ControlledSupply.png&diff=59993File:ControlledSupply.png2016-01-15T00:10:51Z<p>Dionyziz: This fixes the denominator of File:ControlledSupply.gif to e 10^8 instead of the incorrect 10^7.</p>
<hr />
<div>== Summary ==<br />
This fixes the denominator of [[File:ControlledSupply.gif]] to e 10^8 instead of the incorrect 10^7.<br />
== Licensing ==<br />
{{self|GFDL|cc-by-3.0|migration=redundant}}</div>Dionyzizhttps://tests.bitcoin.it/w/index.php?title=File:87275aa709db7af386964e565781b6c2.png&diff=59992File:87275aa709db7af386964e565781b6c2.png2016-01-15T00:09:29Z<p>Dionyziz: This fixes the denominator of File:ControlledSupply.gif to be 10^8 instead of the incorrect 10^7.</p>
<hr />
<div>== Summary ==<br />
This fixes the denominator of [[File:ControlledSupply.gif]] to be 10^8 instead of the incorrect 10^7.<br />
== Licensing ==<br />
{{self|GFDL|cc-by-3.0|migration=redundant}}</div>Dionyzizhttps://tests.bitcoin.it/w/index.php?title=Bitcoin_Improvement_Proposals&diff=59342Bitcoin Improvement Proposals2015-11-12T17:22:48Z<p>Dionyziz: Replace broken sourceforge mailing list link with linuxfoundation.org link</p>
<hr />
<div>A '''Bitcoin Improvement Proposal''' ('''BIP''') is a design document for introducing features or information to Bitcoin. This is the standard way of communicating ideas since Bitcoin has no formal structure.<br />
<br />
The first BIP ([[BIP 0001]]) was submitted by Amir Taaki on 2011-08-19 and described what a BIP is.<br />
<br />
= BIP Types =<br />
There are three types of BIPs:<br />
* '''Standards Track BIPs''' - Changes to the network protocol, block or transaction validation, or anything affecting interoperability.<br />
* '''Informational BIPs''' - Design issues, general guidelines. This type of BIP is NOT for proposing new features and do not represent community consensus<br />
* '''Process BIPs''' - Describes or proposes a change in process. Similar to Standards BIPs but apply outside the Bitcoin protocol.<br />
<br />
= BIP Workflow =<br />
As described in [[BIP 0001]] the workflow of a BIP is as follows:<br />
<br />
[[File:BIP Workflow.png]]<br />
<br />
= List of BIPs =<br />
{{BipMoved|README.mediawiki|README}}<br />
<br />
People wishing to submit BIPs, first should propose their idea or document to [https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev the mailing list]. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here.<br />
<br />
We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.<br />
<br />
Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.<br />
<br />
Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: [[economic majority]]).<br />
<br />
<!-- Mostly generated by:<br />
perl -e 'while(<>){ s/bip-(\d+)\.mediawiki/BIP $1/; if (m/^\|\-\s*(style=".*")?$/) { print $a; $a = ""; } $a .= $_; if (m/^\| (Active|Accepted|Final)/) { $a=~s/^(\|\-)\s*(style=".*")?$/$1 style="background-color: #cfffcf"/m; } elsif(m/^\| (Withdrawn|Deferred|Replaced)/){$a=~s/^(\|\-)\s*(style=".*")?$/$1 style="background-color: #ffcfcf"/m; } }; print $a' README.mediawiki<br />
--><br />
{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"<br />
!Number<br />
!Title<br />
!Owner<br />
!Type<br />
!Status<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0001|1]]<br />
| BIP Purpose and Guidelines<br />
| Amir Taaki<br />
| Standard<br />
| Active<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0010|10]]<br />
| Multi-Sig Transaction Distribution<br />
| Alan Reiner<br />
| Informational<br />
| Withdrawn<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0011|11]]<br />
| M-of-N Standard Transactions<br />
| Gavin Andresen<br />
| Standard<br />
| Accepted<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0012|12]]<br />
| OP_EVAL<br />
| Gavin Andresen<br />
| Standard<br />
| Withdrawn<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0013|13]]<br />
| Address Format for pay-to-script-hash<br />
| Gavin Andresen<br />
| Standard<br />
| Final<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0014|14]]<br />
| Protocol Version and User Agent<br />
| Amir Taaki, Patrick Strateman<br />
| Standard<br />
| Accepted<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0015|15]]<br />
| Aliases<br />
| Amir Taaki<br />
| Standard<br />
| Deferred<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0016|16]]<br />
| Pay To Script Hash<br />
| Gavin Andresen<br />
| Standard<br />
| Final<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0017|17]]<br />
| OP_CHECKHASHVERIFY (CHV)<br />
| Luke Dashjr<br />
| Standard<br />
| Withdrawn<br />
|-<br />
| [[BIP 0018|18]]<br />
| hashScriptCheck<br />
| Luke Dashjr<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0019|19]]<br />
| M-of-N Standard Transactions (Low SigOp)<br />
| Luke Dashjr<br />
| Standard<br />
| Draft<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0020|20]]<br />
| URI Scheme<br />
| Luke Dashjr<br />
| Standard<br />
| Replaced<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0021|21]]<br />
| URI Scheme<br />
| Nils Schneider, Matt Corallo<br />
| Standard<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0022|22]]<br />
| getblocktemplate - Fundamentals<br />
| Luke Dashjr<br />
| Standard<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0023|23]]<br />
| getblocktemplate - Pooled Mining<br />
| Luke Dashjr<br />
| Standard<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0030|30]]<br />
| Duplicate transactions<br />
| Pieter Wuille<br />
| Standard<br />
| Final<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0031|31]]<br />
| Pong message<br />
| Mike Hearn<br />
| Standard<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0032|32]]<br />
| Hierarchical Deterministic Wallets<br />
| Pieter Wuille<br />
| Informational<br />
| Accepted<br />
|-<br />
| [[BIP 0033|33]]<br />
| Stratized Nodes<br />
| Amir Taaki<br />
| Standard<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0034|34]]<br />
| Block v2, Height in coinbase<br />
| Gavin Andresen<br />
| Standard<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0035|35]]<br />
| mempool message<br />
| Jeff Garzik<br />
| Standard<br />
| Accepted<br />
|-<br />
| [[BIP 0036|36]]<br />
| Custom Services<br />
| Stefan Thomas<br />
| Standard<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0037|37]]<br />
| Bloom filtering<br />
| Mike Hearn and Matt Corallo<br />
| Standard<br />
| Accepted<br />
|-<br />
| [[BIP 0038|38]]<br />
| Passphrase-protected private key<br />
| Mike Caldwell<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0039|39]]<br />
| Mnemonic code for generating deterministic keys<br />
| Slush<br />
| Standard<br />
| Draft<br />
|-<br />
| 40<br />
| Stratum wire protocol<br />
| Slush<br />
| Standard<br />
| BIP number allocated<br />
|-<br />
| 41<br />
| Stratum mining protocol<br />
| Slush<br />
| Standard<br />
| BIP number allocated<br />
|-<br />
| [[BIP 0042|42]]<br />
| A finite monetary supply for Bitcoin<br />
| Pieter Wuille<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0043|43]]<br />
| Purpose Field for Deterministic Wallets<br />
| Slush<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0044|44]]<br />
| Multi-Account Hierarchy for Deterministic Wallets<br />
| Slush<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0045|45]]<br />
| Structure for Deterministic P2SH Multisignature Wallets<br />
| Manuel Araoz<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0047|47]]<br />
| Reusable Payment Codes for Hierarchical Deterministic Wallets<br />
| Justus Ranvier<br />
| Informational<br />
| Draft<br />
|-<br />
| [[BIP 0050|50]]<br />
| March 2013 Chain Fork Post-Mortem<br />
| Gavin Andresen<br />
| Informational<br />
| Draft<br />
<!-- 50 series reserved for a group of post-mortems --><br />
|-<br />
| [[BIP 0060|60]]<br />
| Fixed Length "version" Message (Relay-Transactions Field)<br />
| Amir Taaki<br />
| Standard<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0061|61]]<br />
| "reject" P2P message<br />
| Gavin Andresen<br />
| Standard<br />
| Final<br />
|-<br />
| [[BIP 0062|62]]<br />
| Dealing with malleability<br />
| Pieter Wuille<br />
| Standard<br />
| Draft<br />
|-<br />
| 63<br />
| Stealth Addresses<br />
| Peter Todd<br />
| Standard<br />
| BIP number allocated<br />
|-<br />
| [[BIP 0064|64]]<br />
| getutxos message<br />
| Mike Hearn<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0065|65]]<br />
| OP_CHECKLOCKTIMEVERIFY<br />
| Peter Todd<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0066|66]]<br />
| Strict DER signatures<br />
| Pieter Wuille<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0067|67]]<br />
| Deterministic P2SH multi-signature addresses<br />
| Thomas Kerin<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0068|68]]<br />
| Consensus-enforced transaction replacement signalled via sequence numbers<br />
| Mark Friedenbach<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0069|69]]<br />
| Lexicographical Indexing of Transaction Inputs and Outputs<br />
| Kristov Atlas<br />
| Standard<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0070|70]]<br />
| Payment protocol<br />
| Gavin Andresen<br />
| Standard<br />
| Final<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0071|71]]<br />
| Payment protocol MIME types<br />
| Gavin Andresen<br />
| Standard<br />
| Final<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0072|72]]<br />
| Payment protocol URIs<br />
| Gavin Andresen<br />
| Standard<br />
| Final<br />
|-<br />
| [[BIP 0073|73]]<br />
| Use "Accept" header with Payment Request URLs<br />
| Stephen Pair<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0099|99]]<br />
| Motivation and deployment of consensus rule changes ([soft/hard]forks)<br />
| Jorge Timón<br />
| Process<br />
| Draft<br />
|-<br />
| [[BIP 0100|100]]<br />
| Floating block size hard limit<br />
| Jeff Garzik<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0101|101]]<br />
| Increase maximum block size<br />
| Gavin Andresen<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0102|102]]<br />
| Block size increase to 2MB<br />
| Jeff Garzik<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0103|103]]<br />
| Block size following technological growth<br />
| Pieter Wuille<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0105|105]]<br />
| Consensus based block size retargeting algorithm<br />
| BtcDrak<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0106|106]]<br />
| Dynamically Controlled Bitcoin Block Size Max Cap<br />
| Upal Chakraborty<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0111|111]]<br />
| NODE_BLOOM service bit<br />
| Matt Corallo and Peter Todd<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0112|112]]<br />
| CHECKSEQUENCEVERIFY<br />
| BtcDrak and Mark Friedenbach<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0113|113]]<br />
| Median time-past as endpoint for lock-time calculations<br />
| Thomas Kerin and Mark Friedenbach<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0120|120]]<br />
| Proof of Payment<br />
| Kalle Rosenbaum<br />
| Standard<br />
| Draft<br />
|-<br />
| [[BIP 0121|121]]<br />
| Proof of Payment URI scheme<br />
| Kalle Rosenbaum<br />
| Standard<br />
| Draft<br />
|}<br />
<br />
<!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! --><br />
<br />
[[Hardfork Wishlist]]<br />
<br />
[[Category:BIP|Z]]<br />
<br />
[[es:Propuestas de mejora de Bitcoin]]</div>Dionyzizhttps://tests.bitcoin.it/w/index.php?title=User:Dionyziz&diff=50673User:Dionyziz2014-09-01T22:08:40Z<p>Dionyziz: </p>
<hr />
<div>[https://dionyziz.com dionyziz]</div>Dionyzizhttps://tests.bitcoin.it/w/index.php?title=User:Dionyziz&diff=50672User:Dionyziz2014-09-01T22:08:17Z<p>Dionyziz: Created page with "#REDIRECT [https://en.wikipedia.org/wiki/User:Dionyziz]"</p>
<hr />
<div>#REDIRECT [https://en.wikipedia.org/wiki/User:Dionyziz]</div>Dionyzizhttps://tests.bitcoin.it/w/index.php?title=Script&diff=50671Script2014-09-01T22:07:10Z<p>Dionyziz: remove outdated information on prunable outputs</p>
<hr />
<div>Bitcoin uses a scripting system for [[transactions]]. [[Wikipedia:FORTH|Forth]]-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.<br />
<br />
A script is essentially a list of instructions recorded with each transaction that describe how the next person wanting to spend the Bitcoins being transferred can gain access to them. The script for a typical Bitcoin transfer to destination Bitcoin address D simply encumbers future spending of the bitcoins with two things: the spender must provide<br />
# a public key that, when hashed, yields destination address D embedded in the script, and<br />
# a signature to show evidence 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, or even no keys at all.<br />
<br />
A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). The party who originally ''sent'' the Bitcoins now being spent, dictates the script operations that will occur ''last'' in order to release them for use in another transaction. The party wanting to spend them must provide the input(s) to the previously recorded script that results in those operations occurring last leaving behind true (non-zero).<br />
<br />
The stacks hold byte vectors.<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 is represented by a null-length vector.<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 />
== Words ==<br />
This is a list of all Script words (commands/functions). Some of the more complicated opcodes are disabled out of concern that the client might have a bug in their implementation; if a transaction using such an opcode were to be included in the chain any fix would risk forking the chain. <br />
<br />
True=1 and False=0.<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 />
|N/A<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 />
|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 />
|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.<br />
|-<br />
|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.<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_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_NOTIF<br />
|100<br />
|0x64<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is 0, the statements are executed. The top stack value is removed.<br />
|-<br />
|OP_ELSE<br />
|103<br />
|0x67<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the preceding OP_IF or OP_NOTIF or OP_ELSE was not executed then these statements are and if the preceding OP_IF or OP_NOTIF or OP_ELSE was executed then these statements are not. <br />
|-<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 OP_IF earlier is also '''invalid'''.<br />
|-<br />
|OP_VERIFY<br />
|105<br />
|0x69<br />
|True / false<br />
|Nothing / False<br />
|'''Marks transaction as invalid''' if top stack value is not true.<br />
|-<br />
|OP_RETURN<br />
|106<br />
|0x6a<br />
|Nothing<br />
|Nothing<br />
|'''Marks transaction as invalid'''. <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_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 />
|Puts the number of stack items onto the stack.<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 />
|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 />
<br />
=== Splice ===<br />
<br />
If any opcode marked as disabled is present in a script, it must abort and fail.<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 />
|style="background:#D97171;"|Concatenates two strings. ''disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''<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 />
If any opcode marked as disabled is present in a script, it must abort and fail.<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 />
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''<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 />
|True / false<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script must abort and fail. <br />
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.<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<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''disabled.''<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 />
|style="background:#D97171;"|a is multiplied by b. ''disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''<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 />
|out<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 />
=== Crypto ===<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 />
|True / false<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 />
|For each signature and public key pair, OP_CHECKSIG is executed. If more public keys than signatures are listed, some key/sig pairs can fail. All signatures need to match a public key. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|True / False<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<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_VER<br />
|98<br />
|0x62<br />
|'''Transaction is invalid''' unless occuring in an unexecuted OP_IF branch<br />
|-<br />
|OP_VERIF<br />
|101<br />
|0x65<br />
|'''Transaction is invalid even when occuring in an unexecuted OP_IF branch'''<br />
|-<br />
|OP_VERNOTIF<br />
|102<br />
|0x66<br />
|'''Transaction is invalid even when 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_NOP10<br />
|176-185<br />
|0xb0-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
== Scripts ==<br />
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Obsolete pay-to-pubkey transaction ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key.<br />
This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced.<br />
scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core.<br />
The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. [http://blockexplorer.com/tx/eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29] is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; [[P2Pool]] does this with the share chain hash txout in the coinbase of blocks it creates.<br />
<br />
=== Anyone-Can-Spend Outputs ===<br />
<br />
Conversely a transaction can be made spendable by anyone at all:<br />
<br />
scriptPubKey: (empty)<br />
scriptSig: OP_TRUE<br />
<br />
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.<br />
<br />
Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]</div>Dionyzizhttps://tests.bitcoin.it/w/index.php?title=Help:Introduction&diff=8232Help:Introduction2011-05-10T18:34:07Z<p>Dionyziz: typo</p>
<hr />
<div>Alice is far away from Bob and wants to buy his [http://www.grasshillalpacas.com/alpacaproductsforbitcoinoffer.html Alpaca socks]. In return, she wants to send him a dollar. A dollar bill is a piece of paper which is very easy to create (by those who can), but which is accepted by people in exchange for valuable products and services in the real world, such as the socks Alice wants to buy. One simple thing Alice can do is to put a dollar bill in an envelope, mail it to Bob, and then wait for Bob to send the socks to her.<br />
<br />
Another thing Alice can do is to "wire" the money to Bob. She can do that by first giving her dollar bills to an institution called a bank, the job of which is to safe-keep Alice's dollar bills and, in return, to give Alice a written promise (called a "bank statement") that, whenever she wishes, she can come to the bank to take back the same number of dollar bills that she deposited. Since the money is still Alice's, she is entitled to do with it whatever she pleases, and the bank (like most banks), for a small fee, will do Alice the service of "giving" the dollar bills to Bob instead of her. This could be done by sending a person to Bob's door, with Alice's dollar bills in hand (or, better, fresh new dollar bills, if Alice's dollar bills are in bad condition), but usually it is done by Alice's bank by giving the dollar bills to Bob's bank and informing them that the money is for Bob, who will then see the amount in his next statement, or, if he is in a hurry, the next time he contacts his bank asking about how much money they have for him.<br />
<br />
Since banks have many customers, and bank employees require money for doing the job of talking to people and signing documents, banks in recent times have been using machines such as ATMs and web servers, that do the job of interacting with customers instead of paid bank employees. The job of these machines is to learn what each customer wants to do with his/her money and, to the extent that it's possible, act on what the customer wants (for example, ATMs can hand cash). In the end, there is very little human involvement in this process, most of the time. The people can always know how much money out of the money that the bank is safe-keeping is theirs, and they are confident that the numbers they see in their bank statements and on their computer screens stand for the number of dollar bills that they can get from the bank at any time they wish. They can be so sure of that, that they can accept those numbers in the same way they accept paper dollars (this is similar to the way people started accepting paper dollars as they accepted gold or silver).<br />
<br />
However, the fact that machines are used does not change the structure of this system, which is, as it was, based on a central authority (the bank) which is responsible for keeping records about how much money belongs to whom. Everybody has to rely on this central authority to be honest (i.e. to say the truth about how much money they are safe-keeping in total, or at least to make the paper money available upon demand from the owners). Also, every person has to identify him/herself to this authority, by giving his/her real name, in order to be allowed to get their paper bills back or to send money to another person.<br />
<br />
Bitcoin is a system of owning and voluntarily transferring amounts of so-called bitcoins, in a manner similar to an on-line banking interface, but anonymously and without reliance on a central authority to decide on what is true. These bitcoins are valuable because they require the spending of real resources (CPU time and electricity) to produce, cannot be spent more than once, and cannot be removed from a person's ownership without illicit access to his/her computer.<br />
<br />
==Preventing stealing==<br />
To guarantee that an eavesdropper, Eve, cannot access other people's bitcoins by creating transactions in their names we use a [[Wikipedia:Public-key_cryptography|public key system]] to make digital signatures. In this system, each person, such as Alice and Bob, has a pair of public and private keys which he/she stores in a safe [[Wallet|wallet]]. Only the user with his secret private key can sign a document, such as the transaction to give some of his bitcoins to somebody else, but any one can validate the signature using the user’s public key.<br />
<br />
* Bob sends his public key to Alice.<br />
* Alice adds Bob’s public key along with the amount she wants to transfer, to the transaction.<br />
* Alice signs the transaction with her secret private key.<br />
<br />
As a result, anyone who knows the public keys of both Alice and Bob can now see that Alice agreed to transfer the amount to Bob, because nobody other than Alice has Alice's private key. Alice would be foolish to give her private key to other people, as this would allow them to sign transactions in her name, removing funds from her balance.<br />
<br />
Later on, when Bob will transfer the same coins to Charley, he will do the same thing: receive from Charley his public key, add a new transaction to the chain of transactions and sign it with his (Bob) private key. But only Bob can do this, because only Bob has the private key which is necessary for signing and which is the only private key to match Bob’s public key that is already in the chain.<br />
<br />
Eve cannot change who the coins belong to by replacing Bob’s public key with her public key, because Alice signed the transfer to Bob using her private key, declaring that the coins which belonged to her now belong to Bob, and Alice's private key is kept secret from Eve. So if Charley accepts that the original coin was in the hands of Alice he will also accept the fact that this coin was later passed to Bob and now Bob is passing this same coin to him.<br />
<br />
==Preventing double-spending==<br />
This is how we guarantee that Alice cannot replicate the coin and use it in more than one transaction (this is the main innovation behind Bitcoin):<br />
<br />
* Details about the [[Transactions|transaction]] are [[Network|sent and forwarded]] to all or as many other computers as possible.<br />
* A constantly growing chain of [[Blocks|blocks]] that contains a record of all transactions is collectively maintained by all computers (each has a full copy).<br />
* To be accepted in the chain, transaction blocks must be valid and must include [[proof of work]] (one block generated by the network every 10 minutes).<br />
* Blocks are chained in a way so that, if any one is modified, all following blocks will have to be recomputed.<br />
* When multiple valid continuations to this chain appear, only the longest such branch is accepted and it is then extended further.<br />
<br />
When Bob sees that his transaction has been included in a block, which has been made part of the single longest and fastest-growing block chain (extended with significant computational effort), he can be confident that the transaction by Alice has been accepted by the computers in the network and will be permanently recorded, preventing Alice from creating a second transaction with the same coin.<br />
<br />
In theory, Alice could attempt to generate spoofed blocks in which her past usage of the same coin does not appear and try to send these blocks to everyone as evidence that the coin is still hers. However, that past transaction, which contains a signature from Alice, has already been announced, has already been distributed to a very large number of computers in the bitcoin network and a block containing it has already been generated by someone (otherwise, the first receiver of the coin would have no confirmation). Since the process of generating a valid block is designed to take a [[Proof_of_work|long time]], Alice will be unable to compete with all these computers in the rate at which she can generate blocks. Bob will receive many more blocks from third persons than Alice alone will ever be able to generate, and some of the newer blocks will contain Alice's previous transaction, telling Bob that Alice has already spent her coin. The only way for Alice to remove her transaction is to create a parallel chain which is longer than the one generated by everybody else and which doesn't contain her transaction, as only the longest chain is accepted. To remain the longest, it also has to grow faster than any other chain, so as to prevent any block generator from adding Alice's transaction to the chain. To do that, Alice has to be in a position to permanently command the majority of the CPU power on the network; something we assume no single person or organization can do. Therefore, as long as the people who control a majority of the CPUs are not cooperating with Alice, her transaction will be permanently recorded and she will be unable to create another transaction with the same coin.<br />
<br />
==Anonymity==<br />
Bitcoin "accounts" do not have people's names on them and do not have to correspond to individuals. Each balance is simply associated with a randomly generated public-private key pair and the money "belongs" to whoever has the private key and can sign transactions with it. The transactions that are signed using those keys also don't have to include names.<br />
<br />
A [[Address|Bitcoin address]] mathematically corresponds to a public key and looks like this:<br />
<br />
:15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC<br />
<br />
Each person can have many such addresses, each with its own balance, and this can make it more difficult to identify which person owns what amount. In order to protect his [[Anonymity|privacy]], Bob can even generate a new public-private key pair for each individual transaction. So David receiving the coin from Charley will not be able to identify who is the second person in the list of transactions (not without asking Charley).<br />
<br />
==Creation of coins==<br />
As we saw, both Bob and Charley need to verify that the original coin from Alice is valid. Alice cannot simply generate coins instantly, out of thin air, because the appearance of a coin is a transaction that needs to be accepted by others.<br />
<br />
According to current software, the way that new coins are slowly introduced is this: every computer that manages to generate a block is allowed to put one transaction there in which it gains 50 BTC, without this amount having to come from somewhere. This amount is an incentive for people to perform the computation work required for block generation. However, it is currently agreed that the reward for generating a block will be reduced to half every 4 years. Meaning that, at some point in the year 2013, the majority of the CPUs will stop accepting blocks in which the generating transaction adds 50BTC to the sum of money, and they will only accept blocks adding half that amount. The same thing will happen in the years 2017, 2021, 2025 and so on, unless different Bitcoin client software has prevailed in the network.<br />
<br />
Since this incentive will eventually diminish, another way for Alice to gain bitcoins when she generates blocks is to accept [[Transaction_fee|transaction fees]]. There is a voluntary transaction fee that can be paid in every transfer of bitcoins, the amount of which is chosen, and paid, by the person who sends the money. This amount is given to the person who generates the "proof-of-work" block in which the transaction appears, which is necessary for the transaction to be accepted. Since Alice is free to include in her block whichever set of transactions she wants, she can choose to include only the transactions with the highest transaction fees. If everybody acts that way, then eventually, and depending on the total number of transactions, a minimum transaction fee will be required for a transaction to appear in the chain of blocks.<br />
<br />
==Putting it all together==<br />
Directly experience the system in action by visiting [http://blockexplorer.com/ Bitcoin Block Explorer].<br />
The site shows you the latest blocks in the block chain. The [[Block_chain|block chain]] contains the agreed history of all transactions that took place in the system.<br />
Note how many blocks were generated in the last hour, should be around 6. Also notice the number of transactions and the total amount transferred in the last hour (last time I checked it was about 64 and 15K.)<br />
This should give you an indication of how active the system is.<br />
<br />
Next, drill into one of these blocks.<br />
Start by noticing that the block's [[hash|hash]] begins with a run of zeros, this is what made making it so difficult.<br />
The computer that generated this block had to run on many ''Nonce'' values (also listed on the block's page) until it found one that generated this run of zeros.<br />
Next notice the line titled ''Previous block'', each block contains the hash of the block that came before it, this is what forms the chain of blocks.<br />
Now notice all the transactions the block contains. The first transaction is the income earned by the computer that generated this block. It includes a fixed amount of coins created out of thin air and possibly fee collected from other transactions in the same block.<br />
<br />
Drill into any of the transactions and you will see how it is made from one or more amounts coming in and out.<br />
The fact that there can be more than one incoming and outgoing amounts, allow the system to join and break amounts in any possible way allowing for any fractional amount needed (usually cents.)<br />
Each incoming amount is a transaction from the past (which you can also drill to) coming from an address of someone<br />
and each outgoing amount is addressed to someone and will be part of a future transaction (which you can also drill too if it also had already taken place.)<br />
<br />
Finally you can drill into any of the [[Address|addresses]] and see what public information is available.<br />
<br />
To get an impression of the amount of activity on the Bitcoin network, you might like to visit the monitoring websites [[Bitcoin Watch]] and [[Bitcoin Monitor]]. The first has general statistics on the amount and size of transactions, while the latter shows a real-time visualization of events on the Bitcoin network.<br />
<br />
''So that all sounds good! How do I help? [[Helping Bitcoin|How to help Bitcoin]]''<br />
<br />
==See Also==<br />
<br />
* [http://www.youtube.com/watch?v=Um63OQz3bjo What is Bitcoin?] video introduction<br />
* Installing Bitcoin [[getting started]] <br />
* [[How bitcoin works]]<br />
* [[Using Bitcoin]]<br />
* A gentle introduction to Bitcoin - [[BitcoinMe]]<br />
* Another introduction, ''The Rebooting Of Money'' podcast is found at [[Bitcoin Money]]</div>Dionyziz