From: p2p-hackers@zgp.org (Lucas Gonze)
Date: Mon Jul 1 01:22:24 2002
Subject: [p2p-hackers] Distributed Timestamping Service

> >>To make things easier, I don't really need the real time.  All I need is a
> >>timeline of discrete events, one following the other, rather than the real
> >>time.  For example, each "time click" could be a hash, and the next time-click
> >>would fold the previous hash into itself, and so on.  So instead of having a
> >>service that says 1:00 PM, then 2:00 PM, etc., it simply says Time Click A,
> >>Time Click B, Time Click C, etc.

...fun stuff...   some thoughts on it while I'm taking a coffee break:

This seems doable as a directed graph with edges from signed data to data
which it it is used to sign. 

When a node signs data for some other node, it certifies that the signed 
data was present by that time.  But what about the key being signed with?   
It might have been created at any point.  So, the key should have been 
signed at some previous time by a third node.

This establishes sequential information between the signed data 
and the signing key.  It says that the key existed first.   

There is no need to have just one signer.   The opposite -- you want 
a lot of signers and a lot of signatures so that you can establish a 
sequence as a directed graph.  

The sequence does break.  It's not perfect at all.  Signing chains can't
be traced back infinitely.   A signer is not available to affirm that the
sequence is correct.  There will be parallel sequences of signing 
chains where there aren't crosslinks available to help you interleave 
events.  

Constantly establishing keys doesn't make sense.  The algorithm works 
just as well if there is a third bit of data, a use-once token.   Can that 
work?  Don't know.

Like anything else this half assed, somebody must have already written 
this idea up better with actual discipline! 

- Lucas