Moving Forward: or how I learned to stop worrying and love the BIP 148 bomb. (Part 2)
In part 1, I explained what I see as huge flaws in the incentive shift that is BIP-148. Here I will talk about next steps, or what should be done to maximize value of bitcoin.
To understand why all this is happening, one first must consider the blocksize issues that are taking place now. To make a long story short, bitcoin can handle approximately 3.5 transactions per second, which fill up a 1MB block every 10 minutes. This MAX_BLOCK_SIZE=1000000 was added as a temporary spam measure, but now has become a lightning rod in the bitcoin community. Until recently, this transaction limit was never approached with regularity, but these days it is constantly full. As the blockspace becomes congested, the fees required to send a transaction rise.
There are many use cases for bitcoin. These range from the bad (Silk Road and ransomware), the good (encoding immutable data to the blockchain), to the world changing (Allowing people to exchange value without central banks).
As fees rise, each single satoshi erases a use case for bitcoin. Changetip bots that allowed forum users to tip posts they like can no longer operate on chain, for example. Another powerful use of bitcoin is remittance. Until recently, Filipino workers living abroad could use bitcoin to avoid bank fees when they sent money home. But now, doing this on the bitcoin blockchain is quickly becoming cost prohibitive: it's cheaper just to use the banks.
People on both sides of the BIP 148 could probably agree with much of what I wrote above. Use cases are getting strangled, and something needs to be done. Many of us have been warning about this for a long time, and suggesting a simple solution: raise the blocksize from 1 million bytes (1MB).
Instead the core developers have chosen a different path, with Segregated Witness, the merits of which I will not argue here. Miners and many others have been so skeptical of this, that only a minority of bitcoin nodes support it.
BIP 148 is basically a game of chicken a group of developers are playing with the miners. “Do what we want, or else” From the developer's perspective, bitcoin is all they do. They have just as much skin in the game as anyone else, right? No.
A conservative, back of the envelope calculation tells us that at least $640,000,000 has been spent on mining hardware alone.
$2000 / Antminer S9 @ 13.5 TH/s = $148.15 // cost per 1 TH/s4,325,000 TH/s * 148.15 = $640,740,740.74 // total
So however much skin the core developers have in the game, it is clear they haven’t invested nearly this much themselves into the bitcoin network (that’s not counting real estate, electricity, maintenance, and R&D costs developers face). No one with this much skin in the game is going to go down without a struggle.
As miners look to move forward from this “blocksize war”, there are 2 broad areas of consideration, tactics and long-term strategy. Tactics refer to the things miners will need to do, short term, to make sure the BIP 148 chain dies a quick and painless death. Strategy refers to maintaining and updating the consensus code after the spit.
The remainder of this article will deal with strategy, tactics are beyond the scope of what I’m doing here, and will be the subject of another article.
A development team is like any other team. Much like a human being, it can be healthy or sick, depending on it’s members. Teams can bring out the best, or the worst in people. To many outside observers, the core bitcoin team is broken, and a change is needed. This is clear to the majority of miners who refuse to signal for segwit.
To protect their investments, miners will need to coalesce around a new team of developers. What I propose is a new development model. Miners should create a market of ideas. Any idea for a change to the consensus code should be voted on. Proposals that are supported by a majority would then reach a 2nd vote: how much of a “bounty” should the network pay for the change. Miners would vote for a percentage from 0 to 1, that should be paid to the dev that writes the change. Then developers or groups of developers could bid for the bounty, and a third vote would take place, to select the developer to author the change. Once the change activates, the author of the change would receive a percentage of the block reward for the following 100 blocks, inclusive of fees.
This would help the (currently broken) supply of wanted code meet the demand. I consider it to be imperfect solution, until a system of voting for bitcoin holders is developed. This could easily be developed by allowing UTXO holders to sign messages following a predetermined set of rules. Future protocol improvements could even allow UTXO holders to sign transactions that would be valid if and only if an improvement they support activates before a particular block.
Whatever the miners do (and they will do something to stop BIP 148, to be sure), let’s hope that it enables the creation of an open, transparent, and above all healthy development team. Not because of altruism, but greed. The value of bitcoin can only rise as people become more confident in it, and I want my bitcoin to be worth more tomorrow than it was yesterday.
