The Bitcoin block size wars are raging at full force. The latest development was that Coinbase, one of the reputable Bitcoin exchange and wallet services, was censored on the discussion boards and delisted from bitcoin.org solely for showing support for a larger maximum block size. The insanity, in short, has reached a fever pitch.
Yet there is a simple, technical way to resolve the Bitcoin maximum block size battle once and for all.
The best way to move forward would be to agree on a schedule of increase for the maximum block size. This is not going to happen. It's time to go through denial, anger, bargaining and depression and cut right through to acceptance that no progress can be made right now.
One might ask why.
First, there are as many schedules as there are functions that go through a handful of desired points. Recall how many that is: infinite. Oddly, there are people suggesting even more increase schedules this late in the game. Stop the madness. Any finite decision power spread over infinitely many options will yield a flat 0 weight for all options.
Further, the debate is being waged with the nuance, tact, and orderliness we would see in a third-grade classroom. We will not catalog the tactics being employed in order not to depress people about the state of the Bitcoin developer community. Attempts to move the discussion to a more scientific basis sadly but predictably found little traction. The discussants seem uninterested in identifying goals, quantifying their arguments, or generally developing a process of scientific inquiry and development.
Compounding the lack of a consensus process is the fact that most of the actual stake holders don't have a voice in the discussion. The Bitcoin community is culturally fixated on hashpower, to the point of thinking that miners determine, at their sole discretion, the shape of the blockchain. We've worked to dispel this common misconception, and most people seem to now agree, yet stakeholders such as exchanges and wallets are still underrepresented in maximum block size discussions. It doesn't bode well that the first and biggest exchange that spoke up about their preference immediately faced an appalling display of censorship.
There's much to be said about VC errors, in particular A16Z's missteps, in not fostering a healthy ecosystem, or the community's sins in idolizing the wrong people, but let's leave that for another time. The game being played now is so dirty that a developer consensus doesn't look likely any time soon.
Yet there's a technical solution to unifying the maximum block size debate. It's dirt simple, and I'm amazed that it has not come up so far, so let me be the first to outline a technical proposal that extracts unity out of the current cacaphony. It's called Bitcoin-Unified (UBTC).
The wrong assumption at the heart of the debate is that there can only be one maximum block size, and only one blockchain, in the network.
The key insight behind Bitcoin-Unified is to build a new versatile-client that can parse multiple blockchains, and some incentives for splitting miner's across multiple chains.
Suppose that we move to a world with two protocols, called Dee and Dum for short, which share a prefix of their blockchains, having forked at a particular moment in time, called the Rapture. Let's oversimplify and assume that Dum is hostile to any and all modifications, so we cannot expect Dum to do anything to facilitate Unified. In contrast, we will assume that Dee wants to facilitate a fork and to operate with a new set of parameters that it wants to demonstrate to be safe for the network. Consequently, Dee is willing to forego some of its autonomy; specifically, we will assume that Dee is willing to refrain from changing its consensus rules arbitrarily.
At a first naive glance, it might seem like unifying Dee and Dum is impossible, because there will be two different versions of the financial history of the world post-Rapture. An evil attacker can pay someone using Dee-coins, and turn around and use Dum-coins to pay someone else, doubling her wealth, and also halving the value of coins. In reality, a tiny bit of programming can easily unify the two chains by identifying and tracking equivalent behaviors in both chains. Let's see how.
There are only three cases of interest: (versa-)clients, (siamese-)miners, and (joint-)fees. Let's start simple and build up.
Bitcoin-Unified clients monitor both chains and take the intersection of the spendable outputs on both chains. A transaction takes place from the point of view of a unified client if and only if it appears on both chains, and has the same effect on both chains. By the assumptions we have made, we can expect that Dee will maintain its protocol in a manner where every valid Dum transaction is also a valid Dee transaction, as long as it spends coins that are already valid in Dee. No force on earth can stop Dee from taking Dum transactions and sticking them in their blockchain. This is precisely what Dee miners do. The transactions need not appear at equivalent block height, nor do they have to be the exact same transaction with the same hash on both chains -- they just need to consume the same inputs and result in the same outputs, not counting the miner fee. Simple pay-to-pubkey-hash and pay-to-script-hash transactions are straightforward. Multikey transactions are evaluated for equivalency by their inputs and outputs, so it is allowable for a 2-out-of-3 payment to be signed by one set of two keys on Dum and another set of two keys on Dee, as long as the transaction consumes the same coins and produces the same outputs. Not that we'll ever encounter such a case, but making this point helps pedagogically with getting across the notion of transaction equivalence. What counts are the consumed inputs and the destination and amounts of the outputs.
So, Bitcoin-Unified considers a coin spent if both Dum and Dee agree on the new recipients. When a client requires that a transaction be buried 6 blocks deep, Unified checks to make sure that both transactions are buried 6 blocks deep. This ensures that Unified clients recognize only a conservative subset of the transactions seen by the others in the ecosystem. Which in turn ensures that no money can be lost by the merchants in cross-chain double-spend attacks, where someone gives the same pre-rapture coins to person A on Dee and person B on Dum.
Unified Miners need not do anything special. They can divide their hash power between Dum and Dee in whichever way they like, or more likely, they time-multiplex between the two, alternatively switching between the two chains.
As we will discuss later, Unified miners should preferentially place transactions on the Dum blockchain first, then the Dee blockchain. Unified transactions will thus take a slight latency hit, typically, of an additional Dee block interval.
The only complicated issue related to mining involves block rewards. We need to ensure that we don't render all block rewards ineffective (as the naive intersection operation described above would for post-Rapture coins), or accidentally double the supply of coins and thus blow the 21M limit and halve the current value of coins by creating a history-sharing altcoin (the 21M limit is so sacredly ingrained into the Bitcoin mentality that any solution that relaxes it would be considered a laughable non-starter).
Take the case of a miner who solves for a block on Dum and earns a block reward. He can spend these coins on the Dum chain as he likes. These coins, however, do not exist on the Dee chain. To make them appear, we amend the coinbase transaction on Dee to contain the name of a unique Dum coinbase transaction, signed with Dum's coinbase key. Such a coinbase in Dee does three things: (a) it creates new coins, specifically, as much as the block reward, recognized solely by Dee clients, (b) it links this block reward to a corresponding block reward on Dum, and (c) it enables regular unification rules to apply, therefore creating Unified coins, and provides an incentive for Unified miners to split their efforts 50/50 across the two chains.
If a miner prefers Dee (or Dum), they can unilaterally stick to their preferred side. Their coins will only be good at Dee (or Dum) merchants. But a unified miner will mine on both chains, helping both, linking the two chains, and spending their block rewards at Dee, Dum, and most importantly, Unified clients.
Recall that Bitcoin transactions not only send their inputs to their named outputs, but also implicitly send a small sliver to the miner who placed the transaction in a block. Because a given transaction might be mined by different miners on Dee and Dum, the financial history of the two worlds might diverge.
That brings up the question of what the Unified clients should do for this divergence. One tempting option is to do absolutely nothing. Let the miners diverge, and spend the money they made from Dee fees with Dee merchants, and Dum fees with Dum merchants. The divergence would happen very slowly. This would create some gentle pressure to explicitly unify the two chains (by merging Dee and Dum at some compromise and doing away with Unified) as people want to cross from one chain to the other.
But there's a better option. Note that the fees that miners earn on Dee and Dum will tend to be in proportion to their hash power, and will be equivalent because there are strong incentives for Dee and Dum to contain the same transactions, and therefore, the same sum total amounts in fees.
We introduce a "link" transaction on Dee that enables the Dee chain to connect mining fees in Dum to equivalent mining fees in Dee. A link transaction collects its inputs from the excess on top of the block reward in a Dee coinbase transaction, names an equivalent amount in fees in a unique Dum coinbase transaction, and provides a signature with the Dum coinbase key. Such post-rapture fees are equivalent as far as Unified is concerned, and are subject to the recursive equivalence treatment by the versa-clients.
What happens when a transaction appears on Dum but not on Dee, or vice versa?
Those coins are unspendable in Unified until the same or equivalent transaction appears on Dee, and vice versa.
What if that never happens?
Unified miners would make sure that they mine transactions on Dum first, then on Dee. Recall that Dee miners can always just take Dum transactions and stick them in their blocks.
A transaction will not be confirmed on Unified until it makes it to both chains. That might never happen if Dum has no room to place a transaction given the fee, and there is no respite in the incoming transaction stream where this transaction can be accommodated (i.e. if the Dum mempool is growing without bound). In that case, the transaction will sit in the mempool until it accumulates sufficient priority to go into a Dum block. In effect, the users who don't like Dum's high fees would either restrict themselves solely to the Dee chain, or end up experiencing longer confirmation latencies.
Luckily, we are still a long way away from this point. The transaction stream routinely slows down as it follows a diurnal pattern where we can clear the backlog. Unified will buy us some time and can help demonstrate that the Dee operational point is safe to deploy.
What about someone who sends coins to one destination on Dee and another on Dum?
Coins involved in a successful double-spend are lost from the Unified world. Note that merchants running Unified would not be affected by a double-spend. This provides an incentive to switch to Unified.
Does splitting the mining power mean that both systems run at half speed?
No, the difficulty adjustment will ensure that both chains chug along at one block per 10 minutes.
Does Unified mean that miners need double the bandwidth?
No, Unified's bandwidth overhead is essentially equal to Bitcoin pre-Rapture.
What would miners do?
Most miners are actively working to maximize the value of their coins, and very strongly prefer a consensus to emerge than to have to choose between Dee and Dum. Unified gives them the option to force that consensus on the two chains by extracting a cohesive whole out of two independent blockchains.
Can someone coerce the miners to mine exclusively on Dee or Dum?
Not easily. It is not easy to determine where a miner's hash power is directed, and it is easy to hide a miner's identity. So, coercing miners is not trivial. Juvenile behavior, such as the DDoS attacks that were directed against certain full nodes, are difficult to lodge against miners.
What happens if the hash power is unevenly split?
While Unified is as strong as the weaker of the two blockchains post-Rapture, it provides a strong incentive to split the hash power down the middle at 50/50.
Of course, we need to consider the worst case scenario. While it's unrealistic that more than 30% of the miners have a strong preference for Dee or Dum, let's suppose they do. If 34% or more of the hash power wants Dum and does not mind sabotaging Dee, they can do so by launching a 51% attack on Dee after the split. In this scenario, Unified will divide hash power into two halves of 33% to Dee and Dum, while the hardcore Dum supporters would have to coordinate a switch to mining on Dee, en masse, to abandon Dum and mine on Dee to launch the attack. Such an attack would be quite visible, and it would leave Dum vulnerable. Unified clients could counter this launching a 51% counterattack on Dum.
The hash rate the attacker would have to command in order to both defend its own chain and 51%-attack the other chan is 67%. So Dee should not initiate Rapture until it is sure that there is more than 67% hash power behind Unified and Dee, combined. Note that a miner coalition of that size can launch 51% attacks on any blockchain, Dee or Dum. We do not see such coalitions today.
Is there a separate market for unified coins? How would they be valued?
Yes. We would expect Unified coins to hold their value, as they are slightly more rare than regular bitcoins are now. We would expect Dee-BTC and Dum-BTC to both lose their value at the time of the split. Overall, the market price for UBTC will reflect the community's confidence that the assumptions behind the Unified system will be upheld.
Are you requiring that Dee be merge-mined with Dum? Or vice versa?
No. They can be separately mined.
Does all this mean that Dee cannot change anything besides the blocksize?
Not at all. Dee can make any changes as long as these changes do not render Dum transactions invalid.
What if one chain wants to change its PoW?
They can go right ahead. Unified just needs to be able to parse both chains.
What about extremely small miners who get lucky and find a block on one chain but lack the hash power to repeat the feat on the other chain?
Any miner in a pool of 0.1% (this is not Verizon math, that's really a tiny pool) or larger should be able to mine easily on both chains in a given month.
Can Dum take explicit actions to thwart Unified?
First, that would be obnoxious. The narrative we have been hearing about "developing the fee market" would go right out the window, to be replaced with "sabotaging the community to wrestle control in a stunningly regrettable display," and people who engage in this would be derided by the community.
Having said that, any good protocol should fully expect this worst case scenario and plan for it. Dum can refuse to place onto its blockchain any transaction that appears on Dee -- this is easily fixed by Unified miners waiting until a transaction appears on Dum. Dum can try to keep out miners who have linked their coinbases (block rewards and fees) to the Dee blockchain -- this is easily avoided by Unified miners using different keys for each block. Dum can try to institute IP-level bans on people known to use Unified -- miners and merchants can rent servers, use VPNs or go through Tor. Dum miners can switch over to the Dee chain and misbehave (e.g. by selfish mining) so as to skew the proportion of blocks won by Unified miners who straddle both chains -- we know how to prohibit selfish mining for attackers smaller than 25%, and there are no huge pools that would actually pose such a risk at the moment. Some forum moderator can censor your company if you run Dee or Unified code -- well, that is already happening, and, frankly, these tactics are not accomplishing much.
What happens if there are more than two possible forks to choose between?
As long as the forks are interoperable and are contained within each other in some kind of nested structure (for some definition of "contains" that we don't have the space to provide here), then we can derive an equivalence relationship and apply the same trick of cross-chain equivalence and coin linkage. Things get complicated when the currencies are not neatly contained within each other.
Is Bitcoin-Unified a scalability solution?
No. Unified is mainly a solution targeting the lack of developer consensus and a safe way to handle a possible protocol schism. It can be used to allow Dee to demonstrate that the Dee protocol is safe to operate at a new parameter point (e.g. with a larger maximum block size), without risk.
Will there be sufficient transactions to exercise interesting behavior of the Dee blockchain?
We would expect the Dee chain to have native Dee users, who make use of the larger blocks offered by Dee. In particular, an organic demand for low-fee services would lead to native Dee users as well as native Dee merchants, followed by an organic transition to Dee as coins are taken off of Unified. If, on the other hand, larger blocks are not called for, we'd expect the coin center of gravity to remain on Unified. Unified provides a safe transition process between the two protocols.
Is there a better way to get Bitcoin to scale?
Yes, there is. Bitcoin-NG is a proposal to achieve much higher throughput and scale with Bitcoin. It also improves the security of 0-conf transactions. It works on current mining hardware, and shares the exact same security model as the current system.
NG does require changes to clients (as does Bitcoin-XT, albeit a smaller one, as do segwit and LN) and a single new opcode in Bitcoin (while Bitcoin-XT requires a single parameter change, and segwit and LN require substantial changes).
Is Bitcoin-Unified an alt-coin?
No, Unified is, by definition, a strict subset of all of its components. Everything legal in Unified is also legal in Core. It respects all of the blockchains on which it builds.
What's the game theory behind the resulting system dynamics?
This is an active area of research and we are currently looking into making the arguments in this post more formally.
So, Bitcoin-Unified is a fairly straightforward technique to make sure that, even in a world with two blockchains, there is one globally agreed set of outcomes.
The real question now is, what do we, reasonable people who want to see cryptocurrencies succeed, want to have happen?
First of all, Bitcoin-Unified would not have been the ideal outcome a year ago -- the ideal outcome is to agree on some schedule and preserve the community. But the community has been irreparably split. And while Bitcoin-Unified is a bit more convoluted than a clean slate design, it is actually fairly clean as far as financial software goes. So it's a reasonable solution.
Second, the sensible thing to do is not to push Bitcoin-Unified as a new system, but for Dee to evolve into Bitcoin-Unified. That way, it can subsume all of Dum, at the cost of not being able to make backwards-incompatible changes, and at the cost of running two chains at half the hash-power. This is a small price to pay. Contrary to what some might say, there is no government out there jumping at the bit to kill bitcoin with a 51% attack, but unable to do so because the hash power is beyond the reach of the state. Dividing the effective hash power between Dee and Dum will have essentially no effect on security. Incidentally, almost everyone says that they support switching to large blocks at some point in time, with exchanges and merchants (who provide the true value proposition for actual bitcoin by connecting them to value in the real world) leading the push, with miners saying that they support maximum sizes. Unified is a way to safely explore the parameter space.
Finally, there exists a far better technique to scale Bitcoin. The current debate is misplaced and misframed because this technique did not exist when the debate started. If we were able to step back and think about the big picture, and follow not our wallets or egos but the science of cryptocurrencies, we would all be looking to adopt Bitcoin-NG, which increases the throughput and improves the security of 0-conf transactions without having to increase the maximum block size.
While science will eventually prevail, as it always does, the debate in the meantime has been too acrimonious and frustrating to watch, even for bystanders like us. So that's why we offer the Bitcoin-Unified proposal, to cut through the insanity by accommodating both factions so the cause of cryptocurrencies can advance. We can use technical measures to force Dee and Dum to work together. We do not need cooperation to create a cohesive result.
Many thanks to Andrew Miller for his insightful feedback on an earlier draft of this post.
Hacker and professor at Cornell, with interests that span distributed systems, OSes and networking. Current projects include HyperDex, OpenReplica and the Nexus OS. more...
A post-doc in the Systems and Networking Group in the Department of Computer Science in Cornell. My Research Interests are distributed systems and algorithms, specifically distributed storage algorithms, the distributed aspects of Bitcoin, and reliable aggregation in distributed sensor networks. more...
bitcoin / security / ethereum / hyperdex / release / nosql / selfish-mining / blocksize / dao / surveillance / privacy / mongo / broken / weaver / nsa / meta / leveldb / blockchain / 51% / voting / smart contracts / graph stores / decentralization / bitcoin-ng / vaults / snowden / satoshi / philosophy / mt. gox / mining pools