https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Norill&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T22:44:05ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Smart_Property&diff=58029Smart Property2015-07-31T12:43:39Z<p>Norill: i made one</p>
<hr />
<div>'''Smart property''' is property whose ownership is controlled via the Bitcoin block chain, using [[Contracts|contracts]]. Examples could include physical property such as cars, phones or houses. Smart property also includes non-physical property like shares in a company or access rights to a remote computer. Making property smart allows it to be traded with radically less trust. This reduces fraud, mediation fees and allows trades to take place that otherwise would never have happened. For example, it allows strangers to loan you money over the internet taking your smart property as collateral, which should make lending more competitive and thus credit cheaper.<br />
<br />
Smart property was first proposed by Nick Szabo in his 1997 paper, [http://szabo.best.vwh.net/idea.html "The idea of smart contracts"]. This page was written by [mailto:mike@plan99.net Mike Hearn]. Contact him with any questions or ask on the forums.<br />
<br />
==Background==<br />
<br />
Primitive forms of smart property are already common - if you own a car, it probably comes with an immobilizer. Immobilizers augment the physical key with a protocol exchange ensuring only the holders of the correct cryptographic token can activate the engine. They have dramatically reduced car theft, for example, immobilisers are fitted to around 45% of all cars in Australia, but account for only 7% of the cars that are stolen.<br />
<br />
Many other forms of modern property are protected against theft using cryptography, for example, some smartphones will refuse to release certain keys if the correct PIN unlock isn't entered, and cryptography not only renders a stolen device fairly useless but makes it impossible to steal someone's phone number as well.<br />
<br />
Although these are victories for cryptography, the potential of cryptographically activated property has not been fully explored. The private key is usually itself held in a physical container (like a key or SIM card) and can't be easily transferred or manipulated. Smart property changes this, allowing ownership to be intermediated by Bitcoin miners.<br />
<br />
==Theory==<br />
<br />
This section assumes you are familiar with the Bitcoin protocol, and have a good understanding of [[contracts]].<br />
<br />
Let's start with the example of a car. The cars computer requires authentication using an ''ownership key''. The ownership key is a regular Bitcoin ECDSA-256 key. The car starts its life at the factory gate with the public part of a newly created ownership key. A small token amount of Bitcoins are deposited on that key, call the amount T (it could be 0.0001 BTC for example). Additionally the car has a digital certificate from its manufacturer, and an ''identification key'' which has the public part in the certificate. This allows the car to prove things like its existence, age or mileage to third parties.<br />
<br />
When the car is sold, the following protocol is used:<br />
<br />
# The buyer generates a nonce (random number) and asks the seller to send them the car data.<br />
# The seller gives the car that nonce, and the car returns a data structure signed with its identification key. The data contains the nonce, the cars public cert, data about the car, the public key of the current owner, and the transaction+merkle branch which transferred ownership last time. This ensures the buyer knows what they are getting and that it came from the real seller (it's not a replay).<br />
# The seller selects a key to receive the payment, k1, and names their price P.<br />
# The buyer generates a new ownership key, k2.<br />
# The buyer creates a transaction with two inputs and two outputs. The first input signs for P coins. The second input is connected to the output holding T coins for the ownership address. The first output sends P coins to k1 and the second output sends T coins to k2. This transaction is not valid because only the first input can be signed. The buyer passes this partially complete transaction to the seller, who then signs the second input with the car's current ownership key and broadcasts the transaction.<br />
# They wait for some confirmations.<br />
# The buyer presents the car with the Bitcoin transaction, a merkle branch linking it to the block header and then enough block headers to fill in the gap from the cars current ownership transaction. The car sees that the new transaction re-assigns ownership and is further along in the chain than its current one, plus it has enough work piled on top to be sure the tx won't be reversed. It then updates its ownership information. The car does not need to keep a full record of the chain nor all headers, but rather just enough data to be able to connect future block headers to the one it was previously presented with.<br />
<br />
In practice this process would likely be handled using smartphones with NFC hardware -- the act of touching the phone containing the ownership key to the dashboard would start your wallet app in a special mode that knows how to do smart property trades, after inputting the price the buyer and seller would then touch their phones together to finalize the deal. Although the cryptography is complex they would never need to know anything about it. The phone could double as a way to start the car as well.<br />
<br />
==Loans and collateral==<br />
<br />
Being able to trade physical property without fraud risk is useful, but we can add an extra layer to allow for secured low-trust loans. Consider a loan with which to start a small business. Rather than deal with a bank, you decide to allow people from around the world bid on your debt so you can get the best rates. For this to work, the strangers need some assurance that if the loan is not repaid, they get to keep the collateral - yet you still need to be able to use the car to set up the business.<br />
<br />
We can do this by adding ''access keys'' to the ownership key. By signing a message with the ownership key, access keys can be added or removed. Access keys can be temporary in nature. This means that for the duration of the loan, you can re-assign ownership of the vehicle to the creditor whilst keeping an access key for yourself.<br />
<br />
It would be best if the debtor had an assurance that, on repaying his debt, the cars ownership would indeed revert to his control. We can implement this as follows:<br />
<br />
# The creditor generates k1, which is used to receive the loan repayments. The loan size is L.<br />
# The creditor signs Tx1 that has an input/output re-assigning ownership of the car back to the debtor which is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY, and an output for L coins to k1. This transaction is not valid because the loan has not yet been repaid, so the output sums to more value than the inputs. The creditor sends this transaction to the debtor who keeps it.<br />
# As the debtor re-earns the money they spent, they add inputs to Tx1 to increase its value. This doesn't break the signature on the ownership key input/output pair because it was signed with SIGHASH_ANYONECANPAY so is independent of other inputs. They can't adjust the outputs or anything else about the transaction because that would invalidate the ownership input/output (SIGHASH_ALL).<br />
# Once the transaction has enough inputs to sum to L, the debtor broadcasts the transaction, thus repaying their debt and simultaneously retaking ownership of the vehicle.<br />
<br />
Because access keys can be given time limits, if the debtor does not repay the loan by its maturity period his access key expires and the car will no longer start for him. The new owner can now either come and pick it up himself, or if he doesn't want to (eg he is in another country), he can sell it using the low-trust sales protocol described above and collect the money that way.<br />
<br />
Most loans are repaid in multiple installments. The same protocol as above can work in this case by embedding some control data in the extra input/output pair, the ownership key would not change but the signature would cover a command that extends the lifetime of the access key for another month. The vehicle would know how to parse the data out of the transaction.<br />
<br />
==Implementation details==<br />
<br />
For expiring access keys, the device must have a trustable source of time. Some devices like cars and phones keep time by themselves. In other cases where that's not practical for some reason, a secure timestamping service can be used. This is a service that signs a message containing the current time and a nonce. The device generates a nonce, and as part of the activation/switch-on protocol, a network connected device like a smartphone sends the nonce to the timestamping service then hands back the signed message. The block chain itself cannot be used as a source of time because there's no challenge/response aspect - the device has no way of knowing if you've handed it the latest blocks or not. Signing the time with a nonce solves this.<br />
<br />
Smart phones play a key role in smart property because they have the ability to bridge devices without network access to the network, using Bluetooth or NFC radio. For instance, requiring internet access for a smart lock on a house door is too expensive and impractical. However, a lock with an NFC touchpoint that understands how to check block header progression is quite feasible. The only operations needed to implement Bitcoin-linked smart property is hashing, ECDSA and a small amount of storage. Smartcard chips that implement everything required are common and cheap.<br />
<br />
[[Category:Technical]]</div>Norillhttps://tests.bitcoin.it/w/index.php?title=Protocol_documentation&diff=57002Protocol documentation2015-06-17T15:04:49Z<p>Norill: fixed links</p>
<hr />
<div>This page ''describes'' the behavior of the [[Original Bitcoin client|reference client]]. The Bitcoin protocol is specified by the behavior of the reference client, not by this page. In particular, while this page is quite complete in describing the network protocol, it does not attempt to list all of the rules for block or transaction validity.<br />
<br />
Type names used in this documentation are from the C99 standard.<br />
<br />
For protocol used in mining, see [[getblocktemplate]].<br />
<br />
==Common standards==<br />
<br />
=== Hashes ===<br />
<br />
Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).<br />
<br />
Example of double-SHA-256 encoding of string "hello":<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br />
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br />
<br />
For bitcoin addresses (RIPEMD-160) this would give:<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br />
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br />
<br />
=== Merkle Trees ===<br />
<br />
Merkle trees are binary trees of hashes. Merkle trees in bitcoin use a '''double''' SHA-256, the SHA-256 hash of the SHA-256 hash of something.<br />
<br />
If, when forming a row in the tree (other than the root of the tree), it would have an odd number of elements, the final double-hash is duplicated to ensure that the row has an even number of hashes.<br />
<br />
First form the bottom row of the tree with the ordered double-SHA-256 hashes of the byte streams of the transactions in the block.<br />
<br />
Then the row above it consists of half that number of hashes. Each entry is the double-SHA-256 of the 64-byte concatenation of the corresponding two hashes below it in the tree.<br />
<br />
This procedure repeats recursively until we reach a row consisting of just a single double-hash. This is the '''Merkle root''' of the tree.<br />
<br />
For example, imagine a block with three transactions ''a'', ''b'' and ''c''. The Merkle tree is: <br />
<br />
d1 = dhash(a)<br />
d2 = dhash(b)<br />
d3 = dhash(c)<br />
d4 = dhash(c) # a, b, c are 3. that's an odd number, so we take the c twice<br />
<br />
d5 = dhash(d1 concat d2)<br />
d6 = dhash(d3 concat d4)<br />
<br />
d7 = dhash(d5 concat d6)<br />
<br />
where<br />
<br />
dhash(a) = sha256(sha256(a))<br />
<br />
''d7'' is the Merkle root of the 3 transactions in this block.<br />
<br />
Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.<br />
<br />
=== Signatures ===<br />
<br />
Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions. <br />
<br />
For [[ECDSA]] the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br />
<br />
Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.<br />
<br />
Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).<br />
<br />
=== Transaction Verification ===<br />
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.<br />
<br />
Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.<br />
<br />
Each ''output'' determines which Bitcoin address (or other criteria, see [[Script]]) is the recipient of the funds.<br />
<br />
In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.<br />
<br />
A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totalling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.<br />
<br />
The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.<br />
<br />
Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.<br />
<br />
=== Addresses ===<br />
<br />
A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br />
<br />
Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br />
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br />
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br />
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br />
<br />
The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br />
<br />
== Common structures ==<br />
<br />
Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br />
<br />
=== Message structure ===<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br />
|-<br />
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br />
|-<br />
| 4 || length || uint32_t || Length of payload in number of bytes<br />
|-<br />
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))<br />
|-<br />
| ? || payload || uchar[] || The actual data<br />
|}<br />
<br />
<br />
Known magic values:<br />
<br />
{|class="wikitable"<br />
! Network !! Magic value !! Sent over wire as<br />
|-<br />
| main || 0xD9B4BEF9 || F9 BE B4 D9<br />
|-<br />
| testnet || 0xDAB5BFFA || FA BF B5 DA<br />
|-<br />
| testnet3 || 0x0709110B || 0B 11 09 07<br />
|-<br />
| namecoin || 0xFEB4BEF9 || F9 BE B4 FE<br />
|}<br />
<br />
=== Variable length integer ===<br />
<br />
Integer can be encoded depending on the represented value to save space.<br />
Variable length integers always precede an array/vector of a type of data that may vary in length.<br />
Longer numbers are encoded in little endian.<br />
<br />
{|class="wikitable"<br />
! Value !! Storage length !! Format<br />
|-<br />
| < 0xfd || 1 || uint8_t<br />
|-<br />
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t<br />
|-<br />
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t<br />
|-<br />
| - || 9 || 0xff followed by the length as uint64_t<br />
|}<br />
<br />
If you're reading the Satoshi client code (BitcoinQT) it refers to this as a "CompactSize". Modern BitcoinQT has also CVarInt class which implements even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here). CVarInt is not a part of the protocol.<br />
<br />
=== Variable length string ===<br />
<br />
Variable length string can be stored using a variable length integer followed by the string itself.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || length || [[Protocol_documentation#Variable_length_integer|var_int]] || Length of the string<br />
|-<br />
| ? || string || char[] || The string itself (can be empty)<br />
|}<br />
<br />
=== Network address ===<br />
<br />
When a network address is needed somewhere, this structure is used. Network addresses are not prefixed with a timestamp in the version message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || time || uint32 || the Time (version >= 31402). '''Not present in version message.'''<br />
|-<br />
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]<br />
|-<br />
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supported IPv4 and only read the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]<br />
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br />
|-<br />
| 2 || port || uint16_t || port number, network byte order<br />
|}<br />
<br />
Hexdump example of Network address structure<br />
<br />
<pre><br />
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br />
<br />
Network address:<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:a00:1 or IPv4: 10.0.0.1<br />
20 8D - Port 8333<br />
</pre><br />
<br />
=== Inventory Vectors ===<br />
<br />
Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br />
<br />
Inventory vectors consist of the following data format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || type || uint32_t || Identifies the object type linked to this inventory<br />
|-<br />
| 32 || hash || char[32] || Hash of the object<br />
|}<br />
<br />
<br />
The object type is currently defined as one of the following possibilities:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || ERROR || Any data of with this number may be ignored<br />
|-<br />
| 1 || MSG_TX || Hash is related to a transaction<br />
|-<br />
| 2 || MSG_BLOCK || Hash is related to a data block<br />
|-<br />
| 3 || MSG_FILTERED_BLOCK || Hash of a block header; identical to MSG_BLOCK. When used in a getdata message, this indicates the reply should be a merkleblock message rather than a block message; this only works if a bloom filter has been set.<br />
|}<br />
<br />
Other Data Type values are considered reserved for future implementations.<br />
<br />
=== Block Headers ===<br />
<br />
Block headers are sent in a headers packet in response to a getheaders message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Will overflow in 2106<ref>http://en.wikipedia.org/wiki/Unix_time#Notable.C2.A0events.C2.A0in.C2.A0Unix.C2.A0time</ref>)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 1 || txn_count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of transaction entries, this value is always 0<br />
|}<br />
<br />
== Message types ==<br />
<br />
=== version ===<br />
<br />
When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No further communication is possible until both peers have exchanged their version.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || int32_t || Identifies protocol version being used by the node<br />
|-<br />
| 8 || services || uint64_t || bitfield of features to be enabled for this connection<br />
|-<br />
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds<br />
|-<br />
| 26 || addr_recv || [[#Network address|net_addr]] || The network address of the node receiving this message<br />
|-<br />
|colspan="4"| version >= 106<br />
|-<br />
| 26 || addr_from || [[#Network address|net_addr]] || The network address of the node emitting this message<br />
|-<br />
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.<br />
|-<br />
| ? || user_agent || [[#Variable length string|var_str]] || [https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki User Agent] (0x00 if string is 0 bytes long)<br />
|-<br />
| 4 || start_height || int32_t || The last block received by the emitting node<br />
|-<br />
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037], since version >= 70001<br />
|}<br />
<br />
A "verack" packet shall be sent if the version packet was accepted.<br />
<br />
The following services are currently assigned:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br />
|}<br />
<br />
Hexdump example of version message (OBSOLETE EXAMPLE: This example lacks a checksum and user-agent):<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br />
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br />
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br />
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br />
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br />
0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
55 00 00 00 - Payload is 85 bytes long<br />
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0<br />
Version message:<br />
9C 7C 00 00 - 31900 (version 0.3.19)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address<br />
DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br />
00 - "" sub-version string (string is 0 bytes long)<br />
55 81 01 00 - Last block sending node has is block #98645<br />
</pre><br />
<br />
And here's a modern (60002) protocol version client advertising itself to a local peer...<br />
<br />
Newer protocol includes the checksum now, this is from a mainline (satoshi) client during <br />
an outgoing connection to another local client, notice that it does not fill out the <br />
address information at all when the source or destination is "unroutable".<br />
<br />
<pre><br />
<br />
0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....<br />
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......<br />
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........<br />
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................<br />
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................<br />
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh<br />
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
64 00 00 00 - Payload is 100 bytes long<br />
3B 64 8D 5A - payload checksum<br />
<br />
Version message:<br />
62 EA 00 00 - 60002 (protocol version 60002)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address<br />
3B 2E B3 5D 8C E6 17 65 - Node ID<br />
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)<br />
C0 3E 03 00 - Last block sending node has is block #212672<br />
</pre><br />
<br />
=== verack ===<br />
<br />
The ''verack'' message is sent in reply to ''[[#version|version]]''. This message consists of only a [[#Message structure|message header]] with the command string "verack".<br />
<br />
Hexdump of the verack message:<br />
<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br />
0010 00 00 00 00 5D F6 E0 E2 ........<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command<br />
00 00 00 00 - Payload is 0 bytes long<br />
5D F6 E0 E2 - Checksum<br />
</pre><br />
<br />
=== addr ===<br />
<br />
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br />
<br />
Payload:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of address entries (max: 1000)<br />
|-<br />
| 30x? || addr_list || (uint32_t + [[#Network address|net_addr]])[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).<br />
|}<br />
<br />
'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.<br />
<br />
Hexdump example of ''addr'' message:<br />
<pre><br />
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br />
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...<br />
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br />
0030 FF 0A 00 00 01 20 8D ..... .<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"<br />
1F 00 00 00 - payload is 31 bytes long<br />
ED 52 39 9B - checksum of payload<br />
<br />
Payload:<br />
01 - 1 address in this message<br />
<br />
Address:<br />
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)<br />
20 8D - port 8333<br />
</pre><br />
<br />
=== inv ===<br />
<br />
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br />
<br />
Payload (maximum 50,000 entries, which is just over 1.8 megabytes):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getdata ===<br />
<br />
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).<br />
<br />
Payload (maximum 50,000 entries, which is just over 1.8 megabytes):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== notfound ===<br />
<br />
notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getblocks ===<br />
<br />
Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first. <br />
<br />
The locator hashes are processed by a node in the order as they appear in the message. If a block hash is found in the node's main chain, the list of its children is returned back via the ''inv'' message and the remaining locators are ignored, no matter if the requested limit was reached, or not.<br />
<br />
To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients may provide blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_documentation#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)<br />
|}<br />
<br />
To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:<br />
<br />
<pre><br />
// From libbitcoin which is under AGPL<br />
std::vector<size_t> block_locator_indices(int top_depth)<br />
{<br />
// Start at max_depth<br />
std::vector<size_t> indices;<br />
// Push last 10 indices first<br />
size_t step = 1, start = 0;<br />
for (int i = top_depth; i > 0; i -= step, ++start)<br />
{<br />
if (start >= 10)<br />
step *= 2;<br />
indices.push_back(i);<br />
}<br />
indices.push_back(0);<br />
return indices;<br />
}<br />
</pre><br />
<br />
Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.<br />
<br />
=== getheaders ===<br />
<br />
Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the block chain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients may provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_documentation#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)<br />
|}<br />
<br />
For the block locator object in this packet, the same rules apply as for the [[Protocol_documentation#getblocks|getblocks]] packet.<br />
<br />
=== tx ===<br />
<br />
''tx'' describes a bitcoin transaction, in reply to ''[[#getdata|getdata]]''<br />
<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Transaction data format version<br />
|-<br />
| 1+ || tx_in count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of Transaction inputs<br />
|-<br />
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br />
|-<br />
| 1+ || tx_out count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of Transaction outputs<br />
|-<br />
| 9+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br />
|-<br />
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:<br />
{|class="wikitable"<br />
! Value !! Description<br />
|-<br />
| 0 || Not locked<br />
|-<br />
| < 500000000 || Block number at which this transaction is locked<br />
|-<br />
| >= 500000000 || UNIX timestamp at which this transaction is locked<br />
|}<br />
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see [[NLockTime]]).<br />
<br />
|}<br />
<br />
TxIn consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br />
|-<br />
| 1+ || script length || [[Protocol_documentation#Variable_length_integer|var_int]] || The length of the signature script<br />
|-<br />
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization<br />
|-<br />
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.<br />
|}<br />
<br />
The OutPoint structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || The hash of the referenced transaction.<br />
|-<br />
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br />
|}<br />
<br />
The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br />
<br />
(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)<br />
<br />
The TxOut structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || value || int64_t || Transaction Value<br />
|-<br />
| 1+ || pk_script length || [[Protocol_documentation#Variable_length_integer|var_int]] || Length of the pk_script<br />
|-<br />
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br />
|}<br />
<br />
Example ''tx'' message:<br />
<pre><br />
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........<br />
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..<br />
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.<br />
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...<br />
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...<br />
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:<br />
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....<br />
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...<br />
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....<br />
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...<br />
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...<br />
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...<br />
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....<br />
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....<br />
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........<br />
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..<br />
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...<br />
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......<br />
<br />
<br />
Message header:<br />
F9 BE B4 D9 - main network magic bytes<br />
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command<br />
02 01 00 00 - payload is 258 bytes long<br />
E2 93 CD BE - checksum of payload<br />
<br />
Transaction:<br />
01 00 00 00 - version<br />
<br />
Inputs:<br />
01 - number of transaction inputs<br />
<br />
Input 1:<br />
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)<br />
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29<br />
00 00 00 00<br />
<br />
8B - script is 139 bytes long<br />
<br />
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)<br />
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23<br />
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41<br />
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD<br />
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E<br />
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD<br />
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02<br />
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04<br />
2F 46 61 4A 4C 70 C0 F1 4B EF F5<br />
<br />
FF FF FF FF - sequence<br />
<br />
Outputs:<br />
02 - 2 Output Transactions<br />
<br />
Output 1:<br />
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script<br />
A9 D9 EA 1A FB 22 5E 88 AC<br />
<br />
Output 2:<br />
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script<br />
FD A0 B7 8B 4E CC 52 88 AC<br />
<br />
Locktime:<br />
00 00 00 00 - lock time<br />
</pre><br />
<br />
=== block ===<br />
<br />
The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A Unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| ? || txn_count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of transaction entries<br />
|-<br />
| ? || txns || tx[] || Block transactions, in format of "tx" command<br />
|}<br />
<br />
The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.<br />
See [[Block hashing algorithm]] for details and an example.<br />
<br />
=== headers ===<br />
<br />
The ''headers'' packet returns block headers in response to a ''getheaders'' packet. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_documentation#Variable_length_integer|var_int]] || Number of block headers<br />
|-<br />
| 81x? || headers || [[Protocol_documentation#Block_Headers|block_header]][] || [[Protocol_documentation#Block_Headers|Block headers]]<br />
|}<br />
<br />
Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.<br />
<br />
=== getaddr ===<br />
<br />
The getaddr message sends a request to a node asking for information about known active peers to help with finding potential nodes in the network. The response to receiving this message is to transmit one or more addr messages with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== mempool ===<br />
<br />
The mempool message sends a request to a node asking for information about transactions it has verified but which have not yet confirmed. The response to receiving this message is an inv message containing the transaction hashes for all the transactions in the node's mempool.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
It is specified in [https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki BIP 35]. Since [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 37], if a [[Protocol_documentation#filterload.2C_filteradd.2C_filterclear.2C_merkleblock|bloom filter]] is loaded, only transactions matching the filter are replied.<br />
<br />
=== checkorder ===<br />
<br />
This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.<br />
<br />
=== submitorder ===<br />
<br />
This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.<br />
<br />
=== reply ===<br />
<br />
This message was used for [[IP Transactions]]. As IP transactions have been deprecated, it is no longer used.<br />
<br />
=== ping ===<br />
<br />
The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || nonce || uint64_t || random nonce<br />
|}<br />
<br />
=== pong ===<br />
<br />
The ''pong'' message is sent in response to a ''ping'' message. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || nonce || uint64_t || nonce from ping<br />
|}<br />
<br />
<br />
=== reject===<br />
<br />
The ''reject'' message is sent when messages are rejected.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || message || var_str || type of message rejected<br />
|-<br />
| 1 || ccode || char || code relating to rejected message<br />
|-<br />
| 1+ || reason || var_str || text version of reason for rejection<br />
|-<br />
| 0+ || data || char || Optional extra data provided by some errors. Currently, all errors which provide this field fill it with the TXID or block header hash of the object being rejected, so the field is 32 bytes.<br />
|}<br />
<br />
CCodes<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0x01 || REJECT_MALFORMED|| <br />
|-<br />
| 0x10 || REJECT_INVALID ||<br />
|-<br />
| 0x11 || REJECT_OBSOLETE ||<br />
|-<br />
| 0x12 || REJECT_DUPLICATE ||<br />
|-<br />
| 0x40 || REJECT_NONSTANDARD ||<br />
|-<br />
| 0x41 || REJECT_DUST ||<br />
|-<br />
| 0x42 || REJECT_INSUFFICIENTFEE ||<br />
|-<br />
| 0x43 || REJECT_CHECKPOINT ||<br />
|}<br />
<br />
=== filterload, filteradd, filterclear, merkleblock ===<br />
<br />
These messages are related to Bloom filtering of connections and are defined in [https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki BIP 0037].<br />
<br />
<br />
The <code>filterload</code> command is defined as follows:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.<br />
|-<br />
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.<br />
|-<br />
| 4 || nTweak || uint32_t || A random value to add to the seed value in the hash function used by the bloom filter.<br />
|-<br />
| 1 || nFlags || uint8_t || A set of flags that control how matched items are added to the filter.<br />
|}<br />
<br />
See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.<br />
<br />
Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below. The flags control the update behaviour of the matching algorithm.<br />
<br />
The <code>filteradd</code> command is defined as follows:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || data || uint8_t[] || The data element to add to the current filter.<br />
|}<br />
<br />
The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).<br />
<br />
The given data element will be added to the Bloom filter. A filter must have been previously provided using <code>filterload</code>. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer (though doing so is usually advisable to maintain anonymity).<br />
<br />
The <code>filterclear</code> command has no arguments at all.<br />
<br />
After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 4 || total_transactions || uint32_t || Number of transactions in the block (including unmatched ones)<br />
|-<br />
| ? || hashes || uint256[] || hashes in depth-first order (including standard varint size prefix)<br />
|-<br />
| ? || flags || byte[] || flag bits, packed per 8 in a byte, least significant bit first (including standard varint size prefix)<br />
|}<br />
<br />
=== alert ===<br />
<br />
An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.<br />
<br />
Alert format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || payload || uchar[] || Serialized alert payload<br />
|-<br />
| ? || signature || uchar[] || An ECDSA signature of the message<br />
|}<br />
<br />
The developers of Satoshi's client use this public key for signing alerts:<br />
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br />
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br />
<br />
The payload is serialized into a uchar[] to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || Version || int32_t || Alert format version<br />
|-<br />
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert<br />
|-<br />
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored<br />
|-<br />
| 4 || ID || int32_t || A unique ID number for this alert<br />
|-<br />
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be cancelled: deleted and not accepted in the future<br />
|-<br />
| ? || setCancel || set<int32_t> || All alert IDs contained in this set should be cancelled as above<br />
|-<br />
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.<br />
|-<br />
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.<br />
|-<br />
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.<br />
|-<br />
| 4 || Priority || int32_t || Relative priority compared to other alerts<br />
|-<br />
| ? || Comment || string || A comment on the alert that is not displayed<br />
|-<br />
| ? || StatusBar || string || The alert message that is displayed to the user<br />
|-<br />
| ? || Reserved || string || Reserved<br />
|}<br />
<br />
Note: '''set<''type''>''' in the table above is a [[#Variable length integer | variable length integer]] followed by the number of fields of the given ''type'' (either int32_t or [[#Variable length string | variable length string]])<br />
<br />
Sample alert (no message header):<br />
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000<br />
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861<br />
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172<br />
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b<br />
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1<br />
<br />
Version: 1<br />
RelayUntil: 1329620535<br />
Expiration: 1329792435<br />
ID: 1010<br />
Cancel: 1009<br />
setCancel: <empty><br />
MinVer: 10000<br />
MaxVer: 61000<br />
setSubVer: <empty><br />
Priority: 100<br />
Comment: <empty><br />
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"<br />
Reserved: <empty><br />
<br />
== Scripting ==<br />
<br />
See [[script]].<br />
<br />
==See Also==<br />
<br />
* [[Network]]<br />
* [[Protocol rules]]<br />
* [[Hardfork Wishlist]]<br />
* [https://bitcoin.org/en/developer-documentation Developer Documentation on bitcoin.org]<br />
* Bitcoin dissectors for Wireshark: https://github.com/lbotsch/wireshark-bitcoin https://github.com/op-sig/bitcoin-wireshark-dissector<br />
<br />
==References==<br />
<references /><br />
<br />
[[zh-cn:协议说明]]<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Norillhttps://tests.bitcoin.it/w/index.php?title=Invoice_address&diff=56294Invoice address2015-05-05T16:44:30Z<p>Norill: /* Address balances */</p>
<hr />
<div>A '''Bitcoin address''', or simply '''address''', is an identifier of 26-35 alphanumeric characters, beginning with the number 1 or 3, that represents a possible destination for a Bitcoin payment.<br />
Addresses can be generated at no cost by any user of Bitcoin.<br />
For example, using [[Bitcoin-Qt]], one can click "New Address" and be assigned an address.<br />
It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.<br />
<br />
An example of a Bitcoin address is <code>3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy</code><!-- anyone-can-spend, null script -->.<br />
<br />
==A Bitcoin address is a single-use token==<br />
Like e-mail addresses, you can send bitcoins to a person by sending bitcoins to one of their addresses.<br />
However, ''unlike'' e-mail addresses, people have many different Bitcoin addresses and a unique address should be used for each transaction.<br />
Most Bitcoin software and websites will help with this by generating a brand new address each time you create an invoice or payment request.<br />
<br />
==Addresses can be created offline==<br />
Creating addresses can be done without an Internet connection and does not require any contact or registration with the Bitcoin network.<br />
It is possible to create large batches of addresses offline using freely available software tools.<br />
Generating batches of addresses is useful in several scenarios, such as e-commerce websites where a unique pre-generated address is dispensed to each customer who chooses a "pay with Bitcoin" option.<br />
Newer [[Deterministic wallet | "HD wallets"]] can generate a "seed" token which can be used to allow untrusted systems (such as webservers) to generate an unlimited number of addresses without the ability to spend the bitcoins received.<br />
<br />
==Addresses are case sensitive and exact==<br />
Bitcoin addresses are case-sensitive. Bitcoin addresses should be copied and pasted using the computer's clipboard wherever possible. If you hand-key a Bitcoin address, and each character is not transcribed exactly - including capitalization - the incorrect address will most likely be rejected by the Bitcoin software. You will have to check your entry and try again.<br />
<br />
The probability that a mistyped address is accepted as being valid is 1 in 2<sup>32</sup>, that is, approximately 1 in 4.29 billion.<br />
<br />
==Proving you receive with an address==<br />
Most Bitcoin wallets have a function to "sign" a message, proving the entity receiving funds with an address has agreed to the message.<br />
This can be used to, for example, finalise a contract in a cryptographically provable way prior to making payment for it.<br />
<br />
Some services will also piggy-back on this capability by dedicating a specific address for authentication only, in which case the address should never be used for actual Bitcoin transactions.<br />
When you login to or use their service, you will provide a signature proving you are the same person with the pre-negotiated address.<br />
<br />
Current standards for message signatures are only compatible with "version zero" bitcoin addresses (that begin with the number 1).<br />
<br />
==Address validation==<br />
If you would like to validate a Bitcoin address in an application, it is advisable to use a method from [https://bitcointalk.org/index.php?topic=1026.0 this thread] rather than to just check for string length, allowed characters, or that the address starts with a 1 or 3. Validation may also be done using open source code available in [http://rosettacode.org/wiki/Bitcoin/address_validation various languages] or with an [http://lenschulwitz.com/base58 online validating tool]. <br />
<br />
==[[Multisignature|Multi-signature]] addresses==<br />
Addresses can be created that require a combination of multiple private keys.<br />
Since these take advantage of newer features, they begin with the newer prefix of 3 instead of the older 1.<br />
These can be thought of as the equivalent of writing a check to two parties - "pay to the order of somebody AND somebody else" - where both parties must endorse the check in order to receive the funds.<br />
<br />
The actual requirement (number of private keys needed, their corresponding public keys, etc.) that must be satisfied to spend the funds is decided in advance by the person generating this type of address, and once an address is created, the requirement cannot be changed without generating a new address.<br />
<br />
==What's in an address==<br />
Most Bitcoin addresses are 34 characters.<br />
They consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter "O", uppercase letter "I", lowercase letter "l", and the number "0" are never used to prevent visual ambiguity.<br />
<br />
Some Bitcoin addresses can be shorter than 34 characters (as few as 26) and still be valid.<br />
A significant percentage of Bitcoin addresses are only 33 characters, and some addresses may be even shorter.<br />
Every Bitcoin address stands for a number.<br />
These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.<br />
<br />
Several of the characters inside a Bitcoin address are used as a checksum so that typographical errors can be automatically found and rejected.<br />
The checksum also allows Bitcoin software to confirm that a 33-character (or shorter) address is in fact valid and isn't simply an address with a missing character.<br />
<br />
==Testnet==<br />
Addresses on the Bitcoin Testnet are generated with a different address version, which results in a different prefix.<br />
See [[List of address prefixes]] and [[Testnet]] for more details.<br />
<br />
==Misconceptions==<br />
===Address reuse===<br />
<br />
Addresses are not intended to be used more than once, and doing so has numerous problems associated.<br />
See the dedicated article on [[address reuse]] for more details.<br />
<br />
===Address balances===<br />
<br />
Addresses are not wallets nor accounts, and do not carry balances.<br />
They only receive funds, and you do not send "from" an address at any time.<br />
Various confusing services and software{{who}} display ''bitcoins received with an address, minus bitcoins sent in random unrelated transactions'' as an "address balance", but this number is not meaningful: it does not infer the recipient of the bitcoins sent to the address has spent them, nor that they still have the bitcoins received.<br />
<br />
==="From" addresses===<br />
Bitcoin transactions do not have any kind of origin-, source- or "from" address. See the dedicated article on "[[From address|from address]]" for more details.<br />
<br />
==See Also==<br />
* [[Technical background of Bitcoin addresses]]<br />
* [[List of address prefixes]]<br />
* [[Exit Address]]<br />
<br />
== References ==<br />
<references/><br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[es:Dirección]]<br />
[[de:Adresse]]</div>Norillhttps://tests.bitcoin.it/w/index.php?title=Bitcoin_Wiki:Community_portal&diff=56288Bitcoin Wiki:Community portal2015-05-01T19:48:45Z<p>Norill: </p>
<hr />
<div>== Bitcoin Community Forums on various platforms ==<br />
* [http://bitcointalk.org/ Bitcointalk]<br />
* [http://www.reddit.com/r/Bitcoin/ /r/Bitcoin]<br />
* [https://plus.google.com/communities/115591368588047305300 Bitcoin Google+ Community]<br />
* [http://bitcoin.org.uk/forums Bitcoin Forums]<br />
* [http://bitcoin.stackexchange.com/ The Bitcoin StackExchange]<br />
* [http://www.quora.com/Bitcoin/ Bitcoin group on Quora]<br />
* [http://bitcointrading.com Bitcoin Trading Forum]<br />
* [http://tweetforum.com/bitcoin TweetForum Bitcoin Community]<br />
* [http://www.bitcoin-board.com/ Bitcoin-Board Forum]<br />
* [http://www.bitcoinforums.net BitcoinForums.Net]<br />
* [http://groups.google.com/group/bitcoin-discussion Bitcoin google group]<br />
* [http://goo.gl/2PncY Bitcoin Portal p2p (on Osiris platform)]<br />
* [http://www.btclog.com btc::log]<br />
* [http://www.facebook.com/bitcoins Facebook page]<br />
* [http://www.facebook.com/groups/136003253120130 Facebook Group]<br />
* [https://plus.google.com/107581642674912229828/ Bitcoin Google+]<br />
* [http://hubski.com/tag?id=bitcoin Bitcoin on Hubski]<br />
* [http://www.bitcointribe.com Bitcoin Tribe Social Network]<br />
<br />
===Regions / Languages===<br />
* [https://coinforum.ca Canada's Bitcoin Community]<br />
* [https://www.bitcoin-italia.org Bitcoin Italia]<br />
* [http://forum.bitcoin.com.au/ Bitcoin Australia Forum]<br />
* [http://www.bitcoin.org.il Isreali Bitcoin Community Forum]<br />
* [http://bitcoincenterkorea.org Bitcoin Center Korea]<br />
* [http://bitcoin.pl/forum/ Polish Bitcoin Community Forum]<br />
* [http://btcsec.com/ BTCsec.com] Russian Website about Bitcoin<br />
* [https://forum.btcsec.com/ BTCsec.com Bitcoin Community Forum (Russian)]<br />
* [http://rubitcoin.com/ Russian Bitcoin Community Forum]<br />
* [https://www.facebook.com/groups/bitcoinph/ Bitcoin Philippine Community]<br />
<br />
=== Local Communities ===<br />
''For an up-to-date list please see [http://www.reddit.com/r/Bitcoin/wiki/local_communities local communities]<br />
* [http://www.reddit.com/r/ArgenBitcoin Argentina bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinAUS Australia bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinBE Belgian bitcoin community]<br />
* [http://www.reddit.com/r/BrasilBitcoin Brazil bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinCA Canada bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinDK Denmark bitcoin community]<br />
* [http://www.reddit.com/r/bitcoinsuomi Finland bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinFrance France bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinDE Germany bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinGhana Ghana bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinGT Guatemala bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinIndia India bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinIran Iran bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinIT Italy bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinJP Japan bitcoin community]<br />
* [http://www.reddit.com/r/bitcoinlaos Laos bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinMalaysia Malaysia bitcoin community]<br />
* [http://www.reddit.com/r/BITCOINMEX Mexico bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinNL The Netherlands bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinNO Norway bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinPL Poland bitcoin community]<br />
* [http://www.reddit.com/r/bitcoinsouthafrica South Africa bitcoin community]<br />
* [http://www.reddit.com/r/bitcoines Spain bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinSWE Sweden bitcoin community]<br />
* [http://www.reddit.com/r/btctaiwan Taiwan bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinTR Turkey bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinUK United Kingdom bitcoin community]<br />
** [http://www.reddit.com/r/BitcoinLondon London bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinUSA USA bitcoin community]<br />
** [http://www.reddit.com/r/BitcoinBayArea Bay Area, CA bitcoin community]<br />
** [http://www.reddit.com/r/DenverBitcoin/ Denver, CO bitcoin community]<br />
** [http://www.reddit.com/r/BitcoinAsheville Asheville, NC bitcoin community]<br />
** [http://www.reddit.com/r/BitcoinAlbuquerque Albuquerque, NM bitcoin community]<br />
** [http://www.reddit.com/r/BitcoinNY New York City, NY bitcoin community]<br />
** [http://www.reddit.com/r/BitcoinPA Pennsylvania bitcoin community]<br />
** [http://www.reddit.com/r/BitcoinNashville Nashville, TN bitcoin community]<br />
** [http://reddit.com/r/BitcoinAustin/ Austin, TX bitcoin community]<br />
** [http://www.reddit.com/r/BitcoinSeattle Seattle, WA bitcoin community]<br />
* [http://www.reddit.com/r/BitcoinVzla Venezuela bitcoin community]<br />
<br />
== Bitcoin Community Groups on Bitcoin Wiki platform ==<br />
<br />
=== Special interests ===<br />
* [[Bitcoin Wiki]]-group<br />
<br />
=== Geographically ===<br />
* [[Espagna]] / [[Spain]] (E.) <br />
* [[France]] / [[France]] (F.)<br />
* [[Germany]] / [[Deutschland]] (D.) <br />
* [[Netherlands]] (NL) and [[Belgium]] (B.)<br />
* [[United Kingdom]] of Great Brittain (GB) and Northern Ireland<br />
* [[United States]] of America (USA)<br />
<br />
====Clusters====<br />
There are various temporary and permanent clusters where bitcoin-friendly communities form. Temporary clusters are listed in [[Bitcoin:Community_portal#Events|events]]. Permanent communities include:<br />
<br />
* [http://bitcointalk.org/index.php?topic=66832.0 Free State Project] New Hampshire<br />
* [http://www.thebitcointrader.com/2012/05/bitcoins-hogwarts-san-francisco-tech.html 20 Mission] San Francisco, CA<br />
* [http://bitcoinmagazine.net/bitcoin-kiez-rollout-3-new-btc-accepting-stores-and-restaurants-in-berlin-more-to-come Bitcoin Kiez] Berlin, Germany<br />
<br />
== IRC ==<br />
<br />
* See [[IRC_channels|IRC channels]]<br />
<br />
==Wiki Users==<br />
<br />
* [http://en.bitcoin.it/wiki/Special:ListUsers List of Users] registered on the Bitcoin wiki.<br />
<br />
== Events ==<br />
Periodic events where Bitcoin community meets include PorcFest, Chaos Computer Camp, Burning Man, Bitcoin conferences and more.<br />
<br />
* [[Meetups]]<br />
* [http://bitcointalk.org/index.php?topic=4526.0 Events, conferences and other events]<br />
<br />
==Bitcoin Related Publications==<br />
<br />
* [http://bitcoinmagazine.net Bitcoin Magazine] periodical printed publication<br />
* [http://twitter.com/bitcoinnews/bitcoin @BitcoinNews/bitcoin] Twitter list<br />
* See [[:Category:Blogs|Blogs]] category<br />
* See [[:Category:Directories|Directories]] category<br />
* See [[Press]]<br />
<br />
==Education==<br />
<br />
* [[:Category:Educational|Educational category]]<br />
<br />
== Maps ==<br />
* [http://bitcoinyellowpages.com Bitcoin Yellow Pages], A fast growing Bitcoin search directory showing all Bitcoin business locations on a world map. Search by keyword, location, or category to find the Bitcoin business that fits your needs.<br />
* [http://coinmap.org/ CoinMap], collaborative map based on OpenStreetMap data and rendering<br />
* [[Bitcoin.local]] Local exchanges<br />
* The [[Bitcoin Map (Collaborative map)|Bitcoin Map]] collaborative map<br />
* [[Bitcoin Users Worldwide]] - Find nearby Bitcoin users • Engage in local trade • Add your own offers • Get notifications<br />
<br />
== Monitoring ==<br />
* [http://bitcoincharts.com/markets/ Bitcoin Charts] displays an overview of Bitcoin exchange markets.<br />
* The [http://www.bitcoinmonitor.com/ Bitcoin Monitor] visualizes transactions, new blocks and trades on markets as they are happening.<br />
* [http://www.bitcoinwatch.com/ Bitcoin Watch] has various statistics on things like the size of the economy or the number of transactions.<br />
<br />
== Portfolio ==<br />
* [http://my-btc.info MY-BTC.INFO] A free profit/loss portfolio manager for Bitcoins and other digital currencies.<br />
* [http://myBitWorth.com myBitWorth] - allows you to track your bitcoin holdings over multiple addresses and portfolios on the bitcoin securities exchanges.<br />
<br />
== Bitcoin Project ==<br />
* [http://www.bitcoin.org Bitcoin.org] Official project site<br />
* [[:Category:Developer|Developer]] pages<br />
<br />
== Non-profit Organizations ==<br />
<br />
* [[List_of_Bitcoin_non-profits_around_the_world|List of Bitcoin non-profits around the world]]<br />
<br />
== External Communities ==<br />
* [http://www.etsy.com/teams/10366/bitcoin Bitcoin team] on Etsy, an e-commerce website focused on handmade or vintage items.<br />
* [http://weacceptbitcoins.deviantart.com #WeAcceptBitcoins group] on deviantArt, an online community showcasing various forms of user-made artwork.<br />
* [https://www.couchsurfing.org/group.html?gid=38717 Bitcoin group] on Couchsurfing.org, a website that offers its users hospitality exchange and social networking services.<br />
* [http://steamcommunity.com/groups/bitcoin Bitcoin group on Steam] platform by Valve, a gaming platform.<br />
* [http://www.Ogrr.com Ogrr], a digital trading community.<br />
* [http://www.rugatu.com/ Rugatu], a Q&A community.</div>Norillhttps://tests.bitcoin.it/w/index.php?title=Address_reuse&diff=56285Address reuse2015-05-01T17:46:16Z<p>Norill: removed controversial section</p>
<hr />
<div>Address reuse is the practice of sending multiple transactions to the same address.<br />
This works by "accident", not by design.<br />
It is considered a bad practice, and not something that should be done.<br />
<br />
== Problems ==<br />
=== Privacy ===<br />
Address reuse harms the privacy of not only yourself, but also others - including many not related to the transaction.<br />
In some cases, these risks are serious enough that they are likely in violation of reasonable consumer protection laws.<br />
<br />
When addresses are re-used, they allow others to much more easily and reliably determine that the address being reused is yours. Every time the re-used address's private key signs a fresh transaction, whoever receives it can use the histories of that address to discover information about you, and everyone who is interested in discovering the identity of the address's owner has one more target they can try to contact to discover who you are.<br />
<br />
The relationship graph in a re-used address is powerfully-linked in that '''all''' of the inputs to that address are necessarily joined (via the spending authority of your private key) to all of its outputs.<br />
<br />
There has been significant research into the area of what researchers are calling 'identity collapse', which is what happens when more than one Bitcoin address is strongly-linked via the Bitcoin transaction graph to another. Re-using addresses makes their job trivial. There are publically-known databases that exist, right now, that have not only collapsed millions of Bitcoin addresses, but used publically-available information to '''link''' those collapsed identities to individuals, and these databases are being actively maintained.<br />
<br />
While you may be okay with some random European researcher bound by his ethics board to conceal your identity from the public at-large, it is very possible that people who accept money from you may not be aware of your decision: thus, via your privacy-decreasing action, people further on the address signing chain could thus be putting '''you''' at risk if they spend their Bitcoin on something that catches the attention of law enforcement.<br />
<br />
Additionally, in the event that you knowingly make this choice (which you are doing, now that you've read this,) the transaction histories that you are responsible for linking in the event you are a retailer of some sort could put the privacy of your customers at risk because now your well-known singular address(es) which can be strongly linked to your corporate identity can be assumed to be economic activity interacting with your corporate identity.<br />
<br />
See also: [http://www.bitcoinnotbombs.com/innovations-that-enhance-bitcoin-anonymity/ Innovations that Enhance Bitcoin Anonymity]<br />
<br />
==== Worked Example 1 ====<br />
* You save in bitcoin, using a [[Paper Wallet | single-address paper wallet]].<br />
* All your bitcoin savings to this same address, let's say it contains $1 million worth.<br />
* You buy a small amount of bitcoin to add to your savings, depositing in the paper wallet.<br />
* The person who sold you the bitcoins follows their trail on the blockchain and finds your paper wallet containing $1 million.<br />
* He mentions it to someone in a cafe or bar.<br />
* Word gets around. A burglar raids your home. Kidnappers capture your children and know exactly how much to demand in ransom.<br />
<br />
==== Worked Example 2 ====<br />
* You use a single bitcoin address for all your earning and spending. Anyone you trade with can see a complete history of your finances.<br />
* Your landlord can see your salary, when he raises the rent he knows exactly how much to ask for.<br />
* Your shopkeeper can see your spending. Gossip gets around of how much your spend on pornography and how little on church donations.<br />
* Your employer can see your spending. When you pay labour union dues or donate to wikileaks or another non-profit, your boss knows who not to trust.<br />
<br />
=== Security ===<br />
Bitcoin does not, at a low level, have any concept of addresses, only individual coins.<br />
Address reuse, at this layer, requires producing multiple digital signatures when you spend bitcoins.<br />
Multiple situations have been found where more than one digital signature can be used to calculate the private key needed to spend bitcoins.<br />
Even if you spend all the bitcoins claimed by this private key at once, it is still possible to double-spend them in theft before they confirm.<br />
While the known situations for finding the private key from signatures have been fixed, it is not prudent to assume there aren't more such situations yet unknown.<br />
<br />
In the case of spending all the TXOs in a single transaction, there is an additional risk if someone is actively monitoring the network for vulnerable transactions:<br />
upon receiving such a transaction, they can split up their double spends such that there is only one ECDSA verification per transaction (making a single transaction for each TXO);<br />
this will cause the attacker's transactions to relay across the rest of the nodes ''faster'' than the legitimate one, increasing success of a double spend.<br />
<br />
==== Known attacks ====<br />
<br />
* Same K in multiple signatures, see [http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html Recovering Bitcoin private keys using weak signatures from the blockchain].<br />
* [https://eprint.iacr.org/2014/140.pdf Timing sidechannel]<br />
<br />
=== Accidental loss ===<br />
In Bitcoin abstraction, an address is an invoice for a specific payment.<br />
Once that payment is made, the receiving party has no reason to retain the data for the address (technical details simplified) and may discard it.<br />
Even if someone does not choose to discard that data, it may have since been lost in an accident or compromised.<br />
In any of these situations, any future payments to the same address would go in to a "black hole", and be forever lost through no fault of the recipient.<br />
<br />
=== High Fees ===<br />
A single invoice payment using P2PKH can be redeemed and spent with a predictable fee because the transaction should have a predictable size. Software that determines payment and available funds based on "address balance" can cause loss through high fees. If you are paid to an address in many small increments, you will pay a much higher transaction fee when redeeming those payments. It is much more useful for a client to display transaction outputs spendable than address balances for this reason.<br />
<br />
== Notable offenders ==<br />
Some notable Bitcoin software and services encourage or require address reuse:<br />
* Many bitcoin mining pools (especially [[Eligius]])<br />
* Electrum displays addresses in a way that encourages confusion and address reuse and misuse.</div>Norillhttps://tests.bitcoin.it/w/index.php?title=Talk:Address_reuse&diff=56284Talk:Address reuse2015-05-01T17:44:53Z<p>Norill: </p>
<hr />
<div>Seems like another page, which is meant to be a vent for zealots' propaganda:<br />
<br />
- "Address reuse harms the privacy of not only yourself, but also others - including many not related to the transaction ..."<br />
<br />
without explaining what is this all about bears similar amount of informational value as "address reuse will cause you and others burn in eternal fire"<br />
<br />
- "Bitcoin does not, at a low level, have any concept of addresses, only individual coins. Address reuse, at this layer, requires producing multiple digital signatures when you spend bitcoins. Multiple situations have been found where more than one digital signature can be used to calculate the private key needed to spend bitcoins"<br />
<br />
Some solid references, examples? Or just a blah-blah meant to scare people away? Please back such strong statements with solid facts and references. Yes, they can be found.<br />
<br />
- "... situations for finding the private key from signatures have been fixed, it is not prudent to assume there aren't more such situations yet unknown."<br />
<br />
Non sequitur? It is not prudent to assume there aren't more "situations" in *ANY* part of the Bitcoin protocol AND its implementations. I wouldn't be very surprised if one day those who used "damned" address reusing wallets were left with their coins and one or another address changing wallet became compromised for very different reasons. Not that I wish. It is just not prudent to assume.<br />
<br />
- "Accidental loss - In Bitcoin abstraction, an address is an invoice for a specific payment."<br />
<br />
Not true. We want it to be like that and we encourage people to use it this way but we can't say that "it *IS*".<br />
<br />
- "Even if someone does not choose to discard that data, it may have since been lost in an accident or compromised. In any of these situations, any future payments to the same address would go in to a "black hole", and be forever lost through no fault of the recipient."<br />
<br />
True. Just - how different it is from the situation when one loses his holly-address-ever-changing wallet and all his /past/ payments go to a "black hole", and be forever lost through no fault of the recipient? In either situations coins are gone. Except that a prudent user could make a cold storage private key copies for his address and still be able to recover. While this kind of FUD propaganda could lead him to believe that he will be always safe because he never reuses the address.. this argument holds as much water as the previous one. Or if you lose your wallet and restore it from the backup, but... oops!! Suddenly *BECAUSE* of changing address all payments are in the "black hole" and lost forever. Please mind that we talk here about "Address reuse", not about "HD Wallets"!<br />
<br />
- Confusion - "Users who see addresses reused may incorrectly be led to believe they function similarly to [...] bank accounts.<br />
<br />
Because they do. Go to the "offending" blockchain.info, enter an address, which has more than one transaction attached to it and no matter how much we want to bend the reality - the similarities are there: all transactions sum up to a final balance. No matter how it all works deep down (if you go deep enough it is all about moving photons and electrons) looking from a higher perspective they do work "similarly to bank accounts" whether we like it or not and no matter how much we say that they don't.<br />
<br />
- "Often this is manifested in people talking about nonsense like "address balance""<br />
<br />
Definitely! They know nothing and talk nonsense... :-(<br />
<br />
I don't feel like spending a considerable amount of time correcting all these, only to see the changes reverted. For the good of Bitcoin in general, please don't create more confusion than is needed. Tell the truth and explain things instead of telling half-truths or even plain non-truths. This kind of FUD and misinformation is a good way to create even more confusion in new users and scare them away. Tell them true. Show them both sides instead.<br />
<br />
What should be there:<br />
<br />
1. Address reuse lowers the level of privacy and anonymity<br />
2. In certain situations address reuse may lead to increased risk of compromising the private key(s)<br />
etc.<br />
<br />
Wouldn't hurt mentioning good sides either. Like that address reuse can actually *prevent* loss of coins in cases like losing a non-HD wallet, which kept changing addresses. And adding that rather than reusing addresses, people should switch to HD implementations, etc.<br />
<br />
Still - with what I read originally on that page, I am afraid this kind of unbiased information is far too much to expect.<br />
<br />
: If you'd like to add references, feel free. Please don't modify the content to fit your erroneous understanding how Bitcoin works, however. Thanks. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 00:14, 28 October 2014 (UTC)<br />
<br />
:: I would first remove offensive and untrue elements. Only then I would focus on adding appropriate references to those, which are in fact true, valid and important. I just don't want to lose much time doing this if this is going to be reversed by you anyway. But one thing.. could you be so kind as to explain which parts of my understanding how Bitcoin works are erroneous? [[User:Silverdr|Silverdr]] ([[User talk:Silverdr|talk]]) 04:43, 29 October 2014 (UTC)<br />
<br />
Since you don't seem to provide any support for them, can we eventually remove the false statements? luke-jr?<br />
[[User:Silverdr|Silverdr]] ([[User talk:Silverdr|talk]]) 14:50, 30 October 2014 (UTC)<br />
:don't mind the troll. i agree, this article needs a major rewrite [[User:Norill|Norill]] ([[User talk:Norill|talk]]) 17:44, 1 May 2015 (UTC)</div>Norillhttps://tests.bitcoin.it/w/index.php?title=Invoice_address&diff=56280Invoice address2015-04-30T16:17:18Z<p>Norill: /* Proving you receive with an address */ bullshit removed</p>
<hr />
<div>A '''Bitcoin address''', or simply '''address''', is an identifier of 26-35 alphanumeric characters, beginning with the number 1 or 3, that represents a possible destination for a Bitcoin payment.<br />
Addresses can be generated at no cost by any user of Bitcoin.<br />
For example, using [[Bitcoin-Qt]], one can click "New Address" and be assigned an address.<br />
It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.<br />
<br />
An example of a Bitcoin address is <code>3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy</code><!-- anyone-can-spend, null script -->.<br />
<br />
==A Bitcoin address is a single-use token==<br />
Like e-mail addresses, you can send bitcoins to a person by sending bitcoins to one of their addresses.<br />
However, ''unlike'' e-mail addresses, people have many different Bitcoin addresses and a unique address should be used for each transaction.<br />
Most Bitcoin software and websites will help with this by generating a brand new address each time you create an invoice or payment request.<br />
<br />
==Addresses can be created offline==<br />
Creating addresses can be done without an Internet connection and does not require any contact or registration with the Bitcoin network.<br />
It is possible to create large batches of addresses offline using freely available software tools.<br />
Generating batches of addresses is useful in several scenarios, such as e-commerce websites where a unique pre-generated address is dispensed to each customer who chooses a "pay with Bitcoin" option.<br />
Newer [[Deterministic wallet | "HD wallets"]] can generate a "seed" token which can be used to allow untrusted systems (such as webservers) to generate an unlimited number of addresses without the ability to spend the bitcoins received.<br />
<br />
==Addresses are case sensitive and exact==<br />
Bitcoin addresses are case-sensitive. Bitcoin addresses should be copied and pasted using the computer's clipboard wherever possible. If you hand-key a Bitcoin address, and each character is not transcribed exactly - including capitalization - the incorrect address will most likely be rejected by the Bitcoin software. You will have to check your entry and try again.<br />
<br />
The probability that a mistyped address is accepted as being valid is 1 in 2<sup>32</sup>, that is, approximately 1 in 4.29 billion.<br />
<br />
==Proving you receive with an address==<br />
Most Bitcoin wallets have a function to "sign" a message, proving the entity receiving funds with an address has agreed to the message.<br />
This can be used to, for example, finalise a contract in a cryptographically provable way prior to making payment for it.<br />
<br />
Some services will also piggy-back on this capability by dedicating a specific address for authentication only, in which case the address should never be used for actual Bitcoin transactions.<br />
When you login to or use their service, you will provide a signature proving you are the same person with the pre-negotiated address.<br />
<br />
Current standards for message signatures are only compatible with "version zero" bitcoin addresses (that begin with the number 1).<br />
<br />
==Address validation==<br />
If you would like to validate a Bitcoin address in an application, it is advisable to use a method from [https://bitcointalk.org/index.php?topic=1026.0 this thread] rather than to just check for string length, allowed characters, or that the address starts with a 1 or 3. Validation may also be done using open source code available in [http://rosettacode.org/wiki/Bitcoin/address_validation various languages] or with an [http://lenschulwitz.com/base58 online validating tool]. <br />
<br />
==[[Multisignature|Multi-signature]] addresses==<br />
Addresses can be created that require a combination of multiple private keys.<br />
Since these take advantage of newer features, they begin with the newer prefix of 3 instead of the older 1.<br />
These can be thought of as the equivalent of writing a check to two parties - "pay to the order of somebody AND somebody else" - where both parties must endorse the check in order to receive the funds.<br />
<br />
The actual requirement (number of private keys needed, their corresponding public keys, etc.) that must be satisfied to spend the funds is decided in advance by the person generating this type of address, and once an address is created, the requirement cannot be changed without generating a new address.<br />
<br />
==What's in an address==<br />
Most Bitcoin addresses are 34 characters.<br />
They consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter "O", uppercase letter "I", lowercase letter "l", and the number "0" are never used to prevent visual ambiguity.<br />
<br />
Some Bitcoin addresses can be shorter than 34 characters (as few as 26) and still be valid.<br />
A significant percentage of Bitcoin addresses are only 33 characters, and some addresses may be even shorter.<br />
Every Bitcoin address stands for a number.<br />
These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.<br />
<br />
Several of the characters inside a Bitcoin address are used as a checksum so that typographical errors can be automatically found and rejected.<br />
The checksum also allows Bitcoin software to confirm that a 33-character (or shorter) address is in fact valid and isn't simply an address with a missing character.<br />
<br />
==Testnet==<br />
Addresses on the Bitcoin Testnet are generated with a different address version, which results in a different prefix.<br />
See [[List of address prefixes]] and [[Testnet]] for more details.<br />
<br />
==Misconceptions==<br />
===Address reuse===<br />
<br />
Addresses are not intended to be used more than once, and doing so has numerous problems associated.<br />
See the dedicated article on [[address reuse]] for more details.<br />
<br />
===Address balances===<br />
<br />
Addresses are not wallets nor accounts, and do not carry balances.<br />
They only receive funds, and you do not send "from" an address at any time.<br />
Various confusing services and software display ''bitcoins received with an address, minus bitcoins sent in random unrelated transactions'' as an "address balance", but this number is not meaningful: it does not infer the recipient of the bitcoins sent to the address has spent them, nor that they still have the bitcoins received.<br />
<br />
==="From" addresses===<br />
Bitcoin transactions do not have any kind of origin-, source- or "from" address. See the dedicated article on "[[From address|from address]]" for more details.<br />
<br />
==See Also==<br />
* [[Technical background of Bitcoin addresses]]<br />
* [[List of address prefixes]]<br />
* [[Exit Address]]<br />
<br />
== References ==<br />
<references/><br />
<br />
[[Category:Vocabulary]]<br />
<br />
[[es:Dirección]]<br />
[[de:Adresse]]</div>Norillhttps://tests.bitcoin.it/w/index.php?title=Deterministic_wallet&diff=53320Deterministic wallet2014-12-04T16:19:57Z<p>Norill: </p>
<hr />
<div>A deterministic wallet is a system of deriving keys from a single starting point known as a seed. The seed allows a user to easily back up and restore a wallet without needing any other information and can in some cases allow the creation of public addresses without the knowledge of the private key. <br />
<br />
== Benefits ==<br />
<br />
Early clients such as the [[Satoshi client]] generate a buffer of fresh random private keys to be used as receiving and [[change|change addresses]] in the future. This has the effect of invalidating backups after a short period when the keypool buffer (typically 100 addresses) is exhausted. Deterministic wallets can generate an unlimited number of addresses on the fly and as such don't suffer from this issue. As the addresses are generated in a known fashion rather than randomly some clients can be used on multiple devices without the risk of losing funds. Users can conveniently create a single backup of the seed in a human readable format that will last the life of the wallet, without the worry of this backup becoming stale. <br />
<br />
Certain types of deterministic wallet (BIP0032, Armory and [[Coinkite]] ) additionally allow for the complete separation of private and public key creation for greater security and convenience. In this model a server can be set up to only know the Master Public Key of a particular deterministic wallet. This allows the server to create as many public keys as is necessary for receiving funds, but a compromise of the MPK will not allow an attacker to spend from the wallet. They can alternatively be used in [[Electrum]] and [[Armory]] to enable completely offline storage and spending, where an offline computer knows the private key and an online one knows only the MPK. Transactions spending coins are ferried between the two computers via USB storage which avoids exposing the offline computer to a network-based attack.<br />
<br />
Deterministic wallets implemented by hardware wallets ([[TREZOR]]) keep the generated private keys offline and do not expose them to the computer even when spending coins.<br />
<br />
==Types==<br />
<br />
===Type 1 deterministic wallet===<br />
A type 1 deterministic wallet is a simple method of generating addresses from a known starting string, as such it does not allow advanced features such as a Master Public Key. To generate a private key take SHA256(string + n), where n is an ASCII-coded number that starts from 1 and increments as additional keys are needed. <br />
<br />
This type of wallet can be created by Casascius Bitcoin Address Utility.<br />
<br />
===Type 2 hierarchical deterministic wallet===<br />
This wallet type is described in [[BIP 0032]] and is fully implemented in [[TREZOR]], [[Electrum]] and [[CarbonWallet]]. The seed is a random 128 bit value presented to the user as a 12 word mnemonic using common English words. The seed is used after 100,000 rounds of SHA256 to slow down attacks against weak user-chosen strings. [https://bitcointalk.org/index.php?topic=330672.msg3547258#msg3547258]. <br />
<br />
The initial description and workings of this wallet type is credited to Gregory Maxwell. [https://bitcointalk.org/index.php?topic=19137.msg239768#msg239768]<br />
<br />
===Armory deterministic wallet===<br />
[[Armory]] has its own Type-2 deterministic wallet format based on a "root key" and a "chain code." Earlier versions of Armory required backing up both the "root key" and "chaincode," while newer versions start deriving the chaincode from the private key in a non-reversible way. These newer Armory wallets (0.89+) only require the single, 256-bit root key. This older format is intended to be phased out in favor of the standard BIP0032 format. [https://bitcointalk.org/index.php?topic=351099.msg3770818#msg3770818]</div>Norillhttps://tests.bitcoin.it/w/index.php?title=Scalability&diff=53179Scalability2014-11-23T21:09:45Z<p>Norill: </p>
<hr />
<div>The core Bitcoin network cannot scale to much higher transaction rates than are seen today without changing a core principle of the bitcoin protocol as defined in the Satoshi white paper, and assuming that nodes in the network are primarily running on high end servers rather than desktops. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this). A configuration in which the vast majority of users sync lightweight clients to more powerful backbone nodes is capable of scaling to millions of users and tens of thousands of transactions per second.<br />
<br />
==Scalability targets==<br />
<br />
VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 47,000 tps. [http://www.visa.com/blogarchives/us/2013/10/10/stress-test-prepares-visanet-for-the-most-wonderful-time-of-the-year/index.html]<br />
<br />
PayPal, in contrast, handles around 10 million transactions per day for an average of 115 tps. [https://www.paypal-media.com/about]<br />
<br />
Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.<br />
<br />
==Current bottlenecks==<br />
<br />
Today the Bitcoin network is restricted to a sustained rate of 7 tps due to the bitcoin protocol restricting block sizes to 1MB.<br />
<br />
==CPU==<br />
<br />
The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.<br />
<br />
The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some ECDSA signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.<br />
<br />
Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core [http://ark.intel.com/products/53469 Intel Core i7-2670QM 2.2Ghz processor]. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.<br />
<br />
As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity for signature checking unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2012 the network is handling 0.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.<br />
<br />
Of course Bitcoin does other things beyond signature checking, most obviously, managing the database. We use LevelDB which does the bulk of the heavy lifting on a separate thread, and is capable of very high read/write loads. Overall Bitcoin's CPU usage is dominated by ECDSA.<br />
<br />
==Network==<br />
<br />
Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.<br />
<br />
That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.<br />
<br />
This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.<br />
<br />
When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.<br />
<br />
==Storage==<br />
<br />
At very high transaction rates each block can be over half a gigabyte in size.<br />
<br />
It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.<br />
<br />
Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.<br />
<br />
The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. It is quite possible that the set will always fit in memory on dedicated server class machines, if hardware advances faster than Bitcoin usage does.<br />
<br />
==Optimizations==<br />
<br />
The description above applies to the current software with only minor optimizations assumed (the type that can and have been done by one man in a few weeks). <br />
<br />
However there is potential for even greater optimizations to be made in future, at the cost of some additional complexity.<br />
<br />
===CPU===<br />
<br />
Pieter Wuille has implemented a custom verifier tuned for secp256k1 that can go beyond 20,000 signature verifications per second. It would require careful review by professional cryptographers to gain as much confidence as OpenSSL, but this can easily halve CPU load.<br />
<br />
Algorithms exist to accelerate batch verification over elliptic curve signatures. This means if there are several inputs that are signing with the same key, it's possible to check their signatures simultaneously for another 9x speedup. This is a somewhat more complex implementation, however, it can work with existing signatures (clients don't need upgrading).<br />
<br />
Newly developed digital signature algorithms, like [http://ed25519.cr.yp.to/ed25519-20110705.pdf ed25519] have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a chain fork. This ECC algorithm has also been shown to be [http://eprint.iacr.org/2014/198 easily accelerated using GPUs], yielding scalar point multiplication times of less than a microsecond (i.e. a million point multiplications per second).<br />
<br />
At these speeds it is likely that disk and memory bandwidth would become the primary limiting factor, rather than signature checking.<br />
<br />
===Simplified payment verification===<br />
<!-- "Simplified payment verification" redirects here. Update the redirect if you change the section title --><br />
<br />
It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. [[bitcoinj]] is an implementation of this mode.<br />
<br />
In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block. <br />
<br />
As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg. you only really need to store as low as 2016 headers).<br />
<br />
The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.<br />
<br />
Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.<br />
<br />
See also: [[Thin Client Security]].<br />
<br />
== Related work ==<br />
There are a few proposals for optimizing Bitcoin's scalability. Some of these require an alt-chain / hard fork.<br />
<br />
* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"<br />
* [http://www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.<br />
<br />
[[Category:Technical]]</div>Norillhttps://tests.bitcoin.it/w/index.php?title=Paper_wallet&diff=48607Paper wallet2014-07-03T21:43:39Z<p>Norill: typo</p>
<hr />
<div>A '''paper wallet''' is a mechanism for storing bitcoins offline as a physical document that can be secured like cash or anything else of real-world value. Paper wallets are generally created by printing a brand new public address and private key onto paper, and then sending bitcoins from a "live" wallet to the printed wallet's public address for safekeeping. If good security practices are followed, paper wallets are one of the safest ways to store Bitcoins. <br />
<br />
__TOC__<br />
<br />
==Producing safe paper wallets==<br />
<br />
[[File:BitcoinPaperWallet-sample.jpg|thumb|right|300px|Paper wallet with private key secured beneath folds [[BitcoinPaperWallet|BitcoinPaperWallet.com]] ]]<br />
[[File:PaperWallets-offlineaddress-com.png|200px|thumb|right|Paper wallets from [[OfflineAddress|OfflineAddress.com]] ]]<br />
A Bitcoin [[private key]] can be represented in several formats. For paper wallets typically used format is Wallet Import Format (WIF), since keys represented that way are very short (51 characters) and thus easy to re-enter when importing or "sweeping" the wallet for withdrawal.<br />
<br />
Several tools exist for producing paper wallets, including [[BitAddress|BitAddress.org]], [[Bitcoin Address Utility]], [[BitcoinPaperWallet|BitcoinPaperWallet.com]], [[OfflineAddress|OfflineAddress.com]], [[SafePaperWallet|SafePaperWallet.com]], [[vanitygen]], and [[Cwallet]]. <br />
<br />
Care must be taken to securely generate paper wallets since an attacker can steal the present ''and future'' balance of a paper wallet if the private key is exposed, transmitted, or generated with insufficient entropy.<br />
<br />
Some services feature a free open-source client-side paper wallet generators written in JavaScript, which can be used offline. Using these generators is relatively safe when the source code hash can be checked against the author's signature. It's advisable to use those services from a [https://en.wikipedia.org/wiki/Live_CD live bootable CD], to ensure that private keys are not compromised by spyware. <br />
<br />
'''Recommendations:'''<br />
* Paper wallets should be produced on a computer not connected to the Internet.<br />
* Be aware that malware often allows a remote third party to view your screen and see your keystrokes, and these can compromise the integrity of your paper wallet. Also consider that antivirus software cannot completely rule out the possibility of malware. However, booting from a [https://en.wikipedia.org/wiki/Live_CD live disc] prevents malware from running.<br />
* The private keys of paper wallets should never be saved to a computer hard drive. You should also never scan your paper wallet into your computer or type the private keys or save them in e-mail, except at the moment you are redeeming the balance.<br />
* If possible, the private key of a paper wallet should be kept hidden, for example by using BIP38 encryption, or by folding the paper to hide the private key so that a photograph or photocopy of the wallet will not reveal or replicate the private key.<br />
* A web-based paper wallet generator should be written such that that all of the generation happens on your computer, not the web server. Ideally, the HTML/JavaScript for the web generator should be downloaded to your computer, verified, and then run "locally" from an offline computer. Running a paper wallet generator directly from a live website is not recommended unless you can verify that the code has not been tampered with by computing the hash and comparing it with a signed hash by the author.<br />
* A paper wallet generator should use an appropriate source of random numbers (entropy). This means that the generated addresses aren't predictable. If the addresses come from a predictable or partially-predictable patterns like pseudorandom numbers <ref>[https://en.wikipedia.org/wiki/Pseudorandomness#Cryptography Pseudorandomness] '' is not enough for strong cryptography''</ref>, someone else who can predict the pattern can steal the balance. Ideally, randomness should to be human provided (i.e. using dice rolling or random mouse movements or key strokes.) When using a web-based generator it's important to ensure that both the web browser and the JavaScript code are taking advantage of the strongest cryptographic routines available.<ref>[http://www.w3.org/TR/WebCryptoAPI/ w3.org] ''WebCryptoAPI''</ref><br />
<br />
<br />
===Operating System Cache Security===<br />
<br />
The problem with printing out secure documents—even if your computer is 100% virus/trojan free—is that your printer driver and/or operating system may be keeping copies of the documents you print in a "spool" or print queue. If a hacker or virus gets into your computer and knows to look for these cache files, then they can get your private keys and sweep your paper wallets. Precautions to mitigate this type of attack include:<br />
<br />
* Enabling encryption of your entire filesystem so that cache files cannot be 'undeleted'.<br />
<br />
* Setting up a symbolic link from your OS spool directory (e.g. /private/var/spool/cups/cache/ on OS X) to a removable media volume (e.g. a SD card) and disconnecting it when not in use.<br />
<br />
* Using a live-boot CD instead of a regular hard drive OS install. This way when you reboot your computer, all cache files are deleted from memory and no jobs are ever written to disk.<ref>[https://bitcoinpaperwallet.com/#security BitcoinPaperWallet.com] ''Security Tips''</ref><br />
<br />
===Printer Security===<br />
<br />
Some advanced printers have internal storage (even hard drives) that preserve copies of printouts. This is a risk if someone gets access to your printer, or if you dispose of your printer. There is also the possibility that a smart enough printer can be hacked. (Consider [http://en.wikipedia.org/wiki/Stuxnet StuxNet] which was able to rewrite the firmware of non-computer devices indirectly connected to the Internet) If this concerns you, use a "dumb" printer, and never let your printer have access to the Internet or to an Internet-connected computer.<br />
<br />
==Redeeming Keys and Withdrawing Funds==<br />
<br />
Paper wallets are very different from "live" wallets such as the Bitcoin-QT client in that it is not possible to transfer (withdraw) a ''portion'' of a paper wallet's bitcoin balance. The only way to withdraw funds from a paper wallet is to import or "sweep" the ''entire'' balance of the paper wallet to a new address, typically a live wallet or online exchange. Once the transfer has been confirmed, ''the paper wallet should no longer be used''.<ref>[http://www.reddit.com/r/Bitcoin/comments/1c9xr7/psa_using_paper_wallets_understanding_change/ reddit.com] ''Using Paper Wallets and Understanding Change''</ref><br />
<br />
There are various methods for copying the private key data from a paper wallet to other wallets.<br />
bitcoind supports an "importprivkey" RPC method for this purpose.<br />
Bitcoin-Qt's debug console can also be used in a similar way (see also [[how to import private keys v7+]]).<br />
[[BlockChain.info]] and [[Armory]] can also import them directly into wallets.<br />
[[MtGox|Mt. Gox]] provides the ability to Add Funds using a private key:<br />
the exchange will then create a "sweep" transaction that spends any amount for that paper wallet address so that the amount is added to your account with them; it will also sweep to your account any bitcoins received to that address in the future as well.<br />
<br />
==References==<br />
<references /><br />
<br />
==See Also==<br />
<br />
* [[Private key]]<br />
<br />
* [[Securing_your_wallet#Paper_Wallets]]<br />
<br />
* [[How to import private keys]]<br />
<br />
* [https://blockchain.info/wallet/paper-tutorial Blockchain.info tutorial] on how to generate a paper wallet.<br />
<br />
[[Category:Security]]<br />
<br />
[[es:Monedero de papel]]</div>Norillhttps://tests.bitcoin.it/w/index.php?title=Pay_to_script_hash&diff=48447Pay to script hash2014-06-26T18:26:26Z<p>Norill: </p>
<hr />
<div>'''Pay to script hash''' transactions were standardised on [[BIP 0016|BIP 16]].<br />
<br />
== Addresses ==<br />
<br />
[[BIP 0013|BIP 13]] specifies the address format.<br />
<br />
== History ==<br />
<br />
342ftSRCvFHfCeFFBuz4xwbeqnDw6BGUey is a Bitcoin [[address]] notable for being the first [[P2SH]]-compatible address receiving bitcoins on the production network.<br />
Its payment was mined in [[block]] 160720.</div>Norillhttps://tests.bitcoin.it/w/index.php?title=Script&diff=48306Script2014-06-21T13:47:13Z<p>Norill: Removed useless info</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 />
=== Standard Generation Transaction (pay-to-pubkey) ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. 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 />
Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.<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>Norillhttps://tests.bitcoin.it/w/index.php?title=Script&diff=48300Script2014-06-21T00:56:42Z<p>Norill: more info on flow control ops, formatting</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. True is removed, but false is not.<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 />
=== Standard Generation Transaction (pay-to-pubkey) ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. 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 />
Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.<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>Norillhttps://tests.bitcoin.it/w/index.php?title=Script&diff=39730Script2013-07-22T20:37:59Z<p>Norill: /* Provably Unspendable/Prunable Outputs */ removed false information</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 />
Scripts are big-endian.<br />
<br />
The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). 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.<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. True is removed, but false is not.<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 Currently disabled is present in a script, it should 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. ''Currently 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. ''Currently 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. ''Currently 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. ''Currently disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Returns the length of the input string.<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
If any opcode marked as Currently disabled is present in a script, it should 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. ''Currently 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. ''Currently 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. ''Currently 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. ''Currently 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 should abort and fail. <br />
If any opcode marked as ''Currently disabled'' is present in a script - it should 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. ''Currently disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''Currently 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. ''Currently disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''Currently 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. ''Currently 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. ''Currently 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. ''Currently 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.<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-script-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 />
=== Standard Generation Transaction (pay-to-pubkey) ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. 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 />
=== 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>Norillhttps://tests.bitcoin.it/w/index.php?title=Script&diff=37019Script2013-04-14T22:47:06Z<p>Norill: </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 />
Scripts are big-endian.<br />
<br />
The stacks hold byte vectors. Byte vectors are interpreted as little-endian variable-length integers with the most significant bit determining the sign of the integer. Thus 0x81 represents -1. 0x80 is another representation of zero (so called negative 0). 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.<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. True is removed, but false is not.<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 />
{| 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. ''Currently 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. ''Currently 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. ''Currently 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. ''Currently disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Returns the length of the input string.<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''Currently 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. ''Currently 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. ''Currently 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. ''Currently 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 />
{| 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. ''Currently disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''Currently 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. ''Currently disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''Currently 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. ''Currently 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. ''Currently 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. ''Currently 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.<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 ===<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 />
=== Standard Generation Transaction ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key. By default the reference implementation uses this form for coinbase payment, and scriptPubKeys of this transaction form are recognized as payments to user. 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. eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 is an example, and acts to donate 0.125BTC to the miner who mined the transaction. Another use is to add data to a transaction, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc<br />
<br />
Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet.<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, as 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 />
=== Transaction with a message ===<br />
<br />
It's possible to add arbitrary data to any transaction by just adding some data along with OP_DROP. Scripts are limited to 10,000 bytes and 201 instructions, and each individual instruction/value is limited to 520 bytes.<br />
<br />
scriptPubKey: <message> OP_DROP <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <message> OP_DROP <pubKey> OP_CHECKSIG<br />
|<br />
|-<br />
|<sig><br />
|<message> OP_DROP <pubKey> OP_CHECKSIG<br />
|scriptSig added to the stack.<br />
|-<br />
|<sig> <message><br />
|OP_DROP <pubKey> OP_CHECKSIG<br />
|The message has been put.<br />
|-<br />
|<sig><br />
|<pubKey> OP_CHECKSIG<br />
|Top stack item has been removed.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
|Checking signature against the public key.<br />
|-<br />
|true<br />
|Empty.<br />
|Stack holds the value of signature check now.<br />
|}<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>Norillhttps://tests.bitcoin.it/w/index.php?title=Talk:Script&diff=37014Talk:Script2013-04-14T22:32:35Z<p>Norill: </p>
<hr />
<div>xOP_IFDUP 115 0x73 x x / x x If the input is true or false, duplicate it.<br />
<br />
Shouldn't it be: "If the input is true, duplicate it."?<br />
--[[User:ThePiachu|ThePiachu]] 11:37, 20 December 2011 (GMT)<br />
<br />
The byte vectors in the stack are specified as being signed integers of variable-length. Then there's an explanation that these integers are considered false if they are either zero or negative zero, which is 0x80. For this to be the case, the elements should be represented in an old binary format called sign-magnitude, which is important to state explicitly, since today virtually all computers use two's complement as representation, and there's no such thing as a negative zero. There's even another representation, one's complement, where negative zero looks like 0xff.<br />
<br />
Reading the source code of the application, I see that arithmetic operations expect unsigned integers, for example, operations OP_2MUL and OP_2DIV are implemented as byte-shifting, which wouldn't work with signed representations.<br />
<br />
It seems to me that, at best, variable-length sign-magnitued integer format is only used for testing for truth, although I haven't read all the code yet.<br />
<br />
--[[User:Jpierre|Jean-Pierre Rupp]] 10:43, 4 March 2012 (GMT)<br />
<br />
== Provably Unspendable/Prunable Outputs ==<br />
<br />
If im not mistaken this kind of transaction would not result in donating the output to the miner. It would instead make the output unusable by anyone forever. In my opinion the best and easiest way to donate to miner is just transfer BTC between your own addresses and set a high fee. [[User:Norill|Norill]] ([[User talk:Norill|talk]]) 22:32, 14 April 2013 (GMT)</div>Norillhttps://tests.bitcoin.it/w/index.php?title=Talk:Script&diff=37012Talk:Script2013-04-14T22:29:56Z<p>Norill: /* Provably Unspendable/Prunable Outputs */ new section</p>
<hr />
<div>xOP_IFDUP 115 0x73 x x / x x If the input is true or false, duplicate it.<br />
<br />
Shouldn't it be: "If the input is true, duplicate it."?<br />
--[[User:ThePiachu|ThePiachu]] 11:37, 20 December 2011 (GMT)<br />
<br />
The byte vectors in the stack are specified as being signed integers of variable-length. Then there's an explanation that these integers are considered false if they are either zero or negative zero, which is 0x80. For this to be the case, the elements should be represented in an old binary format called sign-magnitude, which is important to state explicitly, since today virtually all computers use two's complement as representation, and there's no such thing as a negative zero. There's even another representation, one's complement, where negative zero looks like 0xff.<br />
<br />
Reading the source code of the application, I see that arithmetic operations expect unsigned integers, for example, operations OP_2MUL and OP_2DIV are implemented as byte-shifting, which wouldn't work with signed representations.<br />
<br />
It seems to me that, at best, variable-length sign-magnitued integer format is only used for testing for truth, although I haven't read all the code yet.<br />
<br />
--[[User:Jpierre|Jean-Pierre Rupp]] 10:43, 4 March 2012 (GMT)<br />
<br />
== Provably Unspendable/Prunable Outputs ==<br />
<br />
If im not mistaken this kind of transaction would not result in donating the output to the miner. It would instead make the output unusable by anyone forever. In my opinion the best and easiest way to donate to miner is just transfer BTC between your own addresses and set a high fee.</div>Norill