Promechard: Proprietary Metablock Chains for Arbitrary Data

[Krona Rev]

Update (Oct/Nov 2014): My github account was deleted for some reason, so the code below is no longer available there.
I found someone to host it for me and the links in the message have been updated.
I recommend people stop using github. They cannot be trusted not to delete your repo.
----------------------------------------------------------------------
I recently thought of a way to publish a sequence of "metablocks" containing arbitrary data which is secured by the Bitcoin block chain. It only requires very small Bitcoin transactions so it doesn't bloat the block chain. It also does not create unspendable transaction outputs: it does not destroy bitcoins and does not increase the number of unspent txouts.

The idea is to use a public key and the hash of the metablock to compute a modified public key and then address. By spending to this address, one certifies the metablock. The transaction certifying the metablock is included in the successor metablock.

I think there are many ways this could be used. One example would be by someone running a notary service like the one at proofofexistence.com.

A detailed written description is available here:

https://github.com/kronarev/bip0032sbcl/blob/master/propmetablockchains.pdf
https://mathgate.info/bip0032sbcl/propmetablockchains.pdf

I extended my implementation of BIP0032 to include commands for certifying and verifying metablocks. It is not fully automated at the moment, but could be by integrating it with bitcoind. The implementation is here:

https://github.com/kronarev/bip0032sbcl/
https://mathgate.info/bip0032sbcl/bip0032sbcl.tgz

As an example, I created three "metablocks" which are available at the github repository above as the files MetaBlock1, MetaBlock2 and MetaBlock3. More information is in the README.md file.

To get a sense of the bitcoin transactions used to certify metablocks, you can view the ones certifying the three metablocks above here:

https://blockchain.info/tx/4b5066707134d715f7b9d2efe3d9f7e0d320689787611ed7cbe1d5cbf98c5768
https://blockchain.info/tx/97e023eddaf5bb867c5caf25bfd5b02fc1ce2588a2077cb22bc9a440d5f0e0f2
https://blockchain.info/tx/f2fb9b6481ed928aedef27279f7ad3d8db657c81407eee20d5f3a21daf15a28d

The address of output 0 of each of these transactions can be computed from the corresponding metablock.  The transaction spending output 0 of the transaction certifies the successor metablock.

Feedback is appreciated. It's possible, of course, that someone has done something like this before and I'm not aware of it. If so, please let me know.

Edit: I decided it might facilitate discussion to give the idea a name, so I'll refer to it as Promechard.

[1715209414]

1715209414

[1715209414]

1715209414

[1715209414]

1715209414

[Adlai]

Although your github account got deleted, there's a fork which is still accessible:

https://github.com/Indicator/bip0032sbcl

[Krona Rev]

Although your github account got deleted, there's a fork which is still accessible:

https://github.com/Indicator/bip0032sbcl

Great! Thanks for letting me know.

[dansmith]

I didn't know github deletes accounts without notice. Sorry for that. Care to elaborate why that happened?

wrt Promechard, now that we have prunable OP_RETURN transactions, do you see any other use cases where Promechards method would still be more diserable?

[Krona Rev]

I didn't know github deletes accounts without notice. Sorry for that. Care to elaborate why that happened?

wrt Promechard, now that we have prunable OP_RETURN transactions, do you see any other use cases where Promechards method would still be more diserable?

I don't know why they deleted my github account. I haven't asked. I consider it a lesson learned and will move on. I always use Tor (via Tails), and maybe my account got flagged because of that. Some websites are not Tor-friendly.

As you pointed out, OP_RETURN is the standard way to embed timestamped hashes into the blockchain now. I guess to make a promechard using OP_RETURN one could publish txs of the form

input1 (tx corresponding to previous metablock)
...
->
output1 (OP_RETURN with the hash of this metablock)
output2 (output indicating who can publish the next metablock)
...

Using my implementation, the OP_RETURN output isn't needed because the hash of the metablock and the public key of who can publish the next metablock are combined. (That is, output1 and output2 can be combined.) This makes the tx slightly smaller than the OP_RETURN version, but it's a savings of only a few bytes. Using OP_RETURN is more flexible.

I hope at least the code is helpful for someone who wants to learn about secp256k1 and prefers to read lisp.