[Cryptography] Dispelling some myths about Bitcoin, from a Bitcoin fan

[lmgoodman at hushmail.com]

~ Dispelling some myths about Bitcoin, from a Bitcoin fan ~
Many people who don't know much about Bitcoin, or who have a poor
grasp on economics, have severe misconceptions about Bitcoin. I do not
attempt to dispel those myths here because many others have already
done so. Rather, I'd like to dispel a few myths that are pervasive in
many people who are generally knowledgeable about Bitcoin.
While some of you may find that more than a few of these myths are
"obvious", they have all been included because I've encountered
several otherwise intelligent people who believed them. If they do not
enlighten you, at least let them be a reminder to dispel those
misconceptions when you encounter them around you.
Myth #1: Satoshi solved the Byzantine Generals problem which was
thought impossible to solve!
Fact: The consensus problem isn't that difficult, it's about who's
allowed to take part in it.
There is a wealth of literature on the Byzantine Generals problem, and
many solutions have been proposed. The solutions to this problem are
indeed often quite complex - unless they are synchronous and use
public key cryptography. With the use of public key cryptography (such
as the elliptic curve signatures used in Bitcoin but also SSL and
countless applications) and synchronicity the problem is considered
trivial: it boils down to a majority vote[1]. As Ben Laurie points
out[2], the problem that the block chain attempts to solve isn't *how*
a consensus should obtained but *who* should be a part of that
consensus. If, say, IP addresses, were used as the consensus group, an
attacker could control the chain by controlling a large swath of IP
addresses, an attack known as the Sybil attack. The consensus group
for Bitcoin is hashing power, a scarce resource. 
Myth #2: The proof-of-work system is great because it incentivizes
miners to upgrade their equipment, thus a lot of computing power is
powering Bitcoin.
Fact: These upgrades do nothing to increase the transaction processing
capacity of the Bitcoin network.
Let's start with what upgrades do accomplish. The race to build more
hashing power (by developing ASICs for instance) means that the cost
to pull off a 51% attack on the network increases. In this respect,
the network is more secure. Note however that the amount of money
spent on mining and mining equipment must be approximately equal, in
the long run, to the amount of bitcoin paid in transaction fees or
created through mining. Given off chain transactions, this could
dwindle to very low levels in the future. However, the processing
power itself doesn't matter. The only thing that matters is that
something expensive is being irreversibly spent, to make it hard to
attack the network. Spending money on computing power has the nice
property that you can easily prove it online, but the computations
themselves are deliberately done on worthless problems. Emphatically,
this computational power is *not* used to validate transactions, an
operation which only takes a modest amount of computing power. More
hashing power does not mean that the Bitcoin network can process more
transactions per second or process them faster.
Myth #3: Bitcoin is a math-based currency / is backed by math.
Fact: Bitcoin is based on a clever set of incentives.
Part of Bitcoin is indeed math based: its cryptography. Cryptography
makes computational guarantees based on widely believed (but not yet
proven) mathematical conjectures. For instance, Bitcoin payments rely
on signatures which are computed using exponentiation (or
multiplication, depending on how you think about it) in an abelian
group. Faking those signatures would require solving the discrete
logarithm problem in elliptic curve groups, a problem that the
mathematical, computer science and cryptographic community considers
very unlikely to be solvable efficiently on a classical (non quantum)
computer. In this context, "not efficient" does not mean "too costly"
or "impractical", it means that the amount of computing power needed
to solve those problems reaches literally astronomical proportions.
However, the cryptography in Bitcoin is the easy part. The safety of
the Bitcoin protocol strongly relies on the impracticality of forking
the block chain. The assumption made is that miners are incentivized
to behave honestly with pecuniary rewards. This makes it costly to
attack the system, and even gives a would be attacker an incentive to
still behave honestly. This set of incentives is carefully balanced to
maintain honesty in the system and avoid conflicts of interests. This
really is the heart of the block chain, and it relies on *game-theory*
not mathematics. Yes, game theory is a branch of mathematics, but to
call Bitcoin a "math-based currency" because of its reliance on game
theory would be like calling plumbing "biology based" since plumbers
happen to be biological organisms. There are no mathematical or even
computational guarantees, only a set of incentives. This isn't to say
that the design of incentives in Bitcoin isn't clever or even artful,
but to call the currency math-based, or worse math-backed, is either
dishonest or ignorant.
Myth #4: The proof-of-work system is completely decentralized
Fact: Trust is still involved in the system
One idea behind the block chain is that anyone downloading Bitcoin for
the first time can identify the real block chain from its forks by
simply looking at the chain starting from the genesis hash and
totaling the most hashing power. This means you do not need to extend
trust to anyone... once you have downloaded the Bitcoin client. But
where should you download the Bitcoin client? How do you know
bitcoin.org isn't controlled by malicious attackers? Well perhaps you
could look at the developer's signature of the binary or at the source
code. But how do you know who the official developers even are? You
could Google that information and find that many reputable news
organization all seem to agree that a certain "Gavin Andresen" is one
such developer. But then again, perhaps the Wall Street Journal, the
New York Times, Bloomberg, the Financial Times, Al Jazeera, Xinhua,
the Guardian, Pravda, Google, Yahoo, Bing, Duckduckgo, etc are *all*
conspiring to trick people into downloading a version of the Bitcoin
software with the wrong genesis hash and perhaps a different proof of
work function. They could succeed provided that you don't notice that
this network has no Bitpay, no Coinbase, no Bitstamp, etc.
Obviously, I am not trying to argue that you cannot reliably download
the "real" Bitcoin client, such a conspiracy is ridiculously unlikely.
But this operation isn't decentralized, it relies on a distributed
consensus among reputable peers - something that seems anathema to the
ethos of Bitcoin. One could argue that Bitcoin minimizes the reliance
on this consensus, by making it a one time thing... but this consensus
is required every single time a new client joins the network.
Perhaps the right answer is that the reputation based, distributed
trust mechanism works reliably at low frequencies (on the scale of
months to years) while the proof-of-work mechanism works best at high
frequency (10 minutes for Bitcoin). While I have a lot of sympathy for
Ripple's distributed ledger (which is similar to the mintlets
described by Ben Laurie [3]. No, I'm not referring to the network of
credit line that ripple maintains, but to the consensus system, which
is totally orthogonal to it), I think the right answer is probably a
mix of technologies. Bitcoin's checkpoints for instance, while
inelegant, make use of the low frequency trust mechanism to complement
the safety of the proof of work system. But this also means that much
of the first-principle type of objections to proof-of-stake
mechanisms, are too theoretical.
Myth #5: A decentralized system is safe
Fact: not necessarily 
Decentralization implies that you do not need to trust anyone *a
priori*, but you may have to trust someone *a posteriori*. Indeed, the
bitcoin ecosystem has degenerated into a distribution of hashing power
where ghash.io holds nearly 50% (and recently as much as 51%) of the
hashing power. They could collude with any another pool manager (or be
forced to collude by an attacker, such as a government) to obtain a
majority of the hashing power and launch a 51% attack on the chain.
This does not seem particularly safer than explicitly choosing a set
of reputable organizations. Is a group such as the Wikimedia
foundation, the Swedish Pirate party, Wikileaks, and, say, the
University of Hong-Kong more or less likely to collude than the
current pool operators? If we are to believe developper Gavin
Andresen, this is not such a big deal because ghash's incentives are
to behave honestly. In this case, why bother at all with a cumbersome
proof of work system? Let us have ghash sign every block and be done
with it; the system would be far more efficient, much cheaper and just
as safe. 
Myth #6: Decentralized crypto-ledgers are just a technology and have
nothing to do with politics. 
Fact: Crypto-ledgers are primarily designed to withstand attacks by
governments, that is their *only* advantage of a decentralized
crypto-ledger over a centralized or polycentric one. 
If you think government is a fundamentally nefarious institution and
that decentralized crypto-ledgers could be a powerful tool in
liberating the economy from their grip, then welcome to the club. But
if you think (as a famous VC does - or at least claims to) that they
are a fantastic invention that is much bigger than envisioned by their
cooky, fringe, libertarian makers, then... Actually I don't even want
to convince you otherwise, yay distributed crypto-ledgers! 

[1]
http://research.microsoft.com/en-us/um/people/lamport/pubs/byz.pdf[2]
http://www.links.org/files/decentralised-currencies.pdf [2]
http://www.links.org/files/distributed-currency.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140614/17d024ef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sig.gpg
Type: application/octet-stream
Size: 4701 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140614/17d024ef/attachment.obj>