An idea for safely using Bitcoin for generic timestamping just occurred to me. I'll roughly describe it here. (Though there's a good chance that someone has thought of this already, and I'm just poorly reinventing it.)
Do a softfork with these two new rules:
1. Miners will construct a separate hash tree called the
chain tree, which I'll explain more later. Some special area in blocks is reserved for the root hash of this tree. For example, this could go in the coinbase transaction or in the first transaction after it.
2. When a transaction has an output with the special form
<arbitrary magic constant> <merkleHash> OP_RETURN, then a block containing the transaction is only valid if
merkleHash is the hash of one of the nodes of the chain tree. Therefore, a block can only be considered valid if it is transmitted with enough of the chain tree to verify all of these transactions in it, though the
entire chain tree need not be known to anyone.
Each node of the chain tree would be something like:
struct node {
char[8] chainId;
char[32] hashOfData;
char[32] hashOfLeft;
char[32] hashOfRight;
}Bitcoin full nodes do not verify anything about the chain tree unless required by rule #2 above. If there are no rule#2 transactions in a block, then the chain tree root can just be random data.
Bitcoin then becomes a generic decentralized timestamping server for an unlimited amount of data. There are several use-cases for this, including scaling:
You can create a chain like Bitcoin's, but with 32 MB blocks or whatever. Full nodes on this chain would need to be full nodes on both Bitcoin proper and a separate bigblock network. When receiving a new Bitcoin block, they'd download as much of the chain tree as they can, and then for nodes matching a certain
chainId specified by the bigblock network specification, they'd try to download that block over the bigblock network. Maybe only the first such block would be considered valid (by some ordering specified by the bigblock network), or maybe all valid blocks in the chain tree would be accepted. The network can do whatever it wants.
No mining/PoS/etc. is necessary on the bigblock chain. Anyone can create blocks and submit them to Bitcoin miners for inclusion into the chain tree. However, an attack is possible where someone creates a valid block and gets it into the chain tree, but then refuses to actually send anyone the block until much later, rewriting history; to prevent this, each block should still have a header with a prev-block hash, and the longest chain of blocks should win.
If you're creating a bigblock block, you'd get miners to include your block's node into the chain tree by sending along with your request a transaction using the special rule#2 form specified above. There would typically be only one 0-value output in the special form, and the inputs can use SIGHASH_ANYONECANPAY so that people can work together to pay the fee. Additionally, the chain tree can actually extend inside of the bigblock chain so that bigblock transactions are part of the chain tree; then individual transaction-senders can add a similar incentive that is specific to their own transactions.
Unlike typical sidechains, this would not have SPV-level security. Even if all Bitcoin miners worked together, they could not create an invalid block on the bigblocks network that bigblock full nodes would have to accept. To achieve the same effect with sidechains, you have to do a soft-fork which adds a requirement that all Bitcoin full nodes also be full nodes on the sidechain. This might sometimes be OK, but not if the sidechain is doing something burdensome like creating massive blocks.
I don't think that you can do 2-way-peg without either more-or-less recreating normal sidechains or getting Bitcoin full nodes involved to a much greater extent (more like Peter Todd's Tree Chains idea). So the bigblocks chain described here would have to have its own currency. Whether or not this major drawback allows it to still be worthwhile, I'm not sure.
It works even better for timestamping applications that are less related to transactions, especially:
- As part of a decentralized DNS system.
- For general time-stamping of documents
For these, you maybe don't even need separate blocks at all: the transactions can be connected directly to the chain tree. And certainly you wouldn't need a separate currency.
