W3C home > Mailing lists > Public > public-blockchain@w3.org > September 2016

Re: Chainpoint Community Group Announcement

From: Peter Todd <pete@petertodd.org>
Date: Sat, 24 Sep 2016 17:49:28 -0400
To: Adán Sánchez de Pedro Crespo <adan@stampery.co>
Cc: public-blockchain@w3c.org
Message-ID: <20160924214928.GA1605@fedora-21-dvm>
> That's a really good point. OP_RETURN is not the only way to anchor data
> into the Bitcoin blockchain (e.g. OpenTimestamps).
> In the case of Ethereum, AFAIK,  there are at least two different
> methods as well.

Though it's worth noting, that so long as your timestamp protocol supports
arbitrary commitment operations and anchoring in the block header, all other
anchoring methods can be efficiently represented by a block header anchor and
commitment operation path up to that header.

For example, the OpenTimestamps client comes with an example timestamp that
uses an unspendable txout(1) anchor:

    $ ./ots info examples/empty.ots
    File sha256 hash: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
    prepend <snip - first part of tx>
    append 88ac00000000
    prepend db8b8abf653b8b01fbcb7df85e51a2dcb8af6a4b914a0c0aa1e20569782a3942
    prepend c4403ec528831424827ffb31d7669abf97195cd3d5dc766cec7132532acb2252

    <snip - merkle path up to block header>

    append 37efcd6972b79eddda5191ff7dc25f61d44963def1529af55ff8fd893a470c1c
    verify BitcoinBlockHeaderAttestation(129405)

Note the ripemd160 at the beginning: that's because in Bitcoin a standard
pay-to-pubkey-hash is of the form RIPEMD160(SHA256(<pubkey>))

This type of timestamp has the advantage that it's not possible for miners to
censor, as they can't distinguish it from any other txout. Since OpenTimestamps
is based on commitment operations, the fact that the timestamp happened to be
created this way is of no concern to the validator, and can be validated in the
exact same way as any other Bitcoin timestamp, using the same code.

1) As an aside, you can also create *spendable* txout anchors with P2SH, as
   1-of-2 multisig: one of the pubkeys is real, and the other is the
   commitment. OpenTimestamps used to do something quite similar to this back
   in 2013 with bare multisig; it doesn't do that anymore as bare multisig
   transactions don't get mined by miners these days for various reasons.

https://petertodd.org 'peter'[:-1]@petertodd.org

Received on Saturday, 24 September 2016 21:50:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:26 UTC