Author: Adam Back 2014-12-22 20:05:40
Published on: 2014-12-22T20:05:40+00:00
In a discussion last year on "disentangling" blockchain design, the author outlined candidate layer properties that could be used to construct a decentralized PoW-chain assured immutable history based ecash system. The two properties identified were time-stamping and namespace. Time-stamping creates an immutable stream of data items that came from various users with a time-ordering placed on them, while namespace adds the uniqueness and first-come first-served property up-front. The author explored whether the consensus critical code could be simplified for security and if there were any improvements that could be found. They concluded that it was pretty hard to find any improvements. For bitcoin composability purposes, no hidden commitments are required. Namespace attributes hold information like a public key to approve changes in ownership, an IP address, an email address, etc., and for efficient proof reasons, there is still a merkle tree per PoW time-interval binding names into a hash-chain.For bitcoin re-described using a namespace, the unique coins are the names, and values and ownership public key etc are attributes of the name. Transfers are approved via digital signature, and the additional property bitcoin requires is that the values add up. Proof of publication is essential as it ensures that miners should not build on top of blocks unless they have copies of all data committed to. There is some meta-incentive for bitcoin holders to help others catchup and be assured of the history, and information has to be broadcast as there are many miners and full-nodes. Anti-relay term is meant at the system level, rather than node level, though technically bitcoin nodes in the current protocol version don't relay double-spent transactions. Philosophical differences between proof of publication & anti-relay (or namespace for that matter) do not necessarily have practical implications. It is important that there is no way to attack the insertion logic so that someone can't get a hash into an internal nor leaf node of the merkle tree without the miners first seeing that data. The distinction just comes down to what features are assumed to be naturally included in the layer definition and what features have to be added. From that perspective, it makes sense to say there is a layer that provides assurance of availability of history; the PoW-chain and merkle-tree in the header assures already immutability.
Updated on: 2023-06-09T15:01:20.754754+00:00