Tl;Dr A well written proposal from Bitcoin Unlimited's chief scientist turns out to have various errors and mistaken assumptions, in this post I will try to open the dialogue with Peter in order to create deeper understanding of the issues and where I explain how I see problems in his proposal.

The chief scientist of Bitcoin Unlimited made a proposal to change the Bitcoin Cash consensus rules yesterday. In very short it would use an existing idea of UTXO commitments but change it slightly to force miners to finish validating a previous block before they could start mining one on top. The intention is two fold: to remove header-first mining, something Peter states is a problem. Second, it would make the validation performance directly impact the miners profitability. He deduced that this would lead more funds to flow towards validation infrastructure work, such as Bitcoin Unlimited does.

Personal disclaimer: I am the founder of Flowee which is a series of applications to build infrastructure for Bitcoin Cash. One of those projects is The Hub, a validating node. The Hub is known for its fast validation infrastructure and capability to process huge blocks.

There are various topics I'd like to address where the proposal makes an error in judgement. Lets start with the economic one:

Peter observed in his article that with proof of work (PoW) as a concept to earn money through mining, the hardware to do this work has improved dramatically in efficiency over the last 10 years. He cites a million times improvement. I don't doubt these numbers.

The improvement of PoW is reason to lament the lack of the same kind of improvements on validation speed. There is an assumption that the main missing point was the positive feedback loop which is what Peter wants to introduce.

This logic assumes that the PoW loop is essentially powered by the same drive as the validation speed, but this is not the case. The PoW improvements come from miners having to replace their mining equipment regularly. The reason they have to do so is directly linked to the total money flow of mining. And this is based on two ingredients: the mining reward and the price of the coin.

For most of the lifetime of Bitcoin the price of the coin has been entirely speculative. The price does not reflect the value delivered to the network, it reflects the value people expect it to have in some time in the future when more people use it. Specifically: the market value of all Sha256-coins is quite a lot higher than the utility-value. The market is always trying to be ahead of the actual generated value. This market-value, however, is immediately translated into profit that can be used to buy more and better mining hardware.

In short, the speculative price fueled the market for better mining hardware. The million time increase we have seen in performance is fueled by this same speculation.

None of this is really relevant to the area where Peter is aiming to improve things: validation speed. There is no incentive to improve things for blocks smaller than 2MB. No matter how valuable the coin is, the software will be able to validate such blocks in very short time.

The main ingredient that will drive validation architecture improvements is block-size. When block-size increases the validation speed becomes more relevant. It is worth pointing out that Peters idea is still tied to this exact same limitation. Without block sizes dramatically increasing his idea will have no effect either.

The basic idea that Peter made was to force UTXO commitment calculation to be finished before the block can be mined. He implied that he thinks validation is to be finished. But if you take a moment you will realize that when there is a profit motive involved where miners are incentivized to work around the normal way of things. It is pretty simple and much faster to write code that calculates the UTXO commitment without doing any validation. Then starting to do header-first mining and proceed to the more costly part of validation.

His suggestion doesn't actually reach the goal he wants to reach. Indeed, it will actually add a new step that has to be completed before the validation starts, which makes the miner take even longer before he can start mining on a fully validated block.

At best this proposal forces the miner to download all the transactions or the transaction-IDs, it wont affect validation.

The idea of UTXO-commitments do not themselves have any requirements on validation speed. We can have commitments without the added burden on the miner. Simple solution is to make the commitment recorded be from 100 blocks ago. The proposal intentionally uses commitments to create a higher cost to validate then there has to be.

If we ignore the plea to get developers paid in order to fix this introduced problem, we are left with the question of how header-first mining is an issue. Is it really that severe that the incentives need to be fixed? It turns out that, no its not.

Header-first mining is the principle that a miner first gets a block-header, which takes no time at all to validate, and only some time later the entire block which takes a measurable time to validate.

The moment a miner validates the new block header he is aware that he lost the block race for that block and continuing to try to mine one is most likely not going to give him any profit, whereas the cost of electricity will be substantial.

The simple solution would be to turn off the mining hardware for the seconds between receiving the block-header and when he finishes validation of a block. This, however, is very bad for the hardware and shortens their lifetime. So, what is the miner to do with the running mining hardware?

The most profitable solution is to create an empty block, that builds on the block-header already validated, and mine that. Then when the full block is validated do we start to add transactions to the template to mine.

This approach is not uncommon in the mining world today, and the fact that we see very little empty blocks on our chain shows that this is not a problem to the ecosystem. There actually is no evidence to support there is an actual problem on Bitcoin Cash.

Miners simply have a choice of mining to compete with block that they already lost the race to, or mine on top of it. This is an important choice to realize that the miner has to make. The indirect result of successfully making validation a requirement will not be empty blocks, it will just change the choice outcome. Instead of empty blocks the miner now may go for orphan blocks to hope that the previous one was faulty. The mining hashpower has to go somewhere, making more expensive the most profitable choice doesn't change this.

Whenever there is an effort to try to change incentives to an open system there are always unintended side-effects (read more). These side-effects in many cases are worse than the actual issue that they tried to fix. It is the main issue why our modern economies are so screwed up and why we have millions of laws that limit free trade.

One side-effect that is very likely to occur in a world where the protocol intentionally makes validation-time part of the economic profit model is that this software will become closed-source.

Because when faster means higher profit then a miner can not afford to not get the fastest software. This means that a new ecosystem could start up to sell miners the validation software (or infrastructure) and since there is real money to be made there it will be closed source software and companies could compete with each other on creating faster solutions.

While this sounds perfectly in line with the idea of getting faster validation speeds, it does pose create a new problem where the infrastructure for mining becomes more closed. As we see today: there is really not a lot of choice of vendors when it comes to mining hardware for sha256.

I'd argue that when closed source software owned by the next Microsoft being the main way to validate a chain, we'd be much worse off. We'd set back the idea of a Bitcoin Cash Economy by years. Miners are not the only ones that validate the chain. All economic players should have that ability.

The way that startups are measured is that growth is the main driver and measure of success. If Bitcoin Cash was a startup the aim would be to have growth in users and growth in transaction volume. There will not be a single honest person that will blame the performance of validation as the reason we can't onboard more users and get more growth today.

This translates into the simple conclusion that effort and funds should, and do, go to areas where growth is currently constricted. In my personal opinion this is mostly end-user experience and merchant on-boarding.

This is where money and effort does go to, and rightfully so.