path: root/49/7b7e61eae68cd9dfa1291a9775a7fe0eb04672

Return-Path: <m@ib.tc>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 09CBCC0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  4 Oct 2020 15:59:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id E5C9786FDA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  4 Oct 2020 15:59:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 4fRo1mVKGn3V
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  4 Oct 2020 15:59:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com
 [209.85.221.47])
 by hemlock.osuosl.org (Postfix) with ESMTPS id AB07586F58
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  4 Oct 2020 15:59:21 +0000 (UTC)
Received: by mail-wr1-f47.google.com with SMTP id n15so1135248wrq.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 04 Oct 2020 08:59:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ib.tc; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=v5M4RzGzIp6msyerqa+n+qvDsy3cZQpkat4bSVGouko=;
 b=CH2SQykwBHWju1XqOTk2UiZ9df2prLDrK4SwDMUMWKRSqGCu/wSNeyfDrn1nYb2Ihv
 157S+nstYT/uwL2W5Yvk6Kz44IoPUaXgK/xCA9rFoj5r58JGhaNuXEHHsshW/ICX/IbK
 0IiWoDXo1JtyJCVsCpEhKQb+usuuhUqTRhP4ILHiXwEm58938VFUiD6tuIt55o6phtBb
 JioRGDj4bg5eRe6dF++h+47F7nLpHZcuQrV3CD59aS2ieozk/chMhc3sH3ieEvw8SRkc
 ZwrCTc+tzg8y5UjA4th/KXcCYCpR4AUPnoGG89upac3iaSoFDVBv4XlMozyh/htc+XVJ
 3uJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=v5M4RzGzIp6msyerqa+n+qvDsy3cZQpkat4bSVGouko=;
 b=cW7/wOsoORIudKQma3d6MLN6x0q4C4g+yVYGSvmfb8HcqfifDxBAwV/XAH96AuTGG8
 1N/8yvgKGC9IVDOAAWJ4V316dN8PWgAW4YF3PxpVTKdiaYF5C89nf9AOSOauh/pSWfO6
 t0BfIADBiBTk4CMFw2ausgaFan3ttP/nlrxNHISWuRWNJ9Tjiq401EpdaUT2IrYGTJ2g
 9Ym9mI/G8U3p/mQ+bazlLShqhH/A5IaL+Qvv1jiY5Dta+O1S8lU7DmxvJCETjhoJknyE
 FTVPhW0JQcUmjfEY8sqQDirU7AoGgaqYjN7+vUuaWD8MBA1VO4bNB1RvBSjLlG994Df5
 OH4w==
X-Gm-Message-State: AOAM533ugofAZZ9e7hH2x0uOkX8rveb3wyKbRJKnk1/rdiu2OZhIQbnn
 D2x9aZ+gFnyrOWf0W4WSs/J9f1GmSCZ1Bf0mfnV5EA==
X-Google-Smtp-Source: ABdhPJzTINHMrnpuaME2dwjjatED2HK860NQ/z1mUYPSI003E+00s9VwOncmr3Hbx577dJgMyJoRpG/f5EzBb/x6WX8=
X-Received: by 2002:adf:fc4e:: with SMTP id e14mr13110055wrs.329.1601827159829; 
 Sun, 04 Oct 2020 08:59:19 -0700 (PDT)
MIME-Version: 1.0
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>
 <2WPSOr8E15WzoaUWtShu8zEjhDuSd1324drfNlZ1JW8nFgZNk9sBXeFc2nc_LYgmWZCcgThyZXumA8xbrEyny-xAHKyJiWxl9OP1pvsmG_U=@protonmail.com>
In-Reply-To: <2WPSOr8E15WzoaUWtShu8zEjhDuSd1324drfNlZ1JW8nFgZNk9sBXeFc2nc_LYgmWZCcgThyZXumA8xbrEyny-xAHKyJiWxl9OP1pvsmG_U=@protonmail.com>
From: Mike Brooks <m@ib.tc>
Date: Sun, 4 Oct 2020 08:58:58 -0700
Message-ID: <CALFqKjR=-eWG93qheBB82sUT88+Lj_PmvbiC=zb0hToviLpGyA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000da81d005b0da726f"
X-Mailman-Approved-At: Sun, 04 Oct 2020 17:49:27 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
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: Sun, 04 Oct 2020 15:59:23 -0000

--000000000000da81d005b0da726f
Content-Type: text/plain; charset="UTF-8"

Good Morning ZmnSCPxj ,

It is cheaper and easier to delay messages, or preempt the spreading of
messages, than it is to produce a better fitness score. Whether it be
through pre-emption or an eclipse - an adversary can influence the size of
both sides of the disagreement, which is a strange feature for any network
to have.  "First seen" is a factor of time, time is an attacker-controlled
element, and this dependence on time creates a race-condition.

My original statement is that it is cheaper to introduce a large number of
non-voting nodes, than it is compeate on mining power -  holds true.  It
doesn't have to be perfect to be a shortcut, an adversary can perform the
same kind of impact as 51% attack - so long as they have a sufficient
number of non-voting nodes.   My language here is referring to the original
paper which makes reference to non-voting nodes and that the electorate
must only be made by computational effort. However, a sufficient number of
non-voting nodes who diligently pass messages, hold the keys to the kingdom.


> 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.
>

* Power is relative, my only comment is that message passing is cheaper
than mining - and that this proposed attack is somewhat better than 51%
mining attack.
* Assuming all adversaries are crippled will not produce a very good threat
model.
* Both sides need to be more or less equal - in practice I don't think this
needs to be exact, and only needs to be held open long enough to trick
validators.  It can and will be unstable, but still exploitable.

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.
>

Mr Nakamoto is assuming normal network conditions - if a majority of
messages are passed by malicious nodes, then this conjecture no longer
holds.  If the majority are dishonest, and non-voting, then the rules
change.


> 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.


Offline, we had discussed that there is currently an active
malicious-mining campaign being conducted against the Bitcoin network.
Large mining pools will delay the broadcast of a block that they have
formed in order to have a slight advantage on the formation of the next
block.   Currently, there is an economic incentive for the formation of
disagreement and it is being actively exploited.   FPNC means that blocks
below the 1/2 cut-off are greatly incentivised to be broadcast as quickly
as possible, and blocks above the cutt-off could be held onto a little
longer.  This withholding attack is already taking place because there is
an economic incentive.  Although no proposed solution can prevent it
completely,  seeing that this bad thing would happen 1/2 as often - I see
this as an absolute win.

-Michael

--000000000000da81d005b0da726f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"></div><div class=3D"gmail_quote"><div>Goo=
d Morning ZmnSCPxj ,</div><div><br></div><div>It is cheaper and easier to d=
elay messages, or preempt the spreading of messages, than it is to produce =
a better fitness score. Whether it be through pre-emption or an eclipse - a=
n adversary can influence the size of both sides of the disagreement, which=
 is a strange feature for any network to=C2=A0have.=C2=A0 &quot;First seen&=
quot; is a factor of time, time is an attacker-controlled element, and this=
 dependence on time creates a race-condition.=C2=A0<br></div><div><br></div=
><div>My original=C2=A0statement=C2=A0is that it is cheaper to introduce a =
large number of non-voting nodes, than it is compeate on mining power -=C2=
=A0 holds true.=C2=A0 It doesn&#39;t have to be perfect to be a shortcut, a=
n adversary can perform=C2=A0the same kind of impact as 51% attack - so lon=
g as they have a sufficient number of non-voting nodes.=C2=A0 =C2=A0My lang=
uage here is referring to the original paper which makes reference to non-v=
oting nodes and that the electorate must only be made by computational effo=
rt. However, a sufficient number of non-voting nodes who diligently pass me=
ssages, hold=C2=A0the keys to the kingdom.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">
This is the point at which I think your argument fails.<br>
<br>
You are expecting:<br>
<br>
* That the attacker is powerful enough to split the network.<br>
* That the attacker is adept enough that it can split the network such that=
 mining hashpower is *exactly* split in half.<br>
* 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.<br></blockquote><div><br></div><div>* Power is relativ=
e, my only comment is that message passing is cheaper than mining - and tha=
t this proposed attack is somewhat better than 51% mining attack.=C2=A0</di=
v><div><div>* Assuming all adversaries are crippled will not produce a very=
 good threat model.=C2=A0</div><div>* Both sides need to be more or less eq=
ual - in practice I don&#39;t think this needs to be exact, and only needs =
to be held open long enough to trick validators.=C2=A0 It can and will be u=
nstable, but still exploitable.=C2=A0</div></div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
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.<br>
<br>
Yet this is a [***metastable***](<a href=3D"https://en.wikipedia.org/wiki/M=
etastability" rel=3D"noreferrer" target=3D"_blank">https://en.wikipedia.org=
/wiki/Metastability</a>) state, as I have mentioned.<br>
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.<br></blockquote><di=
v>=C2=A0</div><div>Mr Nakamoto is assuming normal network conditions - if a=
 majority of messages are passed by malicious nodes, then this conjecture n=
o longer holds.=C2=A0 If the majority are dishonest, and non-voting, then t=
he rules change.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
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.<br>
I would suggest deferring to those in the security team, as they may have m=
ore information than is available to you or me.</blockquote><div>=C2=A0</di=
v><div>Offline, we had discussed that there is currently an active maliciou=
s-mining campaign being conducted against the Bitcoin network.=C2=A0 Large =
mining pools will delay the broadcast of a block that they have formed in o=
rder to have a slight advantage on the formation of the next block.=C2=A0 =
=C2=A0Currently, there is an economic incentive for the formation of disagr=
eement and it is being actively exploited.=C2=A0 =C2=A0FPNC means that bloc=
ks below the 1/2 cut-off=C2=A0are greatly incentivised to be broadcast as q=
uickly as possible, and blocks above the cutt-off=C2=A0could be held onto a=
 little longer.=C2=A0 This withholding attack is already taking place becau=
se there is an economic incentive.=C2=A0 Although no proposed solution can =
prevent it completely,=C2=A0 seeing that this bad thing would happen 1/2 as=
 often - I see this as an absolute win.</div><div><br></div><div>-Michael</=
div></div>
</div>

--000000000000da81d005b0da726f--