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.htmlIf 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