Live forever on the blockchain
(How to embed your data on Bitcoin Blockchain)
The Bitcoin network bundles transactions together into a distributed database
known as the block chain. When viewed from within the network, transactions
simply represent electronic cash payments. Outside the Bitcoin network, more
complex interpretations are possible. Adding application-specific data to
transactions opens the door to using Bitcoin not just for electronic cash
payments, but new kinds of financial, property, and legal transactions.
Questions around how — and even whether — to support these uses have been hotly
debated for years.
Bitcoin is one of the biggest revolution of the early digital era.
Bitcoin, and its underlying technology known as Blockchain, changed the way we
can transfer value from A to B without passing through a central authority or
intermediaries, being, at the same time, safe against double spending and
malicious balances alterations. While performing as a great storage of value and
balanced value transfer system Bitcoin protocol offers other great features.
One of the most important and useful capabilities of the Bitcoin’s blockchain is
to be able to embed chunk of non-necessary data into every transaction, thus
into a block, so into a blockchain which will last forever and ever in a
immutability fashion which no other tricks would do.
Bitcoin transactions have an actual size limit of 1 MB circa and you can use
“only” 40 bytes to embed your stuff, which isn’t so much but neither so few, but
this is far enough for many of the most useful use cases of such feature: you
can embed into a transaction many different types of data, from a simple
sentence, to urls & notes but first of all you are, in example, able to embed a
notarization hash of verifiable documents, contracts and more. This said, a
world of new applications opens in front of us.
However, living in the big data society, 40 bytes comes a bit tight when dealing
with large amounts of data to attach on Bitcoin blockchain: this isn’t a big
issue so far because an easy workaround kicks in: we can hash text & files to an
embeddable format suitable with the bitcoin blockchain encoding, which is HEX
format, and spread (divide) it through many transactions so that a big size file
can be divided in many little pieces. If we want to embed the whole Divina
Commedia of Dante Alighieri in the blockchain this will force us to use multiple
transactions, each of them containing a maximum of 72 chars converted in HEX
format and embedded in it. Since the Divina Commedia is composed by nearly
500000 chars we would need around 7000 TXs to accomplish with this task. Of
course you have to pay a little fee to the network, as any other transaction, to
get your TX confirmed in the blockchain and to make your embedded file living
FOREVER. Writing such many letters on plain text could seems like a waste of
resources but this is the beatuy of this feature: no dictatorship, no
Fahrenheit_451 fireburners, no literally one can erase or change this from this
world until Bitcoin’s blockchain will last (i.e. forever).
Now let’s dive in the tech side of it.
Scripts & OP_RETURN
Transactions are far more flexible, and complex, than they might appear on the
surface. Within each transaction lies a small program, or script, written in a
custom language: a transaction supplies one
part of a two-part script. A payment defines a challenge script that places
conditions on how a coin can be redeemed. The transaction redeeming the payment
provides a response script that satisfies the conditions imposed by the
challenge script.
Full nodes (e.g., those running Bitcoin Core) verify a transaction by combining
challenge and response scripts into a validation script. The validation script
is then executed during verification, just like a program. If the script
finishes running without raising errors or returning a non-true result, then the
transaction is considered valid.
Validation scripts offer an obvious method for encoding application-specific
data, but other techniques have been used. For example, one
scheme
stored data by writing it into two payment addresses.
Although these ad hoc methods solved the problem of adding application-specific
data to the block chain, the long-term costs were a cause for concern. For
example, the block chain grows at an exponential rate, doubling in size over
the last year
alone.
This growth exerts upward pressures on storage space, and more importantly
network bandwidth.
A more serious concern stems from the need to keep application-specific data
within the unspent transaction output (UTXO) set. The UTXO set contains
references to all spendable coins, and so should be kept small to ensure fast
transaction validation. Embedding application data into addresses or challenge
scripts forces each full node to add a reference to the UTXO set.
Not the best way to optimize resources and network functionality.
OP_RETURN
Validation scripts can choose from a diverse palette of predefined
functions. Due to security concerns,
only a handful of functions are permitted in standard transactions. Because
miners only relay standard transactions, many of the most useful script
functions remained off-limits.
The 0.9.0 release of Bitcoin Core added a new standard transaction type granting
access to a previously disallowed script function, OP_RETURN. This function
accepts a user-defined sequence of up to 40 bytes. When a transaction containing
a challenge script with an OP_RETURN function is mined into a block, the
accompanying byte sequence enters the block chain.
Although stored in the block chain, OP_RETURN bytes are excluded from the UTXO
set, conserving a scarce resource. As a side effect, an output using an
OP_RETURN challenge script becomes unspendable. For this reason, the value of
an OP_RETURN output is usually set to 0.
The OP_RETURN Compromise
OP_RETURN and its 40-byte limit represent a compromise between two opposing
visions of Bitcoin’s future.
One camp sees the block chain as a secure, decentralized data store on which
numerous financial and social applications can be built. Promoting the growth of
these new applications helps ensure Bitcoin’s long-term relevance. Allowing
transactions to carry application-specific data in a standard way advances this
goal.
The other camp views the Bitcoin block chain exclusively as a medium for
recording electronic cash payments. Even so, important scalability issues will
need to be addressed sooner or later. Trying to accomodate the data requirements
of arbitrary application layers only raises the cost of maintaining the network
today, while pushing forward the eventual day of reckoning.
The 40 byte limit on OP_RETURN data constrains the use of the block chain as a
data store. For example, OP_RETURN was originally expected to support 80 bytes
of data. One of the strongest critisisms of the later 40-byte limit came from
Counterparty, who
claimed that
40 bytes was not enough to support the system of peer-to-peer markets and
financial instruments it had created.
However, a 40 byte sequence more than suffices to encode an identifier such as a
hash value. This value can uniquely represent any digital document, from an
image, to a poem, to an abstract data structure. Embedded hash values in turn
offer a method to link the block chain to other data stores such as distributed
hash tables.
The Bitcoin Core 0.9.0 release notes
attempted to clarify the purpose of OP_RETURN:
On OP_RETURN: There was been some confusion and misunderstanding in the
community, regarding the OP_RETURN feature in 0.9 and data in the blockchain.
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.
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.
These guidelines re-iterate Satoshi’s original view that external data should
not be stored in the block chain.
Uses of OP_RETURN
Since its introduction in March 2014, OP_RETURN has been examined from a
number of angles. At least one service, Proof of
Existence, now uses OP_RETURN to
permanently link digital documents to the block chain. Counterparty’s lead
developer
announced
the discovery of a method to run the system off of 40-bytes of OP_RETURN data.
Mastercoin, another project relying embedded data, started a
discussion dedicated to
finding a way to use OP_RETURN.
Stealth addresses offer another example of OP_RETURN in action. This scheme
enables payments to be received without publicly revealing the receiver’s public
key or address. Data needed to make this system work are encoded within a call
to OP_RETURN. In essence, Bitcoin does double duty as a secure messaging
protocol.
Although the best uses of OP_RETURN may take some time to materialize, one
thing is clear. Many Bitcoin users see value in adding data payloads to
transactions, and some have started using OP_RETURN for this purpose.
Transactions using OP_RETURN can be monitored via Coin
Secrets.
HOW TO — Step to Step Guide
Step 1
Choose something you want to embed in the blockchain, text or whatever, and
convert to HEX format here (or with your preferred method):
http://www.online-toolz.com/tools/text-hex-convertor.php
In example we are going to write on the blockchain the following:
coincaps.ai — cryptocurrencies info hub
Which converted in hex format is:
636f696e636170732e6169202d2063727970746f63757272656e6369657320696e666f20687562
This Hex string is the piece of data we are going to submit in our transaction
OP_RETURN. Let’s go ahead to step 2.
Step 2
Open your Bitcoin wallet.
If using command line interface just run commands
with “bitcoin-cli [command here]”, you are instead using a QT GUI version of
Bitcoin Core wallet click on Help -> Debug Window -> Console.
Now we must choose an existing address holding spendable funds to create, sign
and send our data embedding data payload transaction.
For a quick look at all the available commands for the bitcoin api type:
“help”.
At this step we need to check some necessary informations about the address
we’ll use to sign the transaction. More precisely we have to check the unspent
balances of the chosen address with the command: “listunspent minconf maxconf
[address1, address2, …]”
Command:
listunspent ( minconf maxconf ["address",…] )
Example:
listunspent 0 999999 '["1BENoCzVT3awc3y1GCbWiCM25cEX9KAw7B"]'
Output:
[
{
"txid": "855a32647ffb88aaa08dbb2359bbf1daeb6d9c7faa9d16cd9fd7ede221158352”,
"vout": 1,
"address": "1BENoCzVT3awc3y1GCbWiCM25cEX9KAw7B",
"account": "",
"scriptPubKey": "76a9147038dc3b8533a422d1225ecbcc3c85e282fd92b388ac",
"amount": 0.00100000,
"confirmations": 0,
"spendable": true
}
]
Now we have all the informations needed to proceed and create a Raw
Transaction that we’ll later push to the bitcoin network. (ATTENTION: always
set the change amount otherwise the remaining balance of the signing address
will go towards miners as a fee!)
Command:
createrawtransaction [{"txid":"paste here txid form previous step output","vout":number from previous step}]''{"data":"the message you want to write on the blockchain converted in hex ","the address you are using":change}']
Example:
createrawtransaction '[{"txid":"855a32647ffb88aaa08dbb2359bbf1daeb6d9c7faa9d16cd9fd7ede221158352","vout":1}]' '{"data":"636f696e636170732e6169202d2063727970746f63757272656e6369657320696e666f20687562","1BENoCzVT3awc3y1GCbWiCM25cEX9KAw7B":0.00080000}'
Enter the above command filled with your data and you should get a string output
like the one below
Output:
010000000152831521e2edd79fcd169daa7f9c6debdaf1bb5923bb8da0aa88fb7f64325a850100000000ffffffff020000000000000000236a214557202347656e65726174696f6e426c6f636b636861696e20776173206865726580380100000000001976a9147038dc3b8533a422d1225ecbcc3c85e282fd92b388ac00000000
N.B. If you don’t set the change, all the bitcoin you have on the address
you are using will go to the miner. In this example I set up the change is such
a way that I left 0.00001 btc to pay the transaction fee. The ideal transaction
fee may change in the future.
STEP 3
This one is quite simple, all we have to do is to sign the transaction just
created:
Command:
signrawtransaction "hexstring from previous step output"
Example:
signrawtransaction 010000000152831521e2edd79fcd169daa7f9c6debdaf1bb5923bb8da0aa88fb7f64325a850100000000ffffffff020000000000000000236a214557202347656e65726174696f6e426c6f636b636861696e20776173206865726580380100000000001976a9147038dc3b8533a422d1225ecbcc3c85e282fd92b388ac00000000
Output:
{
"hex": "010000000152831521e2edd79fcd169daa7f9c6debdaf1bb5923bb8da0aa88fb7f64325a85010000008b483045022100ec8d66045f7bbe1953a0937b2e5970b84d2f5462c6080802055c7cdfb2d19cc402204db3880775534df762e8afdc0814372ce706337ef129d8d35839093bd88734140141045d443089b4587d355b4cb5ac39b0156afc92152627693149de16d0d2269cea2417010c0bc6930e9b47573dab76a951e01d884b2bed9eaf92cc2369b6ddc7f98cffffffff020000000000000000236a214557202347656e65726174696f6e426c6f636b636861696e20776173206865726580380100000000001976a9147038dc3b8533a422d1225ecbcc3c85e282fd92b388ac00000000",
"complete": true
}
STEP 4
Very last step, let’s just broadcast the signed transaction:
Command:
sendrawtransaction "hexstring from previous step output"
Example:
sendrawtransaction 010000000152831521e2edd79fcd169daa7f9c6debdaf1bb5923bb8da0aa88fb7f64325a85010000008b483045022100ec8d66045f7bbe1953a0937b2e5970b84d2f5462c6080802055c7cdfb2d19cc402204db3880775534df762e8afdc0814372ce706337ef129d8d35839093bd88734140141045d443089b4587d355b4cb5ac39b0156afc92152627693149de16d0d2269cea2417010c0bc6930e9b47573dab76a951e01d884b2bed9eaf92cc2369b6ddc7f98cffffffff020000000000000000236a214557202347656e65726174696f6e426c6f636b636861696e20776173206865726580380100000000001976a9147038dc3b8533a422d1225ecbcc3c85e282fd92b388ac00000000
Output:
af91176121c91234cc99387f35f3e1d3f8853afc7f156a5873e48c67260eb7ae
The output from this last step is the transaction ID that we can use to find
this message on any block
explorer.
Since this message starts with “EW”, after one confirmation it appeared also on
Eternity Wall.
We are done now! Just wait until miners confirms our transaction in a block and
then our data will be living forever on the Bitcoin’s blockchain.
Conclusions
Bitcoin’s long-running debate over acceptable uses of the block chain has
received some much needed clarity. Applications can now inexpensively add a 40
byte data payload to transactions using the OP_RETURN script function. On a
technical level, OP_RETURN doesn’t enable anything that wasn’t previously
possible. Instead, OP_RETURN provides a standard interface through which new
services can potentially be layered onto the block chain, and a central point of
focus for future work on integration tools.
This move brings the vision of Bitcoin as a universal platform for mediating
complex agreements one step closer to reality. The extent to which the Bitcoin
community will embrace this vision remains an open question.
CoinCaps.ai
Trading a revolution. #cryptocurrencies #blockchain #bitcoin