Topic: timestamping, namespaces, validation & bitcoin (Read 859 times)

Another time-related concept is a beacon - that is a broadcast, unpredictable and fairly chosen random value.  Eg like this weeks national lottery numbers, someone has gone to lengths to ensure they are chosen fairly, and they are published widely on TV, internet, newspapers etc.  You could view the latest bitcoin block hash as a bit like a beacon.  Even the miner cant control all the bits - it costs him enormous computation just to control the first 55 bits (current log2 target).  There are another 101 bits he cant control; he could control 1 bit by doubling his effort and reducing his mining reward by 1/2 etc.  To control them all is considered impossible.

Say each user, or users collaboratively store the sequence of beacons and vouch for the correctness.  (In the case of the a time-stamp merkle hash chain, used as a beacon it helps you verify that because each block hash includes the previous hash in its preimage.)

You might wander if one could use an abstract beacon for timestamping (beacon without preimage chain).  Could use a beacon to prove that you made a transaction, or mined a pool-sized mining share at a given point in time?  Not fully: if you include a hash of a beacon in your mined pool share, or transaction signature, then you do prove that you did that after the beacon.  However you can also back-date your operation.  Eg you could intentionally include an old beacon value.  Because bitcoin is more concerned about back-dating than forward dating, it doesnt help much.  (Bitcoin concerns itself with first to do something, not last).

To prevent backdating, bitcoin (and time-stamp servers, and auditable name-spaces) put the hash that you are dating into the "beacon".  That proves it was published then.  It may also have been published earlier (ignoring validation), but at least you cant create something and then try to change its date of publication.

Unfortunately to prevent backdating seems to require transmitting all values to the timestamper/namespace manager.  And in a distributed timestamper/namespace manager broadcasting to all full nodes.

A namespace manager also wants to enforce first come first served (no name reuse) so it enforces that it wont stamp names (or name hashes) that it has seen before.  (If the names are random looking like public keys, hashing names is secure against brute-force, unlike hashing domain names or email addresses, so with bitcoin, like with document time-stamping you are not revealing the document/public key at the time of publication).

Adam

I've been trying to understand the relationship between timestamping, namespaces and validation in bitcoin.

Bitcoin is described as relying on a timestamping service.  Now in existing (non-bitcoin) time-stamping service, merkle trees are used to hash a set of documents users want to time stamp during a period into a merkle tree.  The merkle tree root is published (assumed unchangeable)  The previous periods merkle root is also hashed into the current merkle tree, to prevent historic modification.  (Just like bitcoin in fact so far).  The time-stamp server may sign the merkle root; bitcoin substitutes a distributed attempt to create a proof-of-work for a signature that the current majority by CPU power agree is correct.

But bitcoin is more than a timestamping of transactions.  Timestamping does not guarantee uniqueness.  Users are allowed to stamp the same document more than once.

So lets consider a less distributed bitcoin where peers rely on a time stamping service.  Consider it has only full nodes for now.  To know transactions are not double spent they have to track all documents (transactions) hashed by the timestamp server each time period.  If the timestamp server signs its hash every period, if it ever cheated and issued a second merkle root for the same period, all peers would have a proof (and could migrate the timestamping over to a competing time-stamp service).

However that is not convenient for SPV nodes, the only way to know a transaction was not already spent is to look at all time-stamped documents (transactions) ever.

Namespaces have the missing property.  A namespace manages and allocates names on a first come first served basis.  The same name is not allowed to be issued twice.  For bitcoin purposes we'll consider names do not expire and so do not become available for recycling.

We could use a namespace to implement bitcoin.  Eg consider DNS name .bitcoin operated by a somehow trustworthy registrar with the first come first served, never expire policy.  Now we could mine by being the first to claim the name being a hashcash stamp (mined as bitcoin on the hash of a public key).  Stamps which dont match difficulty are ignored or rejected.  When we spend we claim the name being the public key and output.  As owner of the name we can attach txt records to it (eg the signed transaction including the public key hash of the new owner).  For bitcoin purposes transactions which are not signed are ignored or rejected and with names (public key+outputs) that dont correspond to previous txt records (public key hashes of coin owners) are ignored or rejected.

Namespaces can be some-what distributed but publicly auditable to reduce or even avoid any trust in the registrar.  

eg http://cypherspace.org/p2p/auditable-namespace.html

If no trustworthy registrar could be established, the protocol could fall back to current the full p2p bitcoin namespace of the list of transactions.


Bitcoin does one more thing beyond namespace management which is to expect the miner (distributed transaction namespace node) to validate transactions.  Meaning that the inputs have sufficient value to cover the outputs.  That implements coin splitting and combining.  SPV nodes even rely on that, full nodes check it themselves.

Note that with the exception of validation, a namespace manager (auditable and being distributed, somewhat-distributed, or even central) does not need to know the names nor documents.  ie It is normally the case that a time-stamping service does not know the contents of the documents it is stamping.  Eg because they are published in hash form, or hash of non-malleable encrypted form.  The same can be true for namespaces.  It reduces the need to trust a time-stamp server or name-space server if it doesnt know what it is timestamping/allocating names of.  That is because it cant apply apriori policies about whose documents it will process, nor what the documents can contain, nor who they can be addressed to if it doesnt see the document.  

And it can not undetectably revise history because of the published chain of merkle hash roots.  And if it does detectably revise history, other servers or peers in a p2p protocol can reconstruct the true history.  Consequently a mostly trustworthy server (say 99% of transactions have no attempt to modify history by the server) we can still leverage service from such a server.  Its easier to scale such a server and users can then concentrate on validation and reconstruction and repair of history revisions which is a 1% problem vs a 100% problem.

Adam