"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.