Satoshi Nakamoto announced Bitcoin in the “Bitcoin Whitepaper” in 2008.
The Bitcoin Whitepaper describes how to create peer-to-peer electronic money.
All of the design decisions discussed in the whitepaper reflect this objective.
The Bitcoin Whitepaper does not mention “blockchain”.
The
Bitcoin Whitepaper mentions a “timestamp server” based on validating
blocks of transactions that the software it describes uses to establish
the order of transactions over time.
Bitcoin does this in order to solve the “double-spend problem” without resort to “trusted third parties”.
Bitcoin must do this in order to function as peer-to-peer electronic money.
The construction of a public ledger of transactions gathered into blocks and validated using a proof-of-work algorithm in return for economic incentives paid in the currency that the system exists to create is a contingent technical element of doing so.
Blockchains
and proof of work are not original to Bitcoin, there were more
interesting hashing or signature schemes available in 2008, and Nakamoto
Consensus does not represent the first solution to the Byzantine
Generals problem in computer science.
This
use of economic incentives to construct a data structure in an
adversarial environment is Bitcoin’s only technical innovation.
We
can exploit the contingent technical elements of Bitcoin’s design for
peer-to-peer money as primary technical elements if they are appropriate
responses to design challenges that we face elsewhere.
They
are appropriate responses if they support the instantiation of the
project’s stated goal with the same degree of utility that they support
Bitcoin’s stated objective of producing peer-to-peer electronic money,
or at least to a high degree.
Such
instantiations stand a better chance of not being
solutions-in-search-of-a-problem or having broken economic incentive
structures.
The building blocks of the Bitcoin whitepaper can also be exploited as primary concepts if they represent appropriate responses to the conceptual challenges of a project.
We must be careful not to fetishize or miscast them.
For example “trust” in the Bitcoin Whitepaper appears only in the phrase “trusted third parties”, taken from the writing of Nick Szabo, and refers to the unjust and unavoidable intervention into social relationships of potential opponents that might better be described as “treacherous third parties” in the style of Richard Stallman.
In both the technical and conceptual cases, varying emphasis or adding or removing elements from those present in Bitcoin without sufficiently addressing the impact of doing so or the ideological and economic balance of the resulting system can negatively affect its appropriateness and viability.
It
is therefore vital to understanding how each element of Bitcoin
contributes to doing the one thing that Bitcoin is actually meant to do
and be, and being very careful when seeking to produce systems that
exploit elements of it of it for purposes other than that.
All
of this means that a better question than “does this project need a
blockchain?” would be “what is the conceptual equivalent of peer-to-peer
digital money in this domain and if this is an idea worth pursuing how
would we go about constructing it?”.
That is a more difficult question though.
