Bitcoin Unlimited and the chain split risk

Aaron van Wirdum recently published his article How Bitcoin Unlimited Users May End Up on Different Blockchains.

The article brings up some possibly legitimate criticism of Bitcoin Unlimited - though I'd like to comment some points.

Chain split because not everyone switches to BU

It currently seems very unlikely that different Bitcoin implementations — like Bitcoin Core, Libbitcoin, BTCD or Bcoin — will adopt BUIP001, or something compatible. This is especially true because the Bitcoin Unlimited team has not submitted BUIP001 to the cross-implementation Bitcoin Improvement Proposal (BIP) process; most implementations therefore don’t even have the proposal under consideration.

It's a common theme - "submit a BIP first, then we can discuss it". The right place to submit BIPs is on the bitcoin development mailinglist, Peter Rizun claims he has been censored there and has hence decided to boycott the mailing list - that's the background for the BUIPs.

I think it's reasonable to assume that most implementations would adopt support for higher block size limits if BU would gain more traction among the miners. It's no big thing - it's just one simple constant in the code, and most wallet software (SPV-wallets) already don't care about the block sizes. Unfortunately the Bitcoin environment has become very much split in the block size debate, and a small minority is probably so stubbornly stuck with their points of view now that they probably will insist on sticking to the 1 MB block size limit even though the big majority adopts higher limits.

This is very unfortunate. With the ETC vs ETH split there was some fundamental principles at stake - for most people, the bitcoin block size is not so much about principles; most of the actors wants the same; a strong and successful bitcoin, and a split will be counter-productive. The biggest problem now is all the FUD, many "small-blockers" are honestly concerned that bitcoin will be destroyed if miners adopts BU, and many "big-blockers" are honestly concerned that if segwit will pass, all future capacity growth will come through solutions controlled by the Blockstream company. I'm also concerned; my biggest concern is that Bitcoin will never have practical uses outside the criminal niche unless we can grow transaction capacity, it will become as irrelevant as IRC or PGP is today.

Anyway, if the vast majority of miners will adopt BU, then bitcoin with the 1MB-limit will ultimately become very broken, so useless that even the diehard smallblockers most likely will abandon ship. Bitcoin and Ethereum is different beasts entirely. Remember that unless some explicit changes are rolled out to either BU or Bitcoin Core and adopted by the user base, or the end-users make conscious efforts to "split" their coins, all transactions ends up in the same mempool; there will be a "smallblocker" chain with overfilled 1MB blocks with many hours interval versus the BU chain working smoothly with 1MB+ blocks every tenth minute (perhaps every 15th minute for a couple of weeks). The 1MB-limited block chain will be both useless and worthless.

Bitcoin Unlimited users would be unsure as to whether “their” chain would continue to exist at all. If the one megabyte chain should ever overtake the “Bitcoin Unlimited chain” in length (really: total proof of work), Bitcoin Unlimited nodes would automatically switch back to the one megabyte chain. Accordingly, they would dispose of (“orphan”) the entire “Bitcoin Unlimited chain” since the split, even if that chain is thousands of blocks deep. All “their” transactions would be forgotten, perhaps costing lots of people lots of money.

I don't see that happening. I've seen people arguing that from a game-theory point of view, miners would have incentives to switch from the BU-chain to the 1MB-chain as soon as the difficulty drops there. Perhaps it's correct when counting the bitcoins earned, but in the end of the day what matters for the miners are how much they have left after paying the electricity bill; it's needed with a valuable bitcoin to pay for electricity.

Bitcoins success was always pinned on all the actors having economical incentives for it to succeed. Already today the argument above is valid; if any entity can control more than 51% of the mining power, they could unplug from the network, mine an alternative chain for 1000 blocks, and then release the new chain all at once, efficiently redoing the history. In bitcoin terms it's more profitable than being a part of the network, however the value of the bitcoin would plummet (and we'd probably see an ETH/ETC-style split over the discussion on weather "code is law" or if the reference implementation should be changed to invalidate the secret chain). Similarly, the miners that have switched to BU will have all incentives for the bigblock-chain to become the de-facto bitcoin. The "tragedy of the commons" does not apply as the miners are organized in pools.

Chain split due to EB1AD99999

The author goes on arguing that some people running BU still would be running it in "core-compatible mode", never accepting more than 1MB blocks. I think the number of people sticking to those settings should BU be adopted by miners to be truly marginal.

And it would include the same risks as previously described as well. If the one-megabyte chain ever overtakes the two-megabyte chain in length, the two-megabyte chain is completely discarded. Even after thousands of blocks.

I believe this isn't really a different scenario than the first scenario; it is perfectly the same scenario. Some people (and miners) will probably insist on sticking to the 1MB limit even after a majority of miners have adopted BU and are getting ready to increase the block size, it's irrelevant what software they use for it.

3 confirmations becoming less reliable

The author argues that in the best case, with everyone setting AD to 4, we will get a significant number of 3-block-reorgs. He also argues in the next section that under conditions where approx half of the network is flagging for a bigger EB, a malicious minority miner can deliberately generate a block designed to split the network.

I believe this concern cannot be dismissed right out. Today companies that cannot afford any fraud will usually consider bitcoin transactions with 3 confirmations (in rare circumstances, 6) as 100% secure. Now, with miners being out of sync with each other on the EB-settings, one would risk to get stuck on the wrong chain.

The biggest risk that one transaction will be rolled back (double spent) due to a chain reorg. For a three-block split to occur it's not sufficient that a node is out of sync with the miners; the miners has to be out of sync with each other as well. And the double spend requires malice - it requires quite a bit of planning and luck to be able to toss in such a transaction that gets a three-confirmation on a chain honored by a merchant, but still double-spent on the alternative chain that eventually will become the longest chain. Hence it's a quite so unlikely scenario.

In the short run - should BU become dominant - I believe miners will be very cautious with the EB and MG settings. I believe we'll get a de-facto block size limit at 2 MB for quite a while.

We could potentially come into a situation where half of the miners decides to opt for a 3 MB limit, while the other half sticks to the 2 MB limit. This may be a concern. Then again, I believe it's easy to mitigate the risk, and I believe the risk can be mitigated without doing further changes at the protocol level; based on the EB-announcements in the last 1000 blocks it should be pretty easy to predict that a the chain will be split and which chain eventually will be orphaned, and nobody wants to mine on a chain that is doomed. As far as I know, Zanders is working on some better algorithms in the Classic package.

Placebo control

The author argues that even a simple majority of miners can force through any block size increases, nodes will eventually have to jump and follow suite. This concern cannot be dismissed, though one should never forget that the bitcoin ecosystem is symbiotic, miners want the highest value of the bitcoin and they want to be able to sell the bitcoins they mine. A majority of economically significant nodes will always be able to put down a veto, both towards excessively big blocks and against increasing the mining subsidy - regardless of weather it's a configurable option or not.

Sticky gate

The author describes a potential attack vector when some malicious minority miner first manages to split the network by mining a block that is just a bit too big for just a bit less than half of the network. After a while the AD is reached and the nodes and miners with low EB-setting will accept the big block. Due to the "sticky gate"-feature the nodes and miners with the lowest EB-settings would then allow any block for 24 hours, so the malicious miner could then create a huge block which ironically would be accepted by the nodes and miners with the low EB-setting. This is a moot point, because the BU team already recognized this as a potential problem and has fixed the algorithm.

Nodes being out of sync

One risk not touched in the article, but I believe it's also a potential issue: people set up their BU-nodes once (i.e. in 2017) with EB2 AD4, some years later the blocks are 3MB big, but the node owners still haven't touched the configuration. Now, those nodes will constantly be three blocks behind the rest of the network.

I believe it's a real risk, but I believe those "careless node owners" aren't much active parts of the network anyway. Businesses depending on their nodes to be well-connected and up-to-date will most likely actively be maintaining their nodes.

I also believe this is an issue that can be fixed by having the software warn if the configuration is out of sync, or decide on sensible defaults based on what it sees on the network.

The counter-risk

I believe the biggest risks at all is if we do nothing with the block size. Currently bitcoin is like a big ship heading directly towards rocks; we need action, we need to turn the rudder hard. Instead of doing that we're discussing what's best of starboard and port, and weather the rocks are dangerous or not.

There are also people arguing that we should enable the segwit soft-fork, it will allow some more on-chain capacity, and it will allow for better off-chain solutions, like lightning and side chains. Personally I believe the segwit route is better than the "status quo, head for the rocks"-route, but lightning is no silver bullet and the segwit softfork is riddled with technical debt (as compared with Zanders flextrans counter-proposal).

Bitcoin Unlimited may indeed have some risks; but I believe the risks are insignificant, and I believe the risks of sticking to the 1MB limit - or committing to the segwit softfork - is much bigger.