Articles

Bitcoin Q&A: Block capacity and embedded data

December 31, 2019


“What can you put on the Bitcoin blockchain?” “Andreas, how many transactions can fit
in a block, with and without SegWit?” “In addition, what kind of other data
can you include in a block? Thanks.” Great question. I can’t give you an exact number
because it depends on the nature of transactions. Transactions can vary greatly in their size. The most basic transaction, a single input / single
output pay-to-public-key-hash (P2PKH) transaction, if I remember correctly, is 266 bytes. The average transaction with one input and two outputs
is a bit bigger than that because it has change. If it uses a more complex construct, perhaps a
pay-to-script-hash (P2SH), it’s going to be a bit longer. If it uses and is paying out of a multi-signature, it’s going
to have some redeem scripts; that is a bit longer too. So the transaction size can vary. On average, a one megabyte block can fit about
1,800 transactions, maybe up to 2,000 transactions. Now that we have Segregated Witness (SegWit) on
the Bitcoin main chain, that can expand [the capacity] to about 4,500 transactions in a single block. You can look at the statistics; I haven’t looked at them
recently to see exactly how many transactions. But certainly we’ve seen an almost doubling of
the block capacity in order to fit more transactions. I think the factor was 1.7x the last time I looked. The second part of the question is also interesting. “What kind of other data can you include in a block?” Keep in mind that blockchains are the world’s
most expensive and inefficient form of data storage. They’re structured [like that] intentionally… because decentralisation requires us to make
some sacrifices in terms of efficiency. That means you can’t store a lot of data. When you
try to store a lot of data, it gets very expensive. However, one of the interesting things you can do
with a blockchain is, instead of storing the data itself, you can store a hash or fingerprint of the data, and then store the data in a secondary network
such as the InterPlanetary File System (IPFS). Or any other form of storage. You could even store your data on a Google Drive
if you wanted to use a centralised service. With that, what you can do is have the
data stored outside [the blockchain], but you can take a fingerprint or hash of your data
and embed that in the blockchain. What good does that do? It gives you the ability to prove that a certain
piece of data existed on or before a certain time. That’s called proof-of-existence. That’s been a useful service for legal purposes;
you can do notarisation for a variety of uses. There is a protocol that allows you to compress hashes (thousands, hundreds of thousands, millions of them) into a single transaction that timestamps every [hash]. That protocol is called OpenTimestamps. It allows you to timestamp all kinds of data
into the Bitcoin blockchain. Similar protocols exist for other blockchains,
which can be used to timestamp data too. “What exactly is meant with ‘metadata’?
Are metadata visible and useful?” Yes. Metadata is data that refers to something
external to the system in which it is stored. In Bitcoin, only data that is about bitcoin is data. Any data that is not about bitcoin, but about something
else that’s stored “inside” Bitcoin, is metadata. That’s one of the ways to look at it. Of course, the term is probably a bit
more flexible and vague than that. “How could I upload a hash of a document
in an OP_RETURN field myself?” “Is there a special command on
Bitcoin Core which allows me to do so?” I don’t believe there is. There are
a number of other applications. There’s a couple of good ones. One is called ‘Proof of Existence’ and I believe
it is at ProofOfExistence.com, which allows you… to upload the hash of a document and
put it in an OP_RETURN for a small fee. Another one is a more developed protocol called
OpenTimestamps, which is a project by Peter Todd. It’s really interesting because it scales
the ability to do proof-of-existence… for billions of documents by aggregating
all of this information in Merkle trees, putting only the root of the tree in the OP_RETURN [field],
while storing most of the metadata off-chain on OpenTimestamps servers. It’s a good compromise solution.
OpenTimestamps is what you’re looking for there. “In the same manner, could I upload any text I want… on the Bitcoin blockchain,
as long as it’s less than 80 bytes?” Yes, you can. “Could Ethereum be used more efficiently for storing
hashes of documents instead of Bitcoin? Why?” Yes, Ethereum could be used more efficiently for storing
hashes of documents instead of the Bitcoin blockchain. The primary reason is that Ethereum
will allow you to store a lot more data. As a result, it has bigger scaling issues
than the Bitcoin blockchain. On Bitcoin, you can store 80 bytes in each OP_RETURN
and it will cost you a fee to include that in a transaction. With Ethereum and smart contract,
you can store quite a lot of data. You still have to pay a transaction fee, but there’s no
80 byte limit. It’s a matter of metering that with gas. There is a particular type of contract
called a “deed” or non-fungible token, which is basically storing hashes of things. These can be deeds like real-estate titles,
CryptoKitties hashes, and various other things that are non-fungible unique items. Storing those hashes inside a tokenised contract allows
you to transfer these tokens from person to person, or from owner to owner. That’s called ERC-721.
It’s rather interesting. “Can a block with hashed data stored in
OP_RETURN, such as an academic certificate, also have regular mine-able transactions and
therefore be treated just like any other block?” Yes. The transaction that has the OP_RETURN in it
can also have other things like regular payments. Only one of the outputs needs to be an OP_RETURN. The other outputs in that transaction could
be payments, so you can embed it in a transaction that does other things as well as the OP_RETURN. That can be among many other transactions,
and the block is just like any other block.

You Might Also Like

No Comments

Leave a Reply