Addressing the errors in Peter Rizuns' proposal

4 344
Avatar for TomZ
Written by
  30
3 weeks ago

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.

Technically it doesn't actually work

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.

What problem is this meant to solve?

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.

Unintended side-effects

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.

How to go forward

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.

$ 33.03
$ 20.00 from @molecular
$ 5.00 from @SharkySharkdog
$ 2.00 from @ErdoganTalk
+ 10
Avatar for TomZ
Written by
  30
3 weeks ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

Thanks for helping drive more discussion on this topic, Tom. [Side note: I do wish you had picked a title for your article that was less personal. Also, an idea you disagree with is not an error, but rather something you disagree with].

The big picture idea is that to grow BCH to global levels we want a stable, largely unchanging, and economically rational protocol upon which implementations of that protocol can compete. The key points are:

  1. The protocol (set of rules governing what constitutes a valid transaction or block) is distinct from software implementations of that protocol.

  2. We don’t need a lot of development of the protocol to scale BCH massively. And in fact we shouldn’t want the protocol being tinkered with constantly. The protocol should be stabilizing and getting to a point where changes are rare.

  3. We WILL need development of better (optimized) implementations to enable BCH to scale massively.

A lot of people will agree with these three points. Now ask yourself what the incentives are to develop those better implementations today? The fact that a proposal to reroute a portion of the coinbase reward directly into the wallets of a few developers might activate is proof we don't have a good answer!

Imagine that our friend Bob from Alice and Bob fame were to create awesome new node technology that could validate one million transactions per second on low cost hardware. This is the kind of technology bitcoin needs to scale to global levels, but is that technology worth anything? Even if given away for free, would the miners run it? Maybe, but maybe not [more on this later]. What I realised the other day was that if validationless mining was not the intended way to run the network. And that if it were more costly (and many people, SD Lerner of RSK for example, agree that it is possible to discourage validationless mining), then a genuine market for the fastest block validation tech would naturally emerge as blocks got bigger. Groups would compete in an open, permissionless market to develop the fastest tech, because the fastest tech would directly increase a miners' revenue.

Which leads to my fourth point:

  1. Fixing the incentives re: block validation would unleash competitive market forces such that those better implementations would be self-incentivized by competing miners’ profit motive.

To understand the market dynamics, assume that no miners engaged in validationless mining (we can bike shed how to make this assumption a reality later). The reason this creates a market for fast validation technology is because miners could not start mining a new block until they had validated the previous block, and every second they spent validating would be a second they could not spend potentially earning the next coinbase reward.

For example, assume the average block size increased to 8 MB and using the "reference client" it took 7 seconds to validate a block. Those are 7 seconds that the miner cannot be working on finding a new block. The revenue he expects to earn is 1% less than if he could validate the block in 1 second ((7s - 1s) / 600s = 0.01). To add some numbers, at $10,000 per coin a 6s advantage would be worth $6.6M per year to a miner with 10% of the hash power (12.5 10000 144 365 .1 .01 = 6.57106).

We're talking real money here.

There would be genuine market demand to pay for technology to give miners a head start on the next block, compared to their peers. The same dynamics that played out with SHA256 hashing technology would play out with block validation technology. The one difference however, is that at least a little bit of demand for transactions is required, unlike the market for hashing. If miners can validate the last block using the current reference client in less than a second anyways, then there's not much money to be gained by making validation faster.

$ 0.00
User's avatar PeterRizun
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
3 weeks ago

Side note: I do wish you had picked a title for your article that was less personal.

It wasn't your proposal? I have been told many times by BU members that they can't represent BU itself, they are just members. BU itself needs a vote before it can have an opinion.

Also, an idea you disagree with is not an error, but rather something you disagree with

Nah, there really were actual errors in your logic that lead you to the conclusions you had.

Actually, you haven't addressed ANY of the errors. You just made clear you really want reality to bend to your will. How is that working out for you?

$ 0.00
3 weeks ago

You make a good point that producing a UTXO commitment does not actually prove validation.

But the rest I do not agree with. The open things in Bitcoin are the protocol and the reference implementations. There is already closed source software in every corner. If there were some way to require proof of validation, it would make Bitcoin safer.

$ 0.00
3 weeks ago

thanks for writing this article. on first sight Peter's idea seemed awesome to me. now I think maybe it's not a good idea at all.

$ 0.00
3 weeks ago
About us Rules What is Bitcoin Cash? Roadmap Affiliate program Get sponsored Self-host
hello@read.cash (PGP key) Reddit