Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus

From: ZmnSCPxj <[email-masked]>
Date: Wed, 30 Sep 2020 23:44:59 +0000

Good morning Mike,

An observation to be made is that the current "first seen" is more incentive-compatible than floating-point Nakamoto consensus.

If a miner A mines a block at height N, then obviously the first block it has seen is that block.

If due to propagation delays on the network, another miner B mines an alternative block (let us say with more fitness score, regardless of the details of the fitness metric you use) at height N, miner A has no incentive to reject its own version of that block and mine on top of the miner B alternative version, even if floating-point Nakamoto consensus is deployed by most nodes.

Even if the rest of the mining network is now mining on top of the miner B version, if miner A chances on another new block at N+1 built on top of its own version of block N, then it would still win both blocks and earn the block subsidy and fees of two blocks.
And since block height, as I understand it, trumps over floating-point Nakamoto consensus, the B version will be reorganized out anyway in that case.
If miner A had switched to mining on top of the miner B block, then if it won another block at height N+1, it would have lost the block subsidy+fees of the lower-scoring miner A block at height N.

Thus, floating-point Nakamoto consensus is not incentive-compatible, so I doubt it would have any kind of adoption.

The problems with stability you mention can be fixed, fairly trivially, by simply waiting for 3 confirmations rather than just 1 confirmation.

In a relativistic universe, information cannot propagate faster than light-speed, and thus there will always be a communications network delay in propagating data.
As I see it, floating-point Nakamoto consensus cannot fix this issue, as it cannot change underlying laws of the universe.

If your goal is "stability" of some kind, then there is still always a possibility that two miners on opposite sides of the Earth will create blocks at the same height outside of the light cones of each other.
In a relativistic universe, this cannot be eliminated unless all miners occupy the same physical location, i.e. have centralized in the same mining hardware.

One of those two blocks created will, with high probability, have a lower score, and thus any nodes in the light cone of the miner of the lower-scored block will still experience a reorg, as they will first see one block, then switch to the higher-scored block when it arrives to them.

Thus, floating-point Nakamoto consensus cannot provide complete stability of the network, still, as the universe we operate in does not have instantaneous information transfer.

A wise designer of automated systems will ***still*** wait for 3 confirmations before doing anything, and by then, the effects of floating-point Nakamoto consensus will be literally a thing of the past.

Regards,
ZmnSCPxj