Bit Gold and Bitcoin

Throughout the 1990s and into the 2000s Nick Szabo developed ideas for a system he called Bit Gold. Szabo conceived Bit Gold as a form of reserve currency which was created by participants performing a proof-of-work function on computer hardware. Once a participant had created a piece of Bit Gold they added it to a securely time-stamped and publicly accessible registry that recorded all the Bit Gold in existence. The entry they created on this registry formed their proof of title to the Bit Gold and it was on this registry that any subsequent transfers in title of the Bit Gold would be recorded.

In an unpublished and incomplete white paper entitled ‘Bit Gold: Towards Trust-Independent Digital Money’ Szabo outlined the essentials of the system as follows:

(1) bits are generated using an algorithm of known computational cost, e.g. computing an n-bit hash collision (as proposed by Rivest/Shamir for MicroMint and implemented Adam Back with hashcash). In general there are challenge bits input into a benchmark function, which produces solution bits. The desiderata of a benchmark function is fundamentally different from that of a cryptographic one-way function, and I have developed a new formalization to reflect this[1]. Anyone interested in studying such functions, please contact me.

(2) the bits which are the solution to the challenge are added to a multiparty hash chain (i.e., they are securely timestamped), then converted into the next challenge.

(3) Representations of ownership of these solution bits are stored in a public manner, e.g. in a distributed property title registry I also originally suggested (both off the list and in an impractical but privacy-protecting form I described on the list) that publically known levels of wealth can be represented by a system of publicly shared books. However, I think using this approach and discarding the solution bits raises several unecessary problems.

(4) Titles to the bits are traded, achieving a market price based on their estimated original cost of computation and continuing scarcity versus the demand for a secure long term store of value.input into a benchmark function, which produces solution bits. The desiderata of a benchmark function is fundamentally different from that of a cryptographic one-way function, and I have developed a new formalization to reflect this[1]. Anyone interested in studying such functions, please contact me.

This description is tantalizingly close to the Bitcoin subsequently published by Satoshi Nakamoto in 2008, however there are some very clear differences.

Proof-of-work

Szabo does not consider a one-way function, such as the SHA256 hashing function used in Bitcoin, as an appropriate proof-of-work for Bit Gold. The reason for this is Szabo’s concept of Bit Gold requires the amount of work required to create each piece to be quantifiable so that the market can price it. A prohibitively difficult function such as one-way hashing function is not quantifiable in this sense. Instead Szabo proposes a benchmark function: a function whose difficulty is precisely quantifiable in abstract terms.

Supply

Szabo envisages that the difficulty of creating or ‘mining’ Bit Gold will vary over time. He doesn’t assume that it will get easier or harder over time but that at various points in the timestamped history of Bit Gold recorded by registry it will be possible to see fluctuations in the amount of Bit Gold getting created. This may happen for any number of reasons, including a change in the proof-of-work function or advances in technology that make existing functions easier to perform. Therefore people who trade the titles to Bit Gold in the registry will assess the value of a particular piece of Bit Gold taking into account how difficult it was to create Bit Gold at the time that piece was created. Bitcoin, on the other hand, is designed so that it gets harder to create Bitcoin over time and there is in fact a finite amount that can ever be created.

Means of Exchange

Szabo conceived Bit Gold as a reserve currency and not as a form of electronic money in itself. Bit Gold would ‘back’ another form of electronic currency in the same way that physical gold once backed money in the era before fiat currency. While the public record of Bit Gold created over time is stored on a time-stamped hash chain where the most recently added piece of bit gold is used as input to the function that creates the next one, the exchange of title to the bit gold among traders envisaged in the Bit Gold system takes place on a separate entity that is a ‘distributed property title registry’. Szabo discusses the possible workings of this registry in some detail in a separate paper. It too is a chain, but in this case each chain represents the history of ownership of a particular piece of bit gold. Private and public keys are used to transfer ownership. The registry of title chains iis maintained by a network of computers that vote on changes and only accept those agreed by a quorum of participants.

So the question I have set out to explore here is whether it is possible for someone to conceive the idea for Bit Gold as outlined above, realize its problems, and then subsequently adapt it into a related but in many important ways quite different system called Bitcoin?

The fact that one system sets out to be a long term store of value and the other a form of electronic cash, and that each has a very different approach to the concept of how value is created, does not detract from the fact that the main features of each system are overwhelmingly similar. Let’s examine these features and see how closely related to each other they really are.

In both Bit Gold and Bitcoin value is created by computers performing a task that is known to be difficult. In Bit Gold, the more difficult the task the more valuable the bitgold created. In Bitcoin, the tasks get more difficult over time but this has no effect on the value of the bitcoin the tasks create: the purpose of the increasing difficulty is simply to limit the rate of increase in supply.

Unfortunately for Szabo, although he was able to formally define the properties of a benchmark function with quantifiable difficulty, his unpublished draft of a Bit Gold whitepaper shows that he was not optimistic it was practical for him to ever design such functions:

For bit gold we need a benchmark function whose upper bound on common hardware (i.e. RAM-log) is within a small factor (e.g. log(n)) of the lower bound for any realizable machine model. To prove this exists, we need

(a) a list of machine models which is comprehensive of all physically realizable machines, in the sense that any such machine can be simulated with a very small overhead, such as constant or O(log(n)), by some model on the list, and

(b) to prove lower bounds on a benchmark function for all models on the list

So I have probably too much research to do in these areas. I might find that such a comprehensive list of models does not exist and would be very difficult to draw up for some basic reasons?

Szabo’s proposals for such functions appear to have come to nothing so it seems possible that at some point later he returned to consider more closely the simple, but unquantifiably prohibitive, one-way functions used by Hashcash. Had he done so, and there is evidence on his home page that he downloaded and compiled hashcash on the same machine hosting his website, the design choice of a one-way hash function would have the immediate implication that individual pieces of bit gold could not be assigned value according to their specific difficulty at the time they were ‘mined’ or created. The reason for this, in case it is not already clear, is that individual pieces of bit gold are expected to be priced according to how difficult it was in principle to solve the proof-of-work function that created them using available technology at the time they were created. This design feature was in fact something of a problem for Szabo as it led him to envisage bit gold markets behaving in unusual ways in order to auction lots of bit gold of varying provenance in blind auctions so that traders would assign a price to bit gold according to their knowledge of the relative blend of difficult and easy bit gold in the market as a whole and pay for ‘normalized’ lots accordingly.

So while the impracticality of benchmark functions means that individual pieces of bit gold no longer have a value specific to their provenance it also helpfully removes some of the complexity required to normalize the value of bit gold as a whole. If forced to use a simple one-way hash function as proof-of-work what can such a system do about the supply and pricing of the bit gold it generates?

If bit gold cannot be assigned value according to its place in the time-stamped hash chain in which it is recorded then the only remaining function of the hash chain is to record its actual creation. The value of the bit gold itself can only be assigned according to the overall scarcity of bit gold itself so it follows that the hash chain must represent a finite supply of bit gold, otherwise the value of bit gold will approach zero as the hash chain approaches infinity. Thus the total supply of bit gold must be finite in this revised design.

So with a timestamped hash chain recording the creation of the finite supply of bit gold, what about the separate title registry that records the acquisition of title to each piece of bit gold, including the title of the original miner? The original motivation for maintaining this registry separately from the timestamped hash chain was to separate the critical duty of maintaining an accurate record of when the bit gold was created (because that is essential to assaying its value) from the public record of ownership (where we only need to know who is the most recent owner). Now that it is no longer important to ensure that the process of agreeing on title to bit gold does not delay or interfere with recording the time of its creation and nor is it necessary to know when a piece of bit gold was created (but it is still important to record who owns it), it seems that all we really need is a title registry that records the creation of the bit gold and subsequent transfers of ownership. This registry stores the record of the bit gold coming into being, the title of the person who mined it, and any subsequent changes in ownership. The most recent owner recorded on the registry is the current owner.

Having started out with two chains, a timestamped hash chain recording the creation of bit gold and a chain of public-private key signatures transferring ownership of the bit gold, we now only need one. Our target design here is Bitcoin, which merges the two chains envisaged by Szabo, into a single time-stamped hash chain which records the creation of new Bitcoin by taking the transfer-of-title records as input to the proof-of-work function that creates the Bitcoin! The question we are asking here is: what would be required to start from the position we are in now and arrive at the elegant solution embodied in Bitcoin?

From where Szabo was standing in 2005 the next obvious design choice available to him was in fact to ditch the time-stamped hash chain and move everything onto the title registry. The exact opposite of the Bitcoin design. The reason this was his obvious next move was because the title registry is responsible for solving the next biggest problem in Bit Gold apart from establishing its value, which is preventing double-spending. The title registry would do this by using a quorum system among the distributed maintainers of the registry for voting on whether to accept transfers of title to Bit Gold. This quorum system would ensure that participants attempting to transfer titles to bit gold twice-over to different people would not succeed. Now that it was no longer important to establish when a piece of bit gold was created in order for it to have value in the system it only remained to ensure that bit gold was not transferred twice.

The problem with integrating everything into the registry system is that the system still needs to know when Bit Gold was created so that it can know from what point in time it is valid for someone to transfer or assign its ownership. The registry still needs a timestamping service to rely on. Again we are back to needing a separate timestamping hash chain, or at least a registry incorporated in a timestamping hash chain.

The problem with merging the two functions into one chain is that the requirements of the registry, a voting process that can take an indeterminate amount of time, and the requirements of the timestamping hash chain, which needs to accurately record the creation of bit gold chronologically and accurately as soon as possible, are incompatible. It is an obvious step to use the transfers of title recorded by public and private key signatures as inputs to the timestamping hash chain (which is how Bitcoin’s blockchain indeed works or as Nakamoto called it in early versions of the Bitcoin source code the ‘timechain’) but it is not obvious how voting on the valid transfers can still happen in a way that does not impede the proper and timely recording of new timestamps.

What is required to achieve our final, hypothetical leap from the starting design of Bit Gold to the final architecture of Bitcoin is to realize that agreement on the inputs to the time chain, i.e. the title transfers, does not need to be achieved by a complex voting process between nodes on a network. Instead it can be achieved by simply expecting every node on the network to accept the first valid addition to the timechain it receives from any other node and to assume that all the other nodes will do the same. Nakamoto devotes two of the eight pages of his Bitcoin paper explaining the maths behind why this very simple idea will work as long as honest nodes who obey this rule account for more than 50% of the computing power on the Bitcoin network. The unreasonable effectiveness of this simple rule, compared to the byzantine complexity of voting protocols required to assure the honesty of previously proposed consensus networks, is the unprecedented breakthrough of Bitcoin. There is no hint of this revolutionary thought in Szabo’s Bit Gold designs. On the other hand it arises almost like an emergent property from the experimental step of joining the chain and registry together and letting them work together in the only way which it is possible for them to do.

We have set out a reasonable design journey from Szabo’s Bit Gold to Nakamoto’s Bitcoin. One that it is not impossible for Szabo to have followed himself once he accepted that benchmark functions were not a practical choice for proof of work and that his design would have to make do with a one-way function similar to hashcash. With one-way hash functions as a proof of work the properties of variable value envisaged for Bit Gold would have had to be discarded. Since it is no longer important to accurately record when a particular piece of Bit Gold was created, only the point at which it was first created, the need for a dedicated time-stamping hash chain also disappeared: the functions of title transfer and bit gold creation could be merged to a single system. The final step is to realize that once you have joined the two systems together the complex voting procedure required for determining valid inputs to the chain is unnecessary and can be served simply by allowing the ‘timechain’ to safely accept new blocks on a first-come first-served basis. The sole condition required for this to hold is that honest participants should always account for more than half the computing power.

In 2011 Szabo himself reflected on the difficulty of what Nakamoto had achieved with Bitcoin. He dwells particularly on the fact that ‘nearly everybody who heard the general idea [of electronic cash] thought it was a very bad idea’ but he also identifies the same two important changes Nakamoto introduced with his design.

Integrating the timechain and the registry:

(3) Nakamoto improved a significant security shortcoming that my design had, namely by requiring a proof-of-work to be a node in the Byzantine-resilient peer-to-peer system to lessen the threat of an untrustworthy party controlling the majority of nodes and thus corrupting a number of important security features. Yet another feature obvious in hindsight, quite non-obvious in foresight.

The fact that bitcoin does not depend on the date of its creation in order to assume its value:

(4) Instead of my automated market to account for the fact that the difficulty of puzzles can often radically change based on hardware improvements and cryptographic breakthroughs (i.e. discovering algorithms that can solve proofs-of-work faster), and the unpredictability of demand, Nakamoto designed a Byzantine-agreed algorithm adjusting the difficulty of puzzles. I can’t decide whether this aspect of Bitcoin is more feature or more bug, but it does make it simpler.

This observation misses the relationship between proof-of-work and value in Bitcoin. Bitcoin adjusts the difficulty of creating bitcoins in order to produce them at a predictable rate over a finite period of time. As Nakamoto stated on bitcoin.org in 2009:

Total circulation will be 21,000,000 coins. It’ll be distributed to network nodes when they make blocks, with the amount cut in half every 4 years.

first 4 years: 10,500,000 coins

next 4 years: 5,250,000 coins

next 4 years: 2,625,000 coins

next 4 years: 1,312,500 coins

Etc…

Szabo’s automated markets were designed to normalize the market value of bit gold given the expected wide variations over time in the cost of creating a potentially inifinite supply. Bitcoin decouples the concept of difficulty from the value of Bitcoin completely — the purpose of difficulty is simply to control the rate at which the finite supply is created. The value of Bitcoin itself is decided outside the system, by exchange markets. If Szabo had designed Bitcoin as a successor to Bit Gold this is not an observation we would expect him to make, even in a context where he was disavowing Bitcoin as someone else’s work.

So even though we have a relatively small set of steps (in hindsight) to start at Bit Gold and arrive at Bitcoin, I believe we have to accept that Szabo’s subsequent writings on Bitcoin do not reflect the thinking of someone who has taken those steps. Szabo is still looking at Bitcoin as though it is a store of value, like Bit Gold, while Nakamoto explicity envisages it as a means of exchange whose value will be decided by a market evaluating its limited supply.