path: root/03/1bf79557aa7b6027eaa00a98cf1fc0503710c5

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 90E91C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  1 Oct 2020 06:47:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 786DB86BAF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  1 Oct 2020 06:47:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id FHqSDHp+Bh63
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  1 Oct 2020 06:47:08 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
 [185.70.40.130])
 by whitealder.osuosl.org (Postfix) with ESMTPS id E743C86BAD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  1 Oct 2020 06:47:07 +0000 (UTC)
Date: Thu, 01 Oct 2020 06:47:01 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1601534824;
 bh=I+7vIlMY58+54vETBorDs8iO/Ju4r4/Z88+r6lkwpR4=;
 h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
 b=bkEu25Czmdd8U8L3rpgvhsm0wps0aWkE/Ceeacv7z6B8eLpyDD7l5+vVoFmpTQ9GR
 WWGQ3Oghuwbh602YlmT02P9gC8XvDQAst5k0pcATYZUDD1Rppthyyipc4rDnipDQoH
 hBtG3BuNBBGDSMWIlyzy8wxSyTA3WIrndQCzz/sM=
To: Mike Brooks <m@ib.tc>, bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <2WPSOr8E15WzoaUWtShu8zEjhDuSd1324drfNlZ1JW8nFgZNk9sBXeFc2nc_LYgmWZCcgThyZXumA8xbrEyny-xAHKyJiWxl9OP1pvsmG_U=@protonmail.com>
In-Reply-To: <CALFqKjR+uK2Rr4dUsL+D=ZUba2sroqnkhC1xcGHdjjupvDc7+Q@mail.gmail.com>
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
 <5RgK7X_rcpeMbdOdFxKiWkzg6dVcjD0uF_KI8Wt2w7WCBd7dB552EZuRqNQiBbgF4dGBcojwE9GzdWdJeCNmaAlYGYDMAyz6yzSl2QmLC98=@protonmail.com>
 <CALFqKjQDx7BrGEUJLhN=VXS8c--bVOJV4pvQTV6ag2Cy+GjWbw@mail.gmail.com>
 <SSp6MfYHW3q4TqoWyK-2ZUzLQbAqaWxTzJd62cAwKd1tFRac-embhjUZKogr3m__GcIezY5-llLyO91lur7bamlM6tiHRs-nGCNMxe2UKLE=@protonmail.com>
 <CALFqKjSiyjvtkmdSodP8pXdjxw+k0nJn_jTy06CQ6VHe3XTn2g@mail.gmail.com>
 <6DNfWVT6VsuQvFamBbqyGZYokENNopo28FZO6P5-4F0uoOMz2xAAQQZxBxsOmue4J3miOoMq_2MJVpiTtUy3bE9-qMOSVXqRhQoyfriTpXU=@protonmail.com>
 <CALFqKjT_ZTnqzhvRRpFV4wzVf2pi=_G-qJvSkDmkZkhYwS-3qg@mail.gmail.com>
 <LPR_1lQZZGN-sT86purDUy8X_jF0XH35_xxdaqzRXHXPSZDtGVowS-FgIq1RN2mtT1Ds0bBErYvM-1TF7usCSAjojCCfkk5WOnZAvBLFzII=@protonmail.com>
 <CALFqKjR+uK2Rr4dUsL+D=ZUba2sroqnkhC1xcGHdjjupvDc7+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2020 06:47:10 -0000

Good morning Mike,

That is better than implied name-calling and refusing to lay out your argum=
ent 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 thi=
s 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=C2=A0have said are correct. Take=
 this moment=C2=A0to 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,=
=C2=A0unless 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 becaus=
e we live in a world where failure happens. Now if you are in a world of li=
mited visibility, and a presented solution has no intrinsic=C2=A0value othe=
r than it's length - then you create a node that is gullible.=C2=A0An adver=
sary that controls=C2=A0connections can lie that a new solution was ever ev=
en found or selectivally slow the formation of this side of the disagreemen=
t, and probably other=C2=A0bad things too.=C2=A0 =C2=A0That sucks, and no o=
ne is saying that there is a complete solution to this problem and we are a=
ll here to help.
>
> You are absolutely=C2=A0correct - the eclipse effect is never going to be=
 perfect. Which is your point,=C2=A0and it's accurate. Imperfections in the=
 node's visibility=C2=A0allow for a more-fit=C2=A0solution=C2=A0to 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/Metastabilit=
y) state, as I have mentioned.
Since block discovery is random, inevitably, even if the chain splits are e=
xactly equal in mining hashpower, by random one or the other will win the n=
ext block earlier than the other, precisely due to the random nature of min=
ing, 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 reo=
rganized out without requiring floating-point Nakamoto.

This is different if the coin had non-random block production, but fortunat=
ely 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-ru=
n accident tomorrow.

And in Bitcoin, leaving things alone is generally more important, because c=
hange 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 m=
ore information than is available to you or me.

>=C2=A0 This minor change of adding a fitness test to solve disagreements i=
s intended to diminish the influence of delayed message passing, and yes th=
ere are multiple solutions to this problem, absolutely, but bringing this f=
act up just derails the important parts of the conversation.=C2=A0
>
> 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 pro=
blem.=C2=A0 =C2=A0Any attacker can more easily control=C2=A0when a message =
arrives than a good fitness value.=C2=A0 =C2=A0The old 2013 solution was ab=
out naming one side a looser, but that doesn't really help.=C2=A0 It isn't =
just about calling one solution a winner and a loser. We need to make sure =
that all descendants=C2=A0of weak solutions are also going to be weak - and=
 that my friend is the basis for a genetic algorithm.
>
> -Michael Brooks=C2=A0
> (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.=C2=A0
> >
> > 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> wrot=
e:
> > >
> > > > Good morning Mike,
> > > >
> > > > > ZmnSCPxj,
> > > > >
> > > > > The growing tare in growing disagreement continues to divide mini=
ng capacity while the network waits for formation of future blocks - you'll=
 never get to complete=C2=A0consensus=C2=A0unless three is a way to avoid a=
mbiguity in=C2=A0disagreement,=C2=A0which you have not addressed.=C2=A0 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 secti=
on of the entire 8 page paper.=C2=A0 The security came before the introduct=
ion of FPNC because security=C2=A0fundamentals=C2=A0is what drives the nece=
ssity for the solution.
> > > > >
> > > > > The text you are reading right now was delivered using the mailin=
g list manager=C2=A0Majordomo2, 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=C2=A0popped more shells than ever=
yone on this thread combined.=C2=A0=C2=A0 Cryptography?=C2=A0 Sure, I'll br=
ag about the time I hacked Square Inc. This is actually my current favorite=
 crypto exploit=C2=A0=E2=80=94 it was the time I used DKIM signature-mallea=
bility to conduct a replay-attack that allowed an adversary to replay anoth=
er user's transactions an unlimited number of times. After receiving=C2=
=A0a normal payment from another Square user you could empty their account.=
=C2=A0 This was reported ethically and it was a mutual joy to work with suc=
h a great team.=C2=A0 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 ne=
w 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 author=
ity you may claim.
> > > >
> > > > > To be blunt; some of you on this thread are behaving like a virgi=
n=C2=A0reading a trashy love novel and failing to see the point =E2=80=
=94 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.=C2=A0 The industry standard =
of 90 days gives you until November 2nd. Now clearly, we need more time. Ho=
wever,=C2=A0if the consensus is a rejection, then there shouldn't be any co=
ncerns with a sensible 90-day disclosure policy.=C2=A0
> > > >
> > > > I am not a member of this security team, and they may have better i=
nformation 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 compellin=
g.
> > > >
> > > > The attack you describe is:
> > > >
> > > > * Not fixable by floating-point Nakamoto consensus, as such a power=
ful adversary can just as easily prevent propagation of a higher-score bloc=
k.
> > > > * Broken by even a single, manually-created connection between both=
 sides of the chain-split.
> > > >
> > > > Regards,
> > > > ZmnSCPxj


Regards,
ZmnSCPxj