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

[Mike Brooks <m@ib.tc>]

[-- Attachment #1: Type: text/plain, Size: 5424 bytes --]

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
<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0049> 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
<https://www.theregister.com/2010/05/11/phpnuke_infection_purged/> 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
>

[-- Attachment #2: Type: text/html, Size: 5999 bytes --]