https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Occupy+paul+st&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T12:46:35ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=OP_RETURN&diff=60332OP RETURN2016-02-08T17:41:00Z<p>Occupy paul st: </p>
<hr />
<div>OP_RETURN is a [[script]] opcode used to mark a transaction output as invalid. Since the data after OP_RETURN are irrelevant to Bitcoin payments, arbitrary data can be added into the output after an OP_RETURN. Since any outputs with OP_RETURN are provably unspendable, OP_RETURN outputs can be used to [[Proof of burn|burn]] bitcoins.<br />
<br />
Currently, the default Bitcoin client relays OP_RETURN transactions up to 80 bytes [https://github.com/bitcoin/bitcoin/search?utf8=%E2%9C%93&q=MAX_OP_RETURN_RELAYa], but does not provide a way for users to create OP_RETURN transactions.<br />
<br />
<br />
== Is storing data in the blockchain acceptable? ==<br />
Some members of the Bitcoin community believe that use of OP_RETURN violates the contract of Bitcoin, because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data. Despite this, use of OP_RETURN may continue unabated because there is no easy way to stop people from embedding arbitrary data in the blockchain if they want to, and OP_RETURN is reasonably efficient in terms of [http://i.imgur.com/VAGZWBK.png data bytes stored as a fraction of blockchain space consumed]. Compared to some other ways of storing data in the blockchain, OP_RETURN has the advantage of not creating bogus UTXO entries. [https://github.com/bitcoin/bitcoin/pull/5286 Discussion on GitHub pull request]<br />
<br />
From [https://bitcoin.org/en/release/v0.9.0#opreturn-and-data-in-the-block-chain Bitcoin Core release 0.9.0]:<br />
<blockquote><br />
This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin's UTXO database.<br />
<br />
Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.<br />
</blockquote><br />
<br />
<br />
== OP_RETURN applications ==<br />
OP_RETURN is used for writing human-language messages, digital asset proof-of-ownership, and storing data. Its use has been proposed for P2P application discovery. See the "prefixes" table below.<br />
<br />
<br />
== OP_RETURN prefixes ==<br />
Often, OP_RETURN transactions include a prefix to identify which protocol they belong to. There is no standardized method of claiming OP_RETURN prefixes, and not all OP_RETURN transactions use prefixes. At the time of writing, this wiki page is probably the most complete list of OP_RETURN prefixes. Note that this table is an attempt to catalog OP_RETURN prefixes that are already in use, *not* a system for reserving OP_RETURN prefixes!<br />
<br />
{| class="wikitable"<br />
|-<br />
! Prefix !! Protocol<br />
|-<br />
| SPK || [http://coinspark.org/developers/ CoinSpark]<br />
|-<br />
| DOCPROOF || [http://www.proofofexistence.com/ Proof of Existence]<br />
|-<br />
| CryptoTests- || [http://crypto-copyright.com/ Crypto Copyright]<br />
|-<br />
| CryptoProof- || [Crypto Copyright http://crypto-copyright.com/<br />
|-<br />
| BS || [http://blocksignit.com/ BlockSign]<br />
|-<br />
| OA || [https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki Open Assets]<br />
|-<br />
| STAMPD## || [http://stampd.io/ stampd]<br />
|-<br />
| Factom!! || [http://factom.org/ Factom]<br />
|-<br />
| FACTOM00 || [http://factom.org/ Factom]<br />
|-<br />
| Fa || [http://factom.org/ Factom]<br />
|-<br />
| FA || [http://factom.org/ Factom]<br />
|-<br />
| tradle || [http://tradle.io/ Tradle]<br />
|-<br />
| LaPreuve || [http://www.lapreuve.net/ LaPreuve]<br />
|-<br />
| hex:5888 || [http://blog.onename.com/blockstore-bitcoin/ Blockstore]<br />
|-<br />
| hex:5808 || [http://blog.onename.com/blockstore-bitcoin/ Blockstore]<br />
|-<br />
| id || [http://blog.onename.com/blockstore-bitcoin/ Blockstore]<br />
|-<br />
| BITPROOF || [https://bitproof.io/ Bitproof]<br />
|-<br />
| S1 || [https://stampery.co/ Stampery]<br />
|-<br />
| ASCRIBE || [https://www.ascribe.io/ Ascribe]<br />
|-<br />
| ProveBit || [https://github.com/thereal1024/ProveBit ProveBit]<br />
|-<br />
| EW || [http://eternitywall.it/ Eternity Wall]<br />
|-<br />
| CC || [http://colu.co/ Colu]<br />
|-<br />
| omni || [http://www.omnilayer.org/ Omni Layer]<br />
|-<br />
| MG || [http://monegraph.com/ Monegraph]<br />
|-<br />
| RMBd || [https://app.remembr.io/ Remembr]<br />
|-<br />
| RMBe || [https://app.remembr.io/ Remembr]<br />
|-<br />
| ORIGMY || [http://originalmy.com/ OriginalMy]<br />
|}<br />
<br />
<br />
== External resources on OP_RETURN ==<br />
=== Viewing OP_RETURN ===<br />
* [http://coinsecrets.org/ coinsecrets.org]: An OP_RETURN transaction explorer]<br />
* [http://bitcoinstrings.com/ bitcoinstrings.com]: A site showing raw strings in Bitcoin transactions<br />
<br />
=== Explaining OP_RETURN ===<br />
* [https://github.com/coinspark/python-OP_RETURN python-OP_RETURN]<br />
* [http://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like StackExchange: Explanation of what an OP_RETURN transaction looks like]<br />
* [http://www.slideshare.net/coinspark/bitcoin-2-and-opreturns-the-blockchain-as-tcpip Metadata in the Blockchain: The OP_RETURN Explosion]<br />
* [http://wlangiewicz.com/blog/2014/10/24/how-to-put-custom-messages-into-bitcoin-blockchain-op-return/ How to Put Custom Messages Into Bitcoin Blockchain - OP_RETURN]</div>Occupy paul sthttps://tests.bitcoin.it/w/index.php?title=OP_RETURN&diff=59795OP RETURN2016-01-02T11:28:09Z<p>Occupy paul st: Add applications, organize external resources</p>
<hr />
<div>OP_RETURN is a [[script]] opcode used to mark a transaction output as invalid. Since the data after OP_RETURN are irrelevant to Bitcoin payments, arbitrary data can be added into the transaction by following the OP_RETURN with an OP_PUSHDATA. Since any outputs with OP_RETURN are provably unspendable, OP_RETURN outputs can be used to [[Proof of burn|burn]] bitcoins.<br />
<br />
Currently, the default Bitcoin client relays OP_RETURN transactions up to 80 bytes [https://github.com/bitcoin/bitcoin/search?utf8=%E2%9C%93&q=MAX_OP_RETURN_RELAYa], but does not provide a way for users to create OP_RETURN transactions.<br />
<br />
<br />
== Is storing data in the blockchain acceptable? ==<br />
Some members of the Bitcoin community believe that use of OP_RETURN violates the contract of Bitcoin, because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data. Despite this, use of OP_RETURN may continue unabated because there is no easy way to stop people from embedding arbitrary data in the blockchain if they want to, and OP_RETURN is reasonably efficient in terms of [http://i.imgur.com/VAGZWBK.png data bytes stored as a fraction of blockchain space consumed]. Compared to some other ways of storing data in the blockchain, OP_RETURN has the advantage of not creating bogus UTXO entries. [https://github.com/bitcoin/bitcoin/pull/5286 Discussion on GitHub pull request]<br />
<br />
From [https://bitcoin.org/en/release/v0.9.0#opreturn-and-data-in-the-block-chain Bitcoin Core release 0.9.0]:<br />
<blockquote><br />
This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin's UTXO database.<br />
<br />
Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.<br />
</blockquote><br />
<br />
<br />
== OP_RETURN applications ==<br />
OP_RETURN is used for writing human-language messages, digital asset proof-of-ownership, and storing data. Its use has been proposed for P2P application discovery. See the "prefixes" table below.<br />
<br />
<br />
== OP_RETURN prefixes ==<br />
Often, OP_RETURN transactions include a prefix to identify which protocol they belong to. There is no standardized method of claiming OP_RETURN prefixes, and not all OP_RETURN transactions use prefixes. At the time of writing, this wiki page is probably the most complete list of OP_RETURN prefixes. Note that this table is an attempt to catalog OP_RETURN prefixes that are already in use, *not* a system for reserving OP_RETURN prefixes!<br />
<br />
{| class="wikitable"<br />
|-<br />
! Prefix !! Protocol<br />
|-<br />
| SPK || [http://coinspark.org/developers/ CoinSpark]<br />
|-<br />
| DOCPROOF || [http://www.proofofexistence.com/ Proof of Existence]<br />
|-<br />
| CryptoTests- || [http://crypto-copyright.com/ Crypto Copyright]<br />
|-<br />
| CryptoProof- || [Crypto Copyright http://crypto-copyright.com/<br />
|-<br />
| BS || [http://blocksignit.com/ BlockSign]<br />
|-<br />
| OA || [https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki Open Assets]<br />
|-<br />
| STAMPD## || [http://stampd.io/ stampd]<br />
|-<br />
| Factom!! || [http://factom.org/ Factom]<br />
|-<br />
| FACTOM00 || [http://factom.org/ Factom]<br />
|-<br />
| Fa || [http://factom.org/ Factom]<br />
|-<br />
| FA || [http://factom.org/ Factom]<br />
|-<br />
| tradle || [http://tradle.io/ Tradle]<br />
|-<br />
| LaPreuve || [http://www.lapreuve.net/ LaPreuve]<br />
|-<br />
| hex:5888 || [http://blog.onename.com/blockstore-bitcoin/ Blockstore]<br />
|-<br />
| hex:5808 || [http://blog.onename.com/blockstore-bitcoin/ Blockstore]<br />
|-<br />
| id || [http://blog.onename.com/blockstore-bitcoin/ Blockstore]<br />
|-<br />
| BITPROOF || [https://bitproof.io/ Bitproof]<br />
|-<br />
| S1 || [https://stampery.co/ Stampery]<br />
|-<br />
| ASCRIBE || [https://www.ascribe.io/ Ascribe]<br />
|-<br />
| ProveBit || [https://github.com/thereal1024/ProveBit ProveBit]<br />
|-<br />
| EW || [http://eternitywall.it/ Eternity Wall]<br />
|-<br />
| CC || [http://colu.co/ Colu]<br />
|-<br />
| omni || [http://www.omnilayer.org/ Omni Layer]<br />
|-<br />
| MG || [http://monegraph.com/ Monegraph]<br />
|-<br />
| RMBd || [https://app.remembr.io/ Remembr]<br />
|-<br />
| RMBe || [https://app.remembr.io/ Remembr]<br />
|-<br />
| ORIGMY || [http://originalmy.com/ OriginalMy]<br />
|}<br />
<br />
<br />
== External resources on OP_RETURN ==<br />
=== Viewing OP_RETURN ===<br />
* [http://coinsecrets.org/ coinsecrets.org]: An OP_RETURN transaction explorer]<br />
* [http://bitcoinstrings.com/ bitcoinstrings.com]: A site showing raw strings in Bitcoin transactions<br />
<br />
=== Explaining OP_RETURN ===<br />
* [https://github.com/coinspark/python-OP_RETURN python-OP_RETURN]<br />
* [http://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like StackExchange: Explanation of what an OP_RETURN transaction looks like]<br />
* [http://www.slideshare.net/coinspark/bitcoin-2-and-opreturns-the-blockchain-as-tcpip Metadata in the Blockchain: The OP_RETURN Explosion]<br />
* [http://wlangiewicz.com/blog/2014/10/24/how-to-put-custom-messages-into-bitcoin-blockchain-op-return/ How to Put Custom Messages Into Bitcoin Blockchain - OP_RETURN]</div>Occupy paul sthttps://tests.bitcoin.it/w/index.php?title=OP_RETURN&diff=59788OP RETURN2016-01-01T14:37:53Z<p>Occupy paul st: Add quote from Bitcoin 0.9.0 release</p>
<hr />
<div>OP_RETURN is a [[script]] opcode used to mark a transaction output as invalid. Since the data after OP_RETURN are irrelevant to Bitcoin payments, arbitrary data can be added into the transaction by following the OP_RETURN with an OP_PUSHDATA. Since any outputs with OP_RETURN are provably unspendable, OP_RETURN outputs can be used to [[Proof of burn|burn]] bitcoins.<br />
<br />
Currently, the default Bitcoin client relays OP_RETURN transactions up to 80 bytes [https://github.com/bitcoin/bitcoin/search?utf8=%E2%9C%93&q=MAX_OP_RETURN_RELAYa], but does not provide a way for users to create OP_RETURN transactions.<br />
<br />
== Philosophy ==<br />
Some members of the Bitcoin community believe that use of OP_RETURN violates the contract of Bitcoin, because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data. Despite this, use of OP_RETURN may continue unabated because there is no easy way to stop people from embedding arbitrary data in the blockchain if they want to, and OP_RETURN is reasonably efficient in terms of [http://i.imgur.com/VAGZWBK.png data bytes stored as a fraction of blockchain space consumed]. Compared to some other ways of storing data in the blockchain, OP_RETURN has the advantage of not creating bogus UTXO entries. [https://github.com/bitcoin/bitcoin/pull/5286 Discussion on GitHub pull request]<br />
<br />
From [https://bitcoin.org/en/release/v0.9.0#opreturn-and-data-in-the-block-chain Bitcoin Core release 0.9.0]:<br />
<blockquote><br />
This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin's UTXO database.<br />
<br />
Storing arbitrary data in the blockchain is still a bad idea; it is less costly and far more efficient to store non-currency data elsewhere.<br />
</blockquote><br />
<br />
== Resources on OP_RETURN ==<br />
* [http://coinsecrets.org/ coinsecrets.org]: An OP_RETURN transaction explorer<br />
* [https://github.com/coinspark/python-OP_RETURN python-OP_RETURN]<br />
* [http://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like StackExchange: Explanation of what an OP_RETURN transaction looks like]<br />
* [http://www.slideshare.net/coinspark/bitcoin-2-and-opreturns-the-blockchain-as-tcpip Metadata in the Blockchain: The OP_RETURN Explosion]<br />
* [http://wlangiewicz.com/blog/2014/10/24/how-to-put-custom-messages-into-bitcoin-blockchain-op-return/ How to Put Custom Messages Into Bitcoin Blockchain - OP_RETURN]<br />
<br />
== OP_RETURN prefixes ==<br />
Often, OP_RETURN transactions include a prefix to identify which protocol they belong to. There is no standardized method of claiming OP_RETURN prefixes, and not all OP_RETURN transactions use prefixes. At the time of writing, this wiki page is probably the most complete list of OP_RETURN prefixes. Note that this table is an attempt to catalog OP_RETURN prefixes that are already in use, *not* a system for reserving OP_RETURN prefixes!<br />
<br />
{| class="wikitable"<br />
|-<br />
! Prefix !! Protocol<br />
|-<br />
| SPK || [http://coinspark.org/developers/ CoinSpark]<br />
|-<br />
| DOCPROOF || [http://www.proofofexistence.com/ Proof of Existence]<br />
|-<br />
| CryptoTests- || [http://crypto-copyright.com/ Crypto Copyright]<br />
|-<br />
| CryptoProof- || [Crypto Copyright http://crypto-copyright.com/<br />
|-<br />
| BS || [http://blocksignit.com/ BlockSign]<br />
|-<br />
| OA || [https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki Open Assets]<br />
|-<br />
| STAMPD## || [http://stampd.io/ stampd]<br />
|-<br />
| Factom!! || [http://factom.org/ Factom]<br />
|-<br />
| FACTOM00 || [http://factom.org/ Factom]<br />
|-<br />
| Fa || [http://factom.org/ Factom]<br />
|-<br />
| FA || [http://factom.org/ Factom]<br />
|-<br />
| tradle || [http://tradle.io/ Tradle]<br />
|-<br />
| LaPreuve || [http://www.lapreuve.net/ LaPreuve]<br />
|-<br />
| hex:5888 || [http://blog.onename.com/blockstore-bitcoin/ Blockstore]<br />
|-<br />
| hex:5808 || [http://blog.onename.com/blockstore-bitcoin/ Blockstore]<br />
|-<br />
| id || [http://blog.onename.com/blockstore-bitcoin/ Blockstore]<br />
|-<br />
| BITPROOF || [https://bitproof.io/ Bitproof]<br />
|-<br />
| S1 || [https://stampery.co/ Stampery]<br />
|-<br />
| ASCRIBE || [https://www.ascribe.io/ Ascribe]<br />
|-<br />
| ProveBit || [https://github.com/thereal1024/ProveBit ProveBit]<br />
|-<br />
| EW || [http://eternitywall.it/ Eternity Wall]<br />
|-<br />
| CC || [http://colu.co/ Colu]<br />
|-<br />
| omni || [http://www.omnilayer.org/ Omni Layer]<br />
|-<br />
| MG || [http://monegraph.com/ Monegraph]<br />
|-<br />
| RMBd || [https://app.remembr.io/ Remembr]<br />
|-<br />
| RMBe || [https://app.remembr.io/ Remembr]<br />
|-<br />
| ORIGMY || [http://originalmy.com/ OriginalMy]<br />
|}<br />
{{DISPLAYTITLE:OP_RETURN}}</div>Occupy paul sthttps://tests.bitcoin.it/w/index.php?title=OP_RETURN&diff=59712OP RETURN2015-12-29T11:18:34Z<p>Occupy paul st: Add known prefixes table from Gideon Green</p>
<hr />
<div>OP_RETURN is a [[script]] opcode used to mark a transaction output as invalid. Since the data after OP_RETURN are irrelevant to Bitcoin payments, arbitrary data can be added into the transaction by following the OP_RETURN with an OP_PUSHDATA. Since any outputs with OP_RETURN are provably unspendable, OP_RETURN outputs can be used to [[Proof of burn|burn]] bitcoins.<br />
<br />
Currently, the default Bitcoin client relays OP_RETURN transactions up to 80 bytes [https://github.com/bitcoin/bitcoin/search?utf8=%E2%9C%93&q=MAX_OP_RETURN_RELAYa], but does not provide a way for users to create OP_RETURN transactions.<br />
<br />
== Philosophy ==<br />
Some members of the Bitcoin community believe that use of OP_RETURN violates the contract of Bitcoin, because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data. Despite this, use of OP_RETURN may continue unabated because there is no easy way to stop people from embedding arbitrary data in the blockchain if they want to, and OP_RETURN is reasonably efficient in terms of [http://i.imgur.com/VAGZWBK.png data bytes stored as a fraction of blockchain space consumed]. Compared to some other ways of storing data in the blockchain, OP_RETURN has the advantage of not creating bogus UTXO entries. [https://github.com/bitcoin/bitcoin/pull/5286 Discussion on GitHub pull request]<br />
<br />
== Resources on OP_RETURN ==<br />
* [http://coinsecrets.org/ coinsecrets.org]: An OP_RETURN transaction explorer<br />
* [https://github.com/coinspark/python-OP_RETURN python-OP_RETURN]<br />
* [http://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like StackExchange: Explanation of what an OP_RETURN transaction looks like]<br />
* [http://www.slideshare.net/coinspark/bitcoin-2-and-opreturns-the-blockchain-as-tcpip Metadata in the Blockchain: The OP_RETURN Explosion]<br />
* [http://wlangiewicz.com/blog/2014/10/24/how-to-put-custom-messages-into-bitcoin-blockchain-op-return/ How to Put Custom Messages Into Bitcoin Blockchain - OP_RETURN]<br />
<br />
== OP_RETURN prefixes ==<br />
Often, OP_RETURN transactions include a prefix to identify which protocol they belong to. There is no standardized method of claiming OP_RETURN prefixes, and not all OP_RETURN transactions use prefixes. At the time of writing, this wiki page is probably the most complete list of OP_RETURN prefixes. Note that this table is an attempt to catalog OP_RETURN prefixes that are already in use, *not* a system for reserving OP_RETURN prefixes!<br />
<br />
{| class="wikitable"<br />
|-<br />
! Prefix !! Protocol<br />
|-<br />
| SPK || [http://coinspark.org/developers/ CoinSpark]<br />
|-<br />
| DOCPROOF || [http://www.proofofexistence.com/ Proof of Existence]<br />
|-<br />
| CryptoTests- || [http://crypto-copyright.com/ Crypto Copyright]<br />
|-<br />
| CryptoProof- || [Crypto Copyright http://crypto-copyright.com/<br />
|-<br />
| BS || [http://blocksignit.com/ BlockSign]<br />
|-<br />
| OA || [https://github.com/OpenAssets/open-assets-protocol/blob/master/specification.mediawiki Open Assets]<br />
|-<br />
| STAMPD## || [http://stampd.io/ stampd]<br />
|-<br />
| Factom!! || [http://factom.org/ Factom]<br />
|-<br />
| FACTOM00 || [http://factom.org/ Factom]<br />
|-<br />
| Fa || [http://factom.org/ Factom]<br />
|-<br />
| FA || [http://factom.org/ Factom]<br />
|-<br />
| tradle || [http://tradle.io/ Tradle]<br />
|-<br />
| LaPreuve || [http://www.lapreuve.net/ LaPreuve]<br />
|-<br />
| hex:5888 || [http://blog.onename.com/blockstore-bitcoin/ Blockstore]<br />
|-<br />
| hex:5808 || [http://blog.onename.com/blockstore-bitcoin/ Blockstore]<br />
|-<br />
| id || [http://blog.onename.com/blockstore-bitcoin/ Blockstore]<br />
|-<br />
| BITPROOF || [https://bitproof.io/ Bitproof]<br />
|-<br />
| S1 || [https://stampery.co/ Stampery]<br />
|-<br />
| ASCRIBE || [https://www.ascribe.io/ Ascribe]<br />
|-<br />
| ProveBit || [https://github.com/thereal1024/ProveBit ProveBit]<br />
|-<br />
| EW || [http://eternitywall.it/ Eternity Wall]<br />
|-<br />
| CC || [http://colu.co/ Colu]<br />
|-<br />
| omni || [http://www.omnilayer.org/ Omni Layer]<br />
|-<br />
| MG || [http://monegraph.com/ Monegraph]<br />
|-<br />
| RMBd || [https://app.remembr.io/ Remembr]<br />
|-<br />
| RMBe || [https://app.remembr.io/ Remembr]<br />
|-<br />
| ORIGMY || [http://originalmy.com/ OriginalMy]<br />
|}</div>Occupy paul sthttps://tests.bitcoin.it/w/index.php?title=OP_RETURN&diff=59711OP RETURN2015-12-29T01:48:46Z<p>Occupy paul st: Add Omni Layer, note Open Assets prefix</p>
<hr />
<div>OP_RETURN is a [[script]] opcode used to mark a transaction output as invalid. Since the data after OP_RETURN are irrelevant to Bitcoin payments, arbitrary data can be added into the transaction by following the OP_RETURN with an OP_PUSHDATA. Since any outputs with OP_RETURN are provably unspendable, OP_RETURN outputs can be used to [[Proof of burn|burn]] bitcoins.<br />
<br />
Currently, the default Bitcoin client relays OP_RETURN transactions up to 40 bytes, but does not provide a way to create OP_RETURN transactions.<br />
<br />
== Philosophy ==<br />
Some members of the Bitcoin community believe that use of OP_RETURN violates the contract of Bitcoin, because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data. Despite this, use of OP_RETURN may continue unabated because there is no easy way to stop people from embedding arbitrary data in the blockchain, and OP_RETURN is an efficient way to do it. [[https://bitcointalk.org/index.php?topic=471928.0 bitcointalk discussion]]<br />
<br />
== Resources on OP_RETURN ==<br />
* [http://coinsecrets.org/ coinsecrets.org]: An OP_RETURN transaction explorer<br />
* [https://github.com/coinspark/python-OP_RETURN python-OP_RETURN]<br />
* [http://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like StackExchange: Explanation of what an OP_RETURN transaction looks like]<br />
* [http://www.slideshare.net/coinspark/bitcoin-2-and-opreturns-the-blockchain-as-tcpip Metadata in the Blockchain: The OP_RETURN Explosion]<br />
* [http://wlangiewicz.com/blog/2014/10/24/how-to-put-custom-messages-into-bitcoin-blockchain-op-return/ How to Put Custom Messages Into Bitcoin Blockchain - OP_RETURN]<br />
<br />
== OP_RETURN prefixes ==<br />
Often, OP_RETURN transactions include a prefix to identify which protocol they belong to. There is no standardized method of claiming OP_RETURN prefixes, and not all OP_RETURN transactions use prefixes. At the time of writing, this wiki page is probably the most complete list of OP_RETURN prefixes.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Prefix (Ascii-Encoded) !! Protocol/Owner !! Brief description<br />
|-<br />
| Fa || Factom || ?<br />
|-<br />
| CC || Colu || ?<br />
|-<br />
| OA || [https://github.com/OpenAssets/open-assets-protocol Open Assets] || Issuance and transfer of user-created assets<br />
|-<br />
| omni || Omni Layer || ?<br />
|-<br />
| MG || [https://monegraph.com Monegraph] || Digital work licensing<br />
|-<br />
| id || Blockstore || ?<br />
|-<br />
| ASCRIBE || [https://ascribe.io ASCRIBE] || Digital work licensing<br />
|-<br />
| ? || Counterparty || ?<br />
|}</div>Occupy paul sthttps://tests.bitcoin.it/w/index.php?title=Script&diff=59710Script2015-12-29T01:35:54Z<p>Occupy paul st: Add link to OP_RETURN</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, also known as opcodes, commands, or functions.<br />
<br />
There are some words which existed in very early versions of Bitcoin but were removed out of a concern that the client might have a bug in their implementation. This fear was motivated by a bug found in OP_LSHIFT which could crash any Bitcoin node if exploited, and by other bugs in how Script worked which allowed anyone to spend anyone's bitcoins. The removed opcodes are sometimes said to be "disabled" opcodes, but this is something of a misnomer because there is ''absolutely no way'' for anyone using Bitcoin to use these opcodes (they simply ''do not exist anymore'' in the protocol), and there are also no solid plans to ever re-enable all of these opcodes. They are listed here only for historical interest.<br />
<br />
New opcodes can be added by means of a carefully designed and executed [[softfork]] using OP_NOP1-OP_NOP10.<br />
<br />
False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.<br />
<br />
=== Constants ===<br />
When talking about scripts, these value-pushing words are usually omitted.<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_0, OP_FALSE<br />
|0<br />
|0x00<br />
|Nothing.<br />
|(empty value)<br />
|An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)<br />
|-<br />
|N/A<br />
|1-75<br />
|0x01-0x4b<br />
|(special)<br />
|data<br />
|The next ''opcode'' bytes is data to be pushed onto the stack<br />
|-<br />
|OP_PUSHDATA1<br />
|76<br />
|0x4c<br />
|(special)<br />
|data<br />
|The next byte contains the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA2<br />
|77<br />
|0x4d<br />
|(special)<br />
|data<br />
|The next two bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_PUSHDATA4<br />
|78<br />
|0x4e<br />
|(special)<br />
|data<br />
|The next four bytes contain the number of bytes to be pushed onto the stack.<br />
|-<br />
|OP_1NEGATE<br />
|79<br />
|0x4f<br />
|Nothing.<br />
| -1<br />
|The number -1 is pushed onto the stack.<br />
|-<br />
|OP_1, OP_TRUE<br />
|81<br />
|0x51<br />
|Nothing.<br />
|1<br />
|The number 1 is pushed onto the stack.<br />
|-<br />
|OP_2-OP_16<br />
|82-96<br />
|0x52-0x60<br />
|Nothing.<br />
|2-16<br />
|The number in the word name (2-16) is pushed onto the stack.<br />
|}<br />
<br />
=== Flow control ===<br />
<br />
{| class="wikitable"<br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_NOP<br />
|97<br />
|0x61<br />
|Nothing<br />
|Nothing<br />
|Does nothing.<br />
|-<br />
|OP_IF<br />
|99<br />
|0x63<br />
| colspan="2"|<expression> if [statements] [else [statements]]* endif<br />
|If the top stack value is not 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 / ''fail''<br />
|'''Marks transaction as invalid''' if top stack value is not true.<br />
|-<br />
|[[OP_RETURN]]<br />
|106<br />
|0x6a<br />
|Nothing<br />
|''fail''<br />
|'''Marks transaction as invalid'''. A standard way of attaching extra data to transactions is to add a zero-value output with a scriptPubKey consisting of OP_RETURN followed by exactly one pushdata op. Such outputs are provably unspendable, reducing their cost to the network. Currently it is usually considered non-standard (though valid) for a transaction to have more than one OP_RETURN output or an OP_RETURN output with more than one pushdata op.<br />
|}<br />
<br />
=== Stack ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_TOALTSTACK<br />
|107<br />
|0x6b<br />
|x1<br />
|(alt)x1<br />
|Puts the input onto the top of the alt stack. Removes it from the main stack.<br />
|-<br />
|OP_FROMALTSTACK<br />
|108<br />
|0x6c<br />
|(alt)x1<br />
|x1<br />
|Puts the input onto the top of the main stack. Removes it from the alt stack.<br />
|-<br />
|OP_IFDUP<br />
|115<br />
|0x73<br />
|x<br />
|x / x x<br />
|If the top stack value is not 0, duplicate it.<br />
|-<br />
|OP_DEPTH<br />
|116<br />
|0x74<br />
|Nothing<br />
|<Stack size><br />
|Puts the number of stack items onto the stack.<br />
|-<br />
|OP_DROP<br />
|117<br />
|0x75<br />
|x<br />
|Nothing<br />
|Removes the top stack item.<br />
|-<br />
|OP_DUP<br />
|118<br />
|0x76<br />
|x<br />
|x x<br />
|Duplicates the top stack item.<br />
|-<br />
|OP_NIP<br />
|119<br />
|0x77<br />
|x1 x2<br />
|x2<br />
|Removes the second-to-top stack item.<br />
|-<br />
|OP_OVER<br />
|120<br />
|0x78<br />
|x1 x2<br />
|x1 x2 x1<br />
|Copies the second-to-top stack item to the top.<br />
|-<br />
|OP_PICK<br />
|121<br />
|0x79<br />
|xn ... x2 x1 x0 <n><br />
|xn ... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is copied to the top.<br />
|-<br />
|OP_ROLL<br />
|122<br />
|0x7a<br />
|xn ... x2 x1 x0 <n><br />
|... x2 x1 x0 xn<br />
|The item ''n'' back in the stack is moved to the top.<br />
|-<br />
|OP_ROT<br />
|123<br />
|0x7b<br />
|x1 x2 x3<br />
|x2 x3 x1<br />
|The top three items on the stack are rotated to the left.<br />
|-<br />
|OP_SWAP<br />
|124<br />
|0x7c<br />
|x1 x2<br />
|x2 x1<br />
|The top two items on the stack are swapped.<br />
|-<br />
|OP_TUCK<br />
|125<br />
|0x7d<br />
|x1 x2<br />
|x2 x1 x2<br />
|The item at the top of the stack is copied and inserted before the second-to-top item.<br />
|-<br />
|OP_2DROP<br />
|109<br />
|0x6d<br />
|x1 x2<br />
|Nothing<br />
|Removes the top two stack items.<br />
|-<br />
|OP_2DUP<br />
|110<br />
|0x6e<br />
|x1 x2<br />
|x1 x2 x1 x2<br />
|Duplicates the top two stack items.<br />
|-<br />
|OP_3DUP<br />
|111<br />
|0x6f<br />
|x1 x2 x3<br />
|x1 x2 x3 x1 x2 x3<br />
|Duplicates the top three stack items.<br />
|-<br />
|OP_2OVER<br />
|112<br />
|0x70<br />
|x1 x2 x3 x4<br />
|x1 x2 x3 x4 x1 x2<br />
|Copies the pair of items two spaces back in the stack to the front.<br />
|-<br />
|OP_2ROT<br />
|113<br />
|0x71<br />
|x1 x2 x3 x4 x5 x6<br />
|x3 x4 x5 x6 x1 x2<br />
|The fifth and sixth items back are moved to the top of the stack.<br />
|-<br />
|OP_2SWAP<br />
|114<br />
|0x72<br />
|x1 x2 x3 x4<br />
|x3 x4 x1 x2<br />
|Swaps the top two pairs of items.<br />
|}<br />
<br />
=== Splice ===<br />
<br />
If any opcode marked as disabled is present in a script, it must abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CAT<br />
|126<br />
|0x7e<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Concatenates two strings. ''disabled.''<br />
|-<br />
|OP_SUBSTR<br />
|127<br />
|0x7f<br />
|in begin size<br />
|out<br />
|style="background:#D97171;"|Returns a section of a string. ''disabled.''<br />
|-<br />
|OP_LEFT<br />
|128<br />
|0x80<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters left of the specified point in a string. ''disabled.''<br />
|-<br />
|OP_RIGHT<br />
|129<br />
|0x81<br />
|in size<br />
|out<br />
|style="background:#D97171;"|Keeps only characters right of the specified point in a string. ''disabled.''<br />
|-<br />
|OP_SIZE<br />
|130<br />
|0x82<br />
|in<br />
|in size<br />
|Pushes the string length of the top element of the stack (without popping it).<br />
|}<br />
<br />
=== Bitwise logic ===<br />
<br />
If any opcode marked as disabled is present in a script, it must abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_INVERT<br />
|131<br />
|0x83<br />
|in<br />
|out<br />
|style="background:#D97171;"|Flips all of the bits in the input. ''disabled.''<br />
|-<br />
|OP_AND<br />
|132<br />
|0x84<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''and'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_OR<br />
|133<br />
|0x85<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''or'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_XOR<br />
|134<br />
|0x86<br />
|x1 x2<br />
|out<br />
|style="background:#D97171;"|Boolean ''exclusive or'' between each bit in the inputs. ''disabled.''<br />
|-<br />
|OP_EQUAL<br />
|135<br />
|0x87<br />
|x1 x2<br />
|True / false<br />
|Returns 1 if the inputs are exactly equal, 0 otherwise.<br />
|-<br />
|OP_EQUALVERIFY<br />
|136<br />
|0x88<br />
|x1 x2<br />
|Nothing / ''fail''<br />
|Same as OP_EQUAL, but runs OP_VERIFY afterward.<br />
|}<br />
<br />
=== Arithmetic ===<br />
<br />
Note: Arithmetic inputs are limited to signed 32-bit integers, but may overflow their output.<br />
<br />
If any input value for any of these commands is longer than 4 bytes, the script must abort and fail. <br />
If any opcode marked as ''disabled'' is present in a script - it must also abort and fail.<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_1ADD<br />
|139<br />
|0x8b<br />
|in<br />
|out<br />
|1 is added to the input.<br />
|-<br />
|OP_1SUB<br />
|140<br />
|0x8c<br />
|in<br />
|out<br />
|1 is subtracted from the input.<br />
|-<br />
|OP_2MUL<br />
|141<br />
|0x8d<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is multiplied by 2. ''disabled.''<br />
|-<br />
|OP_2DIV<br />
|142<br />
|0x8e<br />
|in<br />
|out<br />
|style="background:#D97171;"|The input is divided by 2. ''disabled.''<br />
|-<br />
|OP_NEGATE<br />
|143<br />
|0x8f<br />
|in<br />
|out<br />
|The sign of the input is flipped.<br />
|-<br />
|OP_ABS<br />
|144<br />
|0x90<br />
|in<br />
|out<br />
|The input is made positive.<br />
|-<br />
|OP_NOT<br />
|145<br />
|0x91<br />
|in<br />
|out<br />
|If the input is 0 or 1, it is flipped. Otherwise the output will be 0.<br />
|-<br />
|OP_0NOTEQUAL<br />
|146<br />
|0x92<br />
|in<br />
|out<br />
|Returns 0 if the input is 0. 1 otherwise.<br />
|-<br />
|OP_ADD<br />
|147<br />
|0x93<br />
|a b<br />
|out<br />
|a is added to b.<br />
|-<br />
|OP_SUB<br />
|148<br />
|0x94<br />
|a b<br />
|out<br />
|b is subtracted from a.<br />
|-<br />
|OP_MUL<br />
|149<br />
|0x95<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is multiplied by b. ''disabled.''<br />
|-<br />
|OP_DIV<br />
|150<br />
|0x96<br />
|a b<br />
|out<br />
|style="background:#D97171;"|a is divided by b. ''disabled.''<br />
|-<br />
|OP_MOD<br />
|151<br />
|0x97<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Returns the remainder after dividing a by b. ''disabled.''<br />
|-<br />
|OP_LSHIFT<br />
|152<br />
|0x98<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a left b bits, preserving sign. ''disabled.''<br />
|-<br />
|OP_RSHIFT<br />
|153<br />
|0x99<br />
|a b<br />
|out<br />
|style="background:#D97171;"|Shifts a right b bits, preserving sign. ''disabled.''<br />
|-<br />
|OP_BOOLAND<br />
|154<br />
|0x9a<br />
|a b<br />
|out<br />
|If both a and b are not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_BOOLOR<br />
|155<br />
|0x9b<br />
|a b<br />
|out<br />
|If a or b is not 0, the output is 1. Otherwise 0.<br />
|-<br />
|OP_NUMEQUAL<br />
|156<br />
|0x9c<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are equal, 0 otherwise.<br />
|-<br />
|OP_NUMEQUALVERIFY<br />
|157<br />
|0x9d<br />
|a b<br />
|Nothing / ''fail''<br />
|Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.<br />
|-<br />
|OP_NUMNOTEQUAL<br />
|158<br />
|0x9e<br />
|a b<br />
|out<br />
|Returns 1 if the numbers are not equal, 0 otherwise.<br />
|-<br />
|OP_LESSTHAN<br />
|159<br />
|0x9f<br />
|a b<br />
|out<br />
|Returns 1 if a is less than b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHAN<br />
|160<br />
|0xa0<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than b, 0 otherwise.<br />
|-<br />
|OP_LESSTHANOREQUAL<br />
|161<br />
|0xa1<br />
|a b<br />
|out<br />
|Returns 1 if a is less than or equal to b, 0 otherwise.<br />
|-<br />
|OP_GREATERTHANOREQUAL<br />
|162<br />
|0xa2<br />
|a b<br />
|out<br />
|Returns 1 if a is greater than or equal to b, 0 otherwise.<br />
|-<br />
|OP_MIN<br />
|163<br />
|0xa3<br />
|a b<br />
|out<br />
|Returns the smaller of a and b.<br />
|-<br />
|OP_MAX<br />
|164<br />
|0xa4<br />
|a b<br />
|out<br />
|Returns the larger of a and b.<br />
|-<br />
|OP_WITHIN<br />
|165<br />
|0xa5<br />
|x min max<br />
|out<br />
|Returns 1 if x is within the specified range (left-inclusive), 0 otherwise.<br />
|}<br />
<br />
=== Crypto ===<br />
<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_RIPEMD160<br />
|166<br />
|0xa6<br />
|in<br />
|hash<br />
|The input is hashed using RIPEMD-160.<br />
|-<br />
|OP_SHA1<br />
|167<br />
|0xa7<br />
|in<br />
|hash<br />
|The input is hashed using SHA-1.<br />
|-<br />
|OP_SHA256<br />
|168<br />
|0xa8<br />
|in<br />
|hash<br />
|The input is hashed using SHA-256.<br />
|-<br />
|OP_HASH160<br />
|169<br />
|0xa9<br />
|in<br />
|hash<br />
|The input is hashed twice: first with SHA-256 and then with RIPEMD-160.<br />
|-<br />
|OP_HASH256<br />
|170<br />
|0xaa<br />
|in<br />
|hash<br />
|The input is hashed two times with SHA-256.<br />
|-<br />
|OP_CODESEPARATOR<br />
|171<br />
|0xab<br />
|Nothing<br />
|Nothing<br />
|All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR.<br />
|-<br />
|[[OP_CHECKSIG]]<br />
|172<br />
|0xac<br />
|sig pubkey<br />
|True / false<br />
|The entire transaction's outputs, inputs, and script (from the most recently-executed OP_CODESEPARATOR to the end) are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise.<br />
|-<br />
|OP_CHECKSIGVERIFY<br />
|173<br />
|0xad<br />
|sig pubkey<br />
|Nothing / ''fail''<br />
|Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.<br />
|-<br />
|OP_CHECKMULTISIG<br />
|174<br />
|0xae<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 <number of public keys><br />
|True / False<br />
|Compares the first signature against each public key until it finds an ECDSA match. Starting with the subsequent public key, it compares the second signature against each remaining public key until it finds an ECDSA match. The process is repeated until all signatures have been checked or not enough public keys remain to produce a successful result. All signatures need to match a public key. Because public keys are not checked again if they fail any signature comparison, signatures must be placed in the scriptSig using the same order as their corresponding public keys were placed in the scriptPubKey or redeemScript. If all signatures are valid, 1 is returned, 0 otherwise. Due to a bug, one extra unused value is removed from the stack.<br />
|-<br />
|OP_CHECKMULTISIGVERIFY<br />
|175<br />
|0xaf<br />
|x sig1 sig2 ... <number of signatures> pub1 pub2 ... <number of public keys><br />
|Nothing / ''fail''<br />
|Same as OP_CHECKMULTISIG, but OP_VERIFY is executed afterward.<br />
|}<br />
<br />
=== Locktime ===<br />
{| class="wikitable" <br />
|-<br />
!Word<br />
!Opcode<br />
!Hex<br />
!Input<br />
!Output<br />
!Description<br />
|-<br />
|OP_CHECKLOCKTIMEVERIFY (previously OP_NOP2)<br />
|177<br />
|0xb1<br />
|Nothing<br />
|Nothing / ''fail''<br />
|'''Marks transaction as invalid''' if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed. Transaction is also invalid if 1. the stack is empty; or 2. the top stack item is negative; or 3. the top stack item is greater than or equal to 500000000 while the transaction's nLockTime field is less than 500000000, or vice versa; or 4. the input's nSequence field is equal to 0xffffffff. The precise semantics are described in [[BIP 0065]]<br />
|}<br />
<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_NOP3-OP_NOP10<br />
|176, 178-185<br />
|0xb0, 0xb2-0xb9<br />
|The word is ignored. Does not mark transaction as invalid.<br />
|}<br />
<br />
== Scripts ==<br />
This is a list of interesting scripts. Keep in mind that all constants actually use the data-pushing commands above. Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.<br />
<br />
=== Standard Transaction to Bitcoin address (pay-to-pubkey-hash) ===<br />
<br />
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
scriptSig: <sig> <pubKey><br />
<br />
To demonstrate how scripts look on the wire, here is a raw scriptPubKey:<br />
<pre> 76 A9 14<br />
OP_DUP OP_HASH160 Bytes to push<br />
<br />
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA 88 AC<br />
Data to push OP_EQUALVERIFY OP_CHECKSIG</pre><br />
<br />
Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.<br />
<br />
Here is how each word is processed:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
| <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Constants are added to the stack.<br />
|-<br />
|<sig> <pubKey> <pubKey><br />
| OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG <br />
| Top stack item is duplicated.<br />
|-<br />
|<sig> <pubKey> <pubHashA><br />
|<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG<br />
| Top stack item is hashed.<br />
|-<br />
|<sig> <pubKey> <pubHashA> <pubKeyHash><br />
|OP_EQUALVERIFY OP_CHECKSIG<br />
| Constant added.<br />
|-<br />
|<sig> <pubKey><br />
|OP_CHECKSIG<br />
| Equality is checked between the top two stack items.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Obsolete pay-to-pubkey transaction ===<br />
<br />
OP_CHECKSIG is used directly without first hashing the public key.<br />
This was used by early versions of Bitcoin where people paid directly to IP addresses, before Bitcoin addresses were introduced.<br />
scriptPubKeys of this transaction form are still recognized as payments to user by Bitcoin Core.<br />
The disadvantage of this transaction form is that the whole public key needs to be known in advance, implying longer payment addresses, and that it provides less protection in the event of a break in the ECDSA signature algorithm.<br />
<br />
scriptPubKey: <pubKey> OP_CHECKSIG<br />
scriptSig: <sig><br />
<br />
Checking process:<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<sig> <pubKey> OP_CHECKSIG<br />
|scriptSig and scriptPubKey are combined.<br />
|-<br />
|<sig> <pubKey><br />
| OP_CHECKSIG<br />
|Constants are added to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|Signature is checked for top two stack items.<br />
|}<br />
<br />
=== Provably Unspendable/Prunable Outputs ===<br />
<br />
The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:<br />
<br />
scriptPubKey: OP_RETURN {zero or more ops}<br />
<br />
OP_RETURN immediately marks the script as invalid, guaranteeing that no scriptSig exists that could possibly spend that output. Thus the output can be immediately pruned from the UTXO set even if it has not been spent. [http://blockexplorer.com/tx/eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29 eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29] is an example: it has a single output of zero value, thus giving the full 0.125BTC fee to the miner who mined the transaction without adding an entry to the UTXO set. You can also use OP_RETURN to add data to a transaction without the data ever appearing in the UTXO set, as seen in 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc; [[P2Pool]] does this with the share chain hash txout in the coinbase of blocks it creates.<br />
<br />
=== Anyone-Can-Spend Outputs ===<br />
<br />
Conversely a transaction can be made spendable by anyone at all:<br />
<br />
scriptPubKey: (empty)<br />
scriptSig: OP_TRUE<br />
<br />
With some software changes such transactions can be used as a way to donate funds to miners in addition to transaction fees: any miner who mines such a transaction can also include an additional one after it sending the funds to an address they control. This mechanism may be used in the future for [[fidelity bonds]] to sacrifice funds in a provable way.<br />
<br />
Anyone-Can-Spend outputs are currently considered non-standard, and are not relayed on the P2P network.<br />
<br />
=== Transaction puzzle ===<br />
<br />
Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b is an interesting puzzle.<br />
<br />
scriptPubKey: OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL<br />
scriptSig: <data><br />
<br />
To spend the transaction you need to come up with some data such that hashing the data twice results in the given hash.<br />
<br />
{| class="wikitable" <br />
|-<br />
! Stack <br />
! Script <br />
! Description <br />
|-<br />
|Empty.<br />
|<data> OP_HASH256 <given_hash> OP_EQUAL<br />
|<br />
|-<br />
|<data><br />
|OP_HASH256 <given_hash> OP_EQUAL<br />
|scriptSig added to the stack.<br />
|-<br />
|<data_hash><br />
|<given_hash> OP_EQUAL<br />
|The data is hashed.<br />
|-<br />
|<data_hash> <given_hash><br />
|OP_EQUAL<br />
|The given hash is pushed to the stack.<br />
|-<br />
|true<br />
|Empty.<br />
|The hashes are compared, leaving true on the stack.<br />
|}<br />
<br />
This transaction was successfully spent by 09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1. The required data happened to be the [[Genesis block]], and the given hash was the genesis block hash. Note that while transactions like this are fun, they are not secure, because they do not contain any signatures and thus any transaction attempting to spend them can be replaced with a different transaction sending the funds somewhere else.<br />
<br />
==See Also==<br />
<br />
* [[Transactions]]<br />
* [[Contracts]]<br />
<br />
<br />
[[Category:Technical]]<br />
[[Category:Vocabulary]]<br />
<br />
{{Bitcoin Core documentation}}</div>Occupy paul sthttps://tests.bitcoin.it/w/index.php?title=OP_RETURN&diff=59709OP RETURN2015-12-29T01:35:12Z<p>Occupy paul st: Created page with "OP_RETURN is a script opcode used to mark a transaction output as invalid. Since the data after OP_RETURN are irrelevant to Bitcoin payments, arbitrary data can be added i..."</p>
<hr />
<div>OP_RETURN is a [[script]] opcode used to mark a transaction output as invalid. Since the data after OP_RETURN are irrelevant to Bitcoin payments, arbitrary data can be added into the transaction by following the OP_RETURN with an OP_PUSHDATA. Since any outputs with OP_RETURN are provably unspendable, OP_RETURN outputs can be used to [[Proof of burn|burn]] bitcoins.<br />
<br />
Currently, the default Bitcoin client relays OP_RETURN transactions up to 40 bytes, but does not provide a way to create OP_RETURN transactions.<br />
<br />
== Philosophy ==<br />
Some members of the Bitcoin community believe that use of OP_RETURN violates the contract of Bitcoin, because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data. Despite this, use of OP_RETURN may continue unabated because there is no easy way to stop people from embedding arbitrary data in the blockchain, and OP_RETURN is an efficient way to do it. [[https://bitcointalk.org/index.php?topic=471928.0 bitcointalk discussion]]<br />
<br />
== Resources on OP_RETURN ==<br />
* [http://coinsecrets.org/ coinsecrets.org]: An OP_RETURN transaction explorer<br />
* [https://github.com/coinspark/python-OP_RETURN python-OP_RETURN]<br />
* [http://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like StackExchange: Explanation of what an OP_RETURN transaction looks like]<br />
* [http://www.slideshare.net/coinspark/bitcoin-2-and-opreturns-the-blockchain-as-tcpip Metadata in the Blockchain: The OP_RETURN Explosion]<br />
* [http://wlangiewicz.com/blog/2014/10/24/how-to-put-custom-messages-into-bitcoin-blockchain-op-return/ How to Put Custom Messages Into Bitcoin Blockchain - OP_RETURN]<br />
<br />
== OP_RETURN prefixes ==<br />
Often, OP_RETURN transactions include a prefix to identify which protocol they belong to. There is no standardized method of claiming OP_RETURN prefixes, and not all OP_RETURN transactions use prefixes. At the time of writing, this wiki page is probably the most complete registry of OP_RETURN prefixes.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Prefix (Ascii-Encoded) !! Protocol/Owner !! Brief description<br />
|-<br />
| Fa || Factom || ?<br />
|-<br />
| CC || Colu || ?<br />
|-<br />
| ? || [https://github.com/OpenAssets/open-assets-protocol Open Assets] || Issuance and transfer of user-created assets<br />
|-<br />
| MG || [https://monegraph.com Monegraph] || Digital work licensing<br />
|-<br />
| id || Blockstore || ?<br />
|-<br />
| ASCRIBE || [https://ascribe.io ASCRIBE] || Digital work licensing<br />
|-<br />
| ? || Counterparty || ?<br />
|}</div>Occupy paul sthttps://tests.bitcoin.it/w/index.php?title=Nanopayments&diff=58679Nanopayments2015-09-05T16:05:52Z<p>Occupy paul st: Add a link to the bitcoin-nanopayment project on Github</p>
<hr />
<div>''a.k.a. Micropayments''<br />
<br />
Nanopayments are tiny payments for a trivial service. For example, 0.0001 BTC for each of three Tor nodes to relay one megabyte of traffic with premium priority.<br />
<br />
It should be easy to see that a series of payments like this would be "spam" to Bitcoin, and infeasible due to transaction fees, and unwelcome to everyone who must download and store the whole block chain.<br />
<br />
The idea, in a nutshell, is for Alice to make a 0.0001 BTC nanopayment to Bob by signing a message not worth 0.0001 BTC, but by signing a message that has 1 in 10000 probability of being worth 1 BTC, and sending it to Bob directly. This message would function much like a share in a mining pool. Out of 10000 nanopayments, on average, 9999 will be worthless and 1 will not.<br />
<br />
For it to work fairly, Alice must not have any way to know which share is actually redeemable to the recipient. <br />
<br />
Of course, due to variance, Alice will sometimes get her services for free, and sometimes she will vastly overpay. However, if she consumes such services regularly, the amount she pays will tend toward the amount she consumes.<br />
<br />
=====Technical stuff: How can probabilistic transactions be created?=====<br />
<br />
Bob creates a secret transaction that will be used for a "guess my hash" challenge. The value can be the minimum and will be sent back by Alice's transaction. He doesn't broadcast it yet.<br />
<br />
Alice will create a multi-input transaction that spends her own coin AND Bob's secret transaction. Here's where the random chance comes in. We're going to randomize the prevout identifying Bob's transaction. Multi-input transactions are not valid unless all their inputs exist, so if Bob's transaction is misidentified, the whole transaction is void.<br />
<br />
For the hash identifying the secret transaction, Bob only gives Alice a numeric range that the hash is in. If the hash is H, and we want a 1/N chance of the nanopayment being real, then Bob would take H1=H-rand(N) and tell Alice the hash is between H1 and H1+N.<br />
<br />
Alice chooses H2 in the range H1 to H1+N and creates the transaction. Input 1 is her coin, and input 2 uses H2 as the prevout hash that may or may not match Bob's secret transaction. She signs input 1 and gives the transaction to Bob. Note that signing one input locks in the prevouts of all inputs, so Bob can't change H2.<br />
<br />
Bob now checks if the H2 she used equals H. If it is, he signs input 2 and broadcasts both his secret transaction and Alice's transaction.<br />
<br />
If H2 is not H, then the transaction can never be valid, because there can be no previous transaction that hashes to H2. Since the transaction is invalid, not just unspendable, Bob can't be a jerk and submit it to the network just to waste Alice's coin.<br />
<br />
<br />
''What if Alice tries to [[double-spending|double spend]] her 1 BTC out from under Bob before he gets his successful transaction into the block chain?''<br />
<br />
If Alice tries to double spend on nanopayments, she'll spend more on transaction fees than she saves.<br />
<br />
She would need to selectively double spend the real ones, but she doesn't know if the transaction she gave Bob was real. All she can do is wait and watch if Bob broadcasts it, but by then his transaction will already [https://bitcointalk.org/index.php?topic=423.msg3819#msg3819 have a big head start]. If Bob is really paranoid, he could connect directly to the pool miners and broadcast only to them first to get most of the mining power sewed up before Alice would even know.<br />
<br />
<br />
''What if Alice uses that same 1 BTC to buy services from somebody else, who won't know she is pledging shares of that same coin in more than one place, where somebody would be shortchanged if both services won the same bitcoin at around the same time?''<br />
<br />
This may not be a big enough problem to matter for most casual, low value uses.<br />
<br />
If need be, this could be solved with hub servers that nanopayment recipients would use to announce coins currently in use to other nanopayment recipients.<br />
<br />
When Alice sends her nanopayment transaction to Bob, she would need to use her coin's EC-DSA key to sign a reserve message containing the current time, her coin's hash, and the address she's paying to. Bob sends this message to the hub server to reserve her coin for some predetermined period like 1 minute.<br />
<br />
A hub server would be pretty simple, just a single lookup table. A merchant sends it a reserve message. The server checks that the signature matches the coin. If a reserve is already in effect for that coin, it returns an error, otherwise OK. It adds the reservation to its lookup table and purges it when it expires. Merchants could connect to several hub servers to keep them honest and for redundancy. It would be fitting to pay the hub servers with nanopayments.<br />
<br />
<br />
This article is derived from [https://bitcointalk.org/index.php?topic=62558 Sustainable nanopayment idea: Probabilistic Payments] by casascius.<br />
<br />
The [https://github.com/paulkernfeld/bitcoin-nanopayment bitcoin-nanopayment] project is a relatively unproven implementation of this using Node.js.</div>Occupy paul st