That which does not kill Bitcoin makes Bitcoin stronger
The Mt. Gox situation finally came to a head last night with a mysterious “crisis strategy” document surfacing, a number of prominent exchanges and wallet services releasing a joint statement, and finally Mt. Gox halting trading and releasing a non-statement this morning.
Only Mt. Gox really knows the extent of their losses yet, but if the rumors are true, 744,408 bitcoins, representing 6% of all issued bitcoins, may have been stolen. This could have a significant impact on the adoption and regulation of Bitcoin. The “crisis strategy” document (of unknown authorship) states:
With Bitcoin/crypto just recently gaining acceptance in the public eye, the likely damage in public perception to this class of technology could put it back 5-10 years, and cause governments to react swiftly and harshly. At the risk of appearing hyperbolic, this could be the end of Bitcoin, at least for most of the public.
However, “that which does not kill us makes us stronger” very much applies to Bitcoin, and the downfall of a single (though large) Bitcoin business is not enough to “kill” Bitcoin. This type of event has happened before. We learn a tough lesson and carry on, strengthening the weakest links as we go.
Some people are pointing to Gox’s failure as a reason Bitcoin needs more governmental regulation, but I believe cryptography and peer-to-peer consensus protocols can eventually replace the need for certain types of regulation entirely.
The rest of this article discusses ways the Bitcoin ecosystem can be improved to be more robust against a variety of threats, including Gox-like failures and fraud. This is mostly a summary of ideas from other people who are much smarter than me. Some of it is a bit hand-wavy, but hopefully it will give you a glimpse of the possibilities. If you’re interested in these things be sure to read all the links.
Bitcoin itself is a trustless and decentralized system, but the Bitcoin ecosystem currently relies on many trusted centralized services. Fortunately, trustless and/or decentralized versions of many of those services could be built using clever combinations of cryptography, P2P networks, and “smart contracts”.
“Decentralized” and “trustless” are really two distinct properties, with different advantages:
- Trustless: reduces or eliminates counterparty risk
- Decentralized: provides censorship-resistance, permissionless participation, and optionally anonymity (often requires trustlessness, since anonymity greatly increases the risk of fraud)
Decentralized/trustless services are almost always more difficult to build than equivalent centralized services, which is why we usually see new ideas first built as centralized services, and later replaced with decentralized versions as needed (notable exceptions include early Internet protocols like email and the web, which were decentralized from the beginning).
Some of these decentralization efforts have been more successful than others. Decentralization usually comes with some cost in efficiency, usability, or complexity, so the system will only thrive if the benefits of decentralization outweigh those costs.
Napster popularized file sharing, but as a centralized service it was quickly shut down by lawsuits. Decentralized services like Gnutella and BitTorrent quickly filled that void.
Censorship-resistant and Anonymous Proxies, Messaging, and DNS
- Anonymity networks like Tor and I2P are more anonymous and robust alternatives to VPNs and HTTP/SOCKS proxies.
- I2P and Bitmessage are anonymous, censorship-resistant messaging systems.
- Namecoin is a censorship-resistant alternative to DNS.
These are relatively niche systems because most people don’t care about strong anonymity and aren’t actively being censored.
PayPal and many other services have allowed users to send money online for a long time. Bitcoin is the first system that allows you to send money online (or offline, for that matter) without trusting anyone and without asking anyone for permission.
Decentralization/Trust Minimization Efforts in the Bitcoin Ecosystem
Provably Fair Gambling
Bitcoin gambling sites can cryptographically prove their system is “fair” by regularly publishing a hash of the seed to their random number generator, then later revealing the seed so that users can audit them. It’s a fairly common feature (search for “provably fair” here), but that wasn’t always the case. Once one site implemented it, other sites had to follow to remain competitive.
This is an excellent example of how cryptography can replace the need for regulation.
Bitcoin mixers allow users to mix their bitcoins with other users’ bitcoins for privacy purposes. Mixers have been around for several years, but until recently using one required trusting the operator not to disappear with your bitcoins.
Trustless mixing accomplishes this without having to trust other users or an operator. Gregory Maxwell’s CoinJoin is one scheme for doing this with varying levels of decentralization. SharedCoin and Dark Wallet implement some of these ideas.
Centralized anonymous online marketplaces (e.x. Silk Road) are very vulnerable to shutdown (even on Tor) as well as fraud (especially on Tor). It’s very likely decentralized marketplaces will begin to emerge soon.
Centralized solutions typically use escrow to reduce the chance of fraud. A decentralized marketplace could use an 2-of-3 multisig escrow transaction with a mutually agreed-upon 3rd party mediator. This is discussed in Lex Cryptographia.
NASHX-style “Mexican standoff” transactions are another possibility:
NASHX is about enabling two untrusted parties to make safe exchanges online by putting them in a Mexican standoff. We put two untrusted parties into Nash equilibrium, through a military strategy called Mutually assured destruction so that neither party has anything to gain by scamming one another.
Update: NASHX acts as a trusted third party, but this can be avoided using Bitcoin contracts, as described by Oleg Andreev.
It’s difficult, if not impossible, to eliminate all counterparty risk when exchanging fiat currencies and cryptocurrencies because, unlike cryptocurrencies, it’s impossible to transfer actual dollars over the internet. When you use a credit card/PayPal/wire transfer/ACH you’re really just transferring debt around, and someone is always trusting someone else will eventually pay that debt. When you transfer bitcoins you really are transferring ownership.
When that risk can’t be eliminated we can try to minimize it by aligning incentives and demanding transparency. Bitcoin can help facilitate both, more so than any previous system.
Proof of Reserves
The easiest and most likely immediate change is Bitcoin services can easily prove that they are actually holding enough bitcoins to cover customer’s balances. This almost certainly would have significantly limited the (presumed) losses at Gox, at the very least by forcing them to implement an accurate accounting system which would have alerted them to the problem much sooner.
It’s trivial for anyone to prove they hold a certain amount of Bitcoin by signing messages using the private keys of their addresses, and Gregory Maxwell outlined a scheme by which a service could prove to a user they hold the funds for them they claim to.
The main issue with this is that services may be reluctant to give out this information if they consider it useful to competitors. However, Coinkite is already providing an audit report with proof of reserves, so much like provably fair gambling other services may have to follow. Radical transparency could be a competitive advantage, especially for new services.
Update: gmaxwell described how zero-knowledge proofs could be used to avoid revealing a service’s total holdings.
Update: Zak Wilcox is documenting the proof-of-reserves movement, including various services’ efforts, or lack of efforts, to prove reserves.
Today most Bitcoin transactions are simple “transfer N bitcoins from A to B” transactions, but Bitcoin contains a largely unexplored transaction scripting language, aptly called “Script”, that can be used to do all sorts of interesting transactions which can minimal trust. A few ideas are detailed on the wiki, as well as in this excellent talk by Mike Hearn. “Multisig” transactions (mentioned above) are one simple example of a contract.
Another application is atomic cross-chain trades between cryptocurrencies, which requires no trust at all. Fiat-backed alt-coins or “colored coins” could also be traded atomically, however this does introduce counterparty risk.
Trading on-chain would be many orders of magnitude slower than off-chain, but it’s possible that off-chain micropayment channel networks could solve this with minimal or no trust.
Ethereum is a very interesting (and very young) project that takes Smart Contracts to the next level by providing a Turing complete scripting language. This enables a new class of “decentralized autonomous organizations”, which are inherently trustworthy because they’re defined in code on a blockchain, verified and executed by a decentralized network.
In theory an exchange could be implemented entirely in Ethereum Script. However, exchanging fiat currencies also requires the same counterparty risk as the cross-chain trading mentioned above.
Ripple attempts to decentralize exchanges by essentially allowing participants to issue lines of credit to each other denominated in any currency, then facilitating trades and settling debts through the network of these lines of credit. This shifts the trust required from a large centralized exchange to entities of your choice, like your bank or even a friend.
Open Transactions and Voting Pools
Open Transactions is a financial cryptography library that could be used to build semi-decentralized Bitcoin services using “voting pools”. Justus Ranvier described this better than I could in his article, Voting Pools: How to Stop the Plague of Bitcoin Heists, Thefts, Hacks, Scams, and Losses.
Bitcoin and related technologies provide an amazing foundation on which we can build robust systems that minimize the need for trust by providing transparency and aligning incentives. We’re still in the early days of building these types of systems, which is why I’m so optimistic and unfazed by setbacks like Mt. Gox’s failure.
Feedback is appreciated on Hacker News or on Twitter at @tlrobinson.