ZmnSCPxj,

The growing tare in growing disagreement continues to divide mining capacity while the network waits for formation of future blocks - you'll never get to complete consensus unless three is a way to avoid ambiguity in disagreement, which you have not addressed. The topic of my discussion is an exploitable condition, your three block plan does not add up.

I wrote the exploit before I wrote the paper. It is telling that still no one here has refenced the threat model, which is the largest section of the entire 8 page paper. The security came before the introduction of FPNC because security fundamentals is what drives the necessity for the solution.

The text you are reading right now was delivered using the mailing list manager Majordomo2, which I shelled in 2011 and got a severity metric and an alert in the DHS newsletter. Correct me if I am wrong, but I bet that just of my exploits has probably popped more shells than everyone on this thread combined. Cryptography? Sure, I'll brag about the time I hacked Square Inc. This is actually my current favorite crypto exploit — it was the time I used DKIM signature-malleability to conduct a replay-attack that allowed an adversary to replay another user's transactions an unlimited number of times. After receiving a normal payment from another Square user you could empty their account. This was reported ethically and it was a mutual joy to work with such a great team. Now it is not just impact, but I am also getting the feeling that I have collected more CVEs, all this is to say that I'm not new to difficult vendors.

To be blunt; some of you on this thread are behaving like a virgin reading a trashy love novel and failing to see the point — Just because you aren't excited, doesn't mean that it isn't hot.

The exploit described in this paper was delivered to the Bitcoin-core security team on August 4 at 9:36 PM PST. The industry standard of 90 days gives you until November 2nd. Now clearly, we need more time. However, if the consensus is a rejection, then there shouldn't be any concerns with a sensible 90-day disclosure policy.

Regards,

Mike Brooks

On Wed, Sep 30, 2020, 4:45 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

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