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

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Mike,

That is better than implied name-calling and refusing to lay out your argument in detail.
It is still sub-optimal since you are still being insulting by labeling me as "reactionary", when you could have just laid out the exact same argument ***in the first place*** without being unnecessarily inflammatory, but this is significantly better than your previous behavior.

I also strongly prefer to discuss this openly on the mailing list.

> Consider for one moment when the words I have said are correct. Take this moment to see the world from someone else's eyes, and do not be reactionary - just be.
>
> Good.
>
> Consider a threat model, where nodes are unable to form new connections, unless the attacker allows it to happen. The point of threat modeling is not to question if it is possible, but rather to plan on failure because we live in a world where failure happens. Now if you are in a world of limited visibility, and a presented solution has no intrinsic value other than it's length - then you create a node that is gullible. An adversary that controls connections can lie that a new solution was ever even found or selectivally slow the formation of this side of the disagreement, and probably other bad things too.   That sucks, and no one is saying that there is a complete solution to this problem and we are all here to help.
>
> You are absolutely correct - the eclipse effect is never going to be perfect. Which is your point, and it's accurate. Imperfections in the node's visibility allow for a more-fit solution to leak out, and ultimately an identical consensus to form - so long as there is some measure to judge the fitness of two disagreements of identical length.

This is the point at which I think your argument fails.

You are expecting:

* That the attacker is powerful enough to split the network.
* That the attacker is adept enough that it can split the network such that mining hashpower is *exactly* split in half.
* That the universe is in an eldritch state such that at the exact time one side of the chain split finds a block, the other side of the chain split *also* finds a block.

This leads to a metastable state, where both chain splits have diverged and yet are at the exact same block height, and it is true that this state can be maintained indefinitely, with no 100% assurance it will disappear.

Yet this is a [***metastable***](https://en.wikipedia.org/wiki/Metastability) state, as I have mentioned.
Since block discovery is random, inevitably, even if the chain splits are exactly equal in mining hashpower, by random one or the other will win the next block earlier than the other, precisely due to the random nature of mining, and if even a single direct connection were manually made between the chain splits, this would collapse the losing chain split and it will be reorganized out without requiring floating-point Nakamoto.

This is different if the coin had non-random block production, but fortunately in Bitcoin we use proof-of-work.

The confluence of too many things (powerful attacker, exact hashpower split, perfect metastability) is necessary for this state --- and your solution to this state --- to actually ***matter*** in practice.
I estimate that it is far more likely my meat avatar will be destroyed in a hit-and-run accident tomorrow than such a state actually occurring, and I do not bother worrying about my meat avatar being destroyed by a hit-and-run accident tomorrow.

And in Bitcoin, leaving things alone is generally more important, because change is always a risk, as it may introduce *other*, more dangerous attacks that we have not thought of.
I would suggest deferring to those in the security team, as they may have more information than is available to you or me.

>  This minor change of adding a fitness test to solve disagreements is intended to diminish the influence of delayed message passing, and yes there are multiple solutions to this problem, absolutely, but bringing this fact up just derails the important parts of the conversation. 
>
> By the client having limited visibility, then non-voting nodes who simply pass messages *are* given a say in the election process, and that is a problem.   Any attacker can more easily control when a message arrives than a good fitness value.   The old 2013 solution was about naming one side a looser, but that doesn't really help.  It isn't just about calling one solution a winner and a loser. We need to make sure that all descendants of weak solutions are also going to be weak - and that my friend is the basis for a genetic algorithm.
>
> -Michael Brooks 
> (my real name)

Do you think emphasizing that this is your real name ***matters*** compared to actual technical arguments?

>
> On Wed, Sep 30, 2020 at 6:45 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> > Good morning Mike,
> >
> > > You are incorrect. 
> >
> > You make no argument to back this claim, so I will now refuse to engage with you.
> >
> > Regards,
> > ZmnSCPxj
> >
> > >
> > > On Wed, Sep 30, 2020, 6:36 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> > >
> > > > Good morning Mike,
> > > >
> > > > > 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.
> > > >
> > > > Argument screens off authority, thus, even if I have no CVEs under this pseudonym, argument must still be weighted more highly than any authority you may claim.
> > > >
> > > > > 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. 
> > > >
> > > > I am not a member of this security team, and they may have better information and arguments than I do, in which case, I would defer to them if they are willing to openly discuss it and I find their arguments compelling.
> > > >
> > > > The attack you describe is:
> > > >
> > > > * Not fixable by floating-point Nakamoto consensus, as such a powerful adversary can just as easily prevent propagation of a higher-score block.
> > > > * Broken by even a single, manually-created connection between both sides of the chain-split.
> > > >
> > > > Regards,
> > > > ZmnSCPxj


Regards,
ZmnSCPxj