Pre-consensus implies consent without giving it.
This is a response to Deadal Nix’s recent article on markets and pre-consensus. It is a really good article and I recommend that you read it first: https://www.yours.org/content/on-markets-and-pre-consensus-4454add1bfbe
While it is a really great article, I disagree with his conclusion and wanted to articulate why a pre-consensus approach on the protocol level should be avoided. This article will be divided into a philosophical objection and then a practical objection.
What is Bitcoin and is it Bitcoin cash?
One of the major objection in the Bitcoin cash camp was that Segwit fundamentally changed the protocol as described in the white paper. BTC believers say that Bitcoin has to adapt and change over time, we have rejected this position and make an appeal to the original protocol as described in the whitepaper. We have said that we are the original protocol and they are the ones who left us, not the other way around.
This will change if we make a fundamental protocol change like a pre-consensus. We will be in the same position as Segwit, making the argument that Bitcoin needs to change and adapt over time. We will no longer be the protocol as described in the white paper.
If we condemn one protocol fork that changes how Bitcoin changes both economically and technically while allowing another fork to do the same then we are hypocritical and will delegitimize our claim as Bitcoin.
In my view, you either support Bitcoin as described in the original white paper or you do not.
What do miners do?
As for my practical objection, we need to consider the miners. People tend to confuse the wealth generated by mining with power and see Jihan having considerable revenue from building miners with him being able to control the network itself. This couldn’t be further from the truth.
Miners have two powers, they can order transactions and they can orphan other blocks. Orphaning blocks is what gives miners some control over the direction of the network as it allows them to reject a fellow miners block and only give the hash power to the chain that they believe is in their best interest. This is the foundation of the Nakamoto consensus. This is how a fork is created; different node implementations create different orphan blocks, which are then built on by different miners.
A pre-consensus implies consent on behalf of the miners while taking away their choice. These techniques determine what blocks will contain before they are found. An example of this will be BitcoinNG, which has been discussed since 2016.
This will reduce orphan blocks and propagation time but this will also take away a lot of the power of miners to choose which blocks to build on. This restriction of freedom is significant and we are reducing the ability for miners to choose. In order words, we are reducing competition by implying that all miners are equal and that every block generated is as value as any other. This is not true and inconsistent with the incentives built into the network.
Right now, miners have the incentive to “police” the network for rogue miners themselves and maintain it even if it means losing block themselves to build on blocks that protect the network long term. This means that “big” miners have more at stack than individual independent miners and if we neuter these miners for the sake of the small by removing their right to choose then we are introducing a disincentive to the network.
We need to consider the miners, their investment, and their role in the network and interfere with the protocol as little as possible when it will affect their incentives within the network.
Who wants 0-conf and why?
While we all agree that we want Bitcoin Cash to be digital cash for the world, we can disagree about the importance of 0-conf because we need to understand who wants it and why they want it.
If you are transferring funds from one of your accounts to another, you don’t need 0-conf because there is no risk of you double spending yourself.
If you are transferring funds to a friend or colleague, you don’t need 0-conf for the same reason.
If you are the purchaser, you don’t need 0-conf, you just need a confirmation that the merchant has your signed transaction and it is up to them to transmit it.
The only group that needs 0-conf is merchants as it is for their protection while providing a good user experience. Full stop.
But it is actually narrower than that as it is even a subset of merchants who are at risk of transferring digital goods prior to receiving a confirmation. This doesn’t affect physical goods shippers as they will receive confirmations before shipping.
Nor will this affect POS retail merchants because they will control when the transaction is submitted and we can verify within a second or two that a double spend didn’t occur (this verification can be improved by the payment processor). The process is slow enough to ensure verification and it is unlikely that someone will leave the store prior to the payment being completed verified properly.
How can digital goods merchants protect themselves from a double spend?
Instead of requiring the entire eco-system to redesign itself to accommodate a new protocol, we should do everything we can to improve this at the appropriate level. If these merchants want 0-conf protection, then they should pay for it, either by buying insurance, making arrangement with a miner, or by using a payment provider who provides 0-conf guarantees. This shouldn’t be achieved by socializing their cost to the entire ecosystem by spending valuable developer time at the protocol level, so let’s put the burden where it belongs.
Changes to the protocol should be considered with great care, stay true to the white paper, and be focused on achieving the dream of peer-to-peer digital cash for the whole world.
6 of 6 reviewers say it's worth paying for
0 of 6 reviewers say it's not worth paying for