Bitcoin Cash: Lessons from a block size canary

Early days

I first became interested in Bitcoin in early 2011. At first I only saw a chance for quick profit. I’d played with penny stocks previously with some success, and it smelled of hype and hollow promises. What got me to take it seriously, though, was the act of actually trying to buy it. Having my bank stop my transfer (MTGox was still using Jed McCaleb’s personal account at the time) was really eye opening. Essentially saying “this is not YOUR money but OUR money and we decide if you can use it this way or not.” After missing my chance to buy BTC for $2 I concluded that, for Bitcoin to work, it needed apps and services; actual things to do with this new form of money. I had a number of ideas and went as far as domain registration (gift cards, credit card gateway, etc) before putting it on the back burner, as I was still “working for the man” and had not yet been brave enough to go out on my own.

At the beginning of 2013 the space started heating up a lot and circumstances had changed, and I decided to get involved in a more active way. After learning of SatoshiDice, I became intrigued by the concept of using the blockchain for purposes beyond just sending money. Being able to establish trust and proof opened my eyes to even more possibilities. On a lark, SatoshiBones was created, shamelessly cloning SatoshiDice’s clever concept. I wasn’t sure where it would lead, but I was very curious, and as they say “imitation is the highest form of flattery.” I was admittedly very naive about the deeper technical concepts, but have learned so much from the endeavor.

Nutty developers

I learned about the block size limit. This was the first crack in my previously unbridled optimism. It seemed we had plenty of time before it would become a problem, and I hoped as many did that it would get sorted out sooner than later. My technical background is primarily as a systems engineer, and I tend to look at technical limitations as a challenge rather than an obstacle. I was told by a de-facto leader in the “core” dev community that raising the limit was a problem because, in essence, the blockchain would not scale infinitely. I was told that they did not want to simply raise the limit a little bit, because it would “set expectations” that raising the block limit was how we could keep scaling into the future. This seemed very presumptuous, and I began to worry more about the attitude of these devs than the technical issue itself.

Then another “core” dev decided to add the prefix used by my site’s vanity addresses (1bones) to a blacklist which he included in the binary release of Gentoo Linux. Security and privacy issues notwithstanding, this was quite an insult. Stop and think about this for a minute. Imagine if someone found a way to block people from sending you bitcoin. Imagine if this was someone who was an insider of the group of people who develop the bitcoin reference software. This project that you love and have invested your money and time in, and have dedicated yourself to building a business on, and one of its notable members is willing to do such a thing. Fortunately most people felt his action was at least a step “too far”, and a pervasive blacklist never materialized as a real threat. However, such is the prevailing attitude of his peers that this behavior got little more than finger wags.

Game theoretical masturbation

In this space we hear a lot of debate about theoretical incentives. Layer after layer of theory-as-fact build up arguments which do not necessarily follow reality. Will a miner really risk their block reward to attack bitcoin? Yes a miner can theoretically doublespend a transaction. But will they? There’s a game theoretical answer that would suggest they will if the potential profit from double spending is higher than the reward. But are most miners totally amoral? And what about reputation? Most hashing power is tied to pools. If a pool starts abusing their hashing power to doublespend transactions, people are going to find out and I don’t think it will go well for them. This is not what happens in real life.

But we’re told otherwise. We’re told “zero confirmation is dead”, and we should be doublespending our own transactions (RBF) to enable a “fee market.” The unfounded economic assumptions of the fee market motivation aside, we watched in disbelief as this meme propagated. We were doing just fine with zero conf. The food and drinks I buy at the pub were doing just fine. Doublespending was not impossible, but neither is shop lifting, and certainly not credit card fraud. A case for a managed risk was not theoretical; it was being made successfully every day.

The real world is messy

As with the original SatoshiDice, we were not requiring confirmations. We include the player’s UTXO in their payout to prevent double spending of wins, and went a surprisingly long time (about a year) before double spending of losses burned us. Out of a desire to lower costs for players, I’d employed the change of minimum fee added with Bitcoin 0.9.0 in 2013, and reduced fees to 0.00001 per kbyte. About half of the hashing power had switched, but not enough to prevent it being trivial to double spend using the fee differential, creating a trivial vector to exploit us with.

The honeymoon was over, and lots of work went in to doublespend prevention. Each time someone would find a new method, our logic to prevent it would get stronger. Over time, it became expensive enough to try to attack us that we very rarely saw attempts, let alone successful attempts. The losses from doublespending were well within our profit margin. This is an imperfect balancing act. But it worked for a very long time. Long past when we were told it was not working.

The final straw

Ultimately the block size limit was reached. Fees rose exponentially, and no one could have any assurance at all that their transaction would get into a block. The cost of playing our on-chain game was pushed to absurd levels, and zero confirmation was, as had previously been claimed, finally dead. Even the pub’s payment processor was now getting doublespent.

Those who side with the “nutty developers” are probably saying “good riddance!” They argue that our transactions are spam, despite our transactions to date paying over 230 BTC in fees. Some others may argue that gambling is a waste of resources. I agree there is a moral argument to be made against gambling. But the economic activity is undeniable. How many people on cell phones in Vietnam are buying small amounts of bitcoin to send as on-chain bets? More than you may think. Will they continue to do this if their small Bitcoin purchase is eaten away with fees and delays? Just as new services are picking up Bitcoin as a payment option, why are we trying to saddle those services and their users with these costs?

Going forward

For all the efforts of so many big block advocates, the best deal that could be struck was Segwit2x. The biggest opponents of large blocks, the core devs, are not even backing this deal. They’re already positioning themselves to fight against the pathetic 2x increase. And even if 2x happens, then what? If Segwit was the only carrot that could get them to increase block size, what hope is there of any future increase?

My long-time sentiment has been that a fork of Bitcoin which does not have a majority of hashing power would be dead on arrival. But very recently I began to see Bitcoin Cash, a fork of Bitcoin with larger blocks, removal of RBF, and a back to basics vision of scale-ability with new eyes. While it is likely to garner only a fraction of the hashing power, the contributing miners represent a large portion of the 1mb Bitcoin mining. These miners are not going to subvert themselves by attacking the minority chain. Because there is replay protection built in, there is no real risk to the 1mb network, so only hard line activist miners are likely to pose any threat. And to what end? Throwing away money to attack something they claim to have no merit seems ridiculous. Doing so will most likely be ineffective and serve merely to gain more support for Bitcoin cash.

For these reasons we are very optimistic for and plan to lend our support to Bitcoin Cash. A minority fork is far from risk free, but I’ll gladly take on the messy technical challenges and uncertainty than to rest my hopes and risk my financial future on control freaks and theorists. We’re very close to releasing an off-chain version of our game, previously the only possible solution to a full blockchain. We’ll be fine either way. But, I still believe in the promise of on-chain services for BITCOIN. I have nothing but good will for our Ethereum friends, but we should not have to leave Bitcoin to provide on-chain services.

Following the successful fork, we have released our on-chain game, playable with Bitcoin Cash. Pending block adjustments and normalization of fees, we will reenable zero confirmation. Let’s make on-chain great again =)