Re: Chainpoint

> But isnt there some complexity involved?  e.g. Proof of work is not simply
> proof of work.  There are also max difficulty changes, number or blocks to
> difficulty change.  Things like Kimoto Gravity Well etc.  Any thoughts on
> how to enumerate all these different flavours of the same concept?

I don't think you can for decentralized chains.

On the bitcoin-dev mailing list we discussed how to interpret block time fields
for the purpose of timestamping in more detail:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013120.html

As you can see, that was a very in-depth discussion, and the tl;dr: answer is
that exactly what a time field means depends a *lot* on the exact details of
how a particular decentralized blockchain protocol achieves consensus. Get this
wrong, and your interpretation could be off by hours, making it quite possible
to falsely generate invalid timestamps.

In any case, creating timestamps is just a small part of the problem:
validating timestamps is the hard part. To validate a decentralized chain's
timestamp, you need a very large dependency: an implementation of the protocol
in question and a full node. In that context, the code savings involved by
trying to come up with a way to generalize the way decentralized chains are
validated are trivial.

My plan for OpenTimestamps is to make each type of decentralized chain a
completely separate notary type, with a separate codebase to validate it.


Rather than focusing on client-side support for multiple chains it may be more
productive - and a lot simpler - to have a community effort to ensure all the
chains out there cross-timestamp each other. The best way to do this is as
follows:

1) Build merkle trees of all headers in every cross-linked chain, creating a
   set of N per-chain commitments.

2) Take that set and create a merkle tree over every per-chain commitment,
   creating a final global commitment.

3) Timestamp that global commitment in every chain.

With some cleverness you could even embed sufficient data in the chains
themselves to recover the exact merkle trees build all of the from the chains,
reducing the risk of losing the necessary data to actually use the trees after
the fact. Otherwise, just save the resulting trees into an archive somewhere
for later use.

In OpenTimestamps, once the above has been done, regardless of what chain a
given message was timestamped in, you'll always be able to find a k*log2(n)
commitment operations path from that chain's header to the header of any other
chain; this is possible because commitment operations are sufficiently flexible
to represent any(1) cryptographically secure merkle path, even if it crosses
multiple chains. That path can in turn be added to your timestamp in the event
that any particular chain fails to be trustworthy - something that could easily
be done by calendar servers on an as-needed basis.


1) One exception would be protocols that XOR intermediate digests with fixed
   constants, but fortunately other than HMAC secret keys AFAIK this idea
   doesn't exist in the wild!

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