path: root/21/d86233d68d7eb2e3528ce3dbbac40e4a8da05a

Return-Path: <m@ib.tc>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 68228C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Sep 2020 23:53:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 55BFC8481F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Sep 2020 23:53:57 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id I4ySbknxMgzi
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Sep 2020 23:53:56 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com
 [209.85.221.66])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id EFC3580CDE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Sep 2020 23:53:55 +0000 (UTC)
Received: by mail-wr1-f66.google.com with SMTP id g4so3626604wrs.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Sep 2020 16:53:55 -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=9aH+52EeF4LRU38CQAIwgg147PHaEfyhHEs3Y89bh8g=;
 b=DmAY1A9D6hvluggTpZ1NOrPTh1MyglRffJQnyOLcyUUcKCtPTMSSQfMMyjtsPcMqyQ
 QxozGLjHOOoQGFGvI/ReOSWW486jEOoPzuXnMANOCqPGQeZbogM7EeKc5nxQl52i6lky
 50Cx1smlVii24nklUx3MTAlrZHUugzBvUTGU7v3HD1tLeMyu2FfF+mnUwpwGBr02S8XD
 GVpwl3J/a4YcBTVw1JEoqwQdo/JNmnzP7l2XudsvevOMscz8x70BqThZPj2nbbcUNhS6
 j4okDrRKWD6PVOjbCkF8YMTkJTjsBZfBdpyHq/KmwC6xNGdkz8UtURUVZPy69D/AuJ+D
 HM9A==
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=9aH+52EeF4LRU38CQAIwgg147PHaEfyhHEs3Y89bh8g=;
 b=H9sb2CLxCeT5h3YeDv0Egyvx40bqom2dXrfH91HSlo3D3KCxnfvsY88DyKohYR6BHe
 RGKjpOsTLzk+YDw3lLardr/H1sPBZXL5CBLMNYFg1cDviOQLVZjtpEaxbFhu0fvmsEn+
 ea+CPaXCTkhSqEfrq0cVUBrTDs6OG+TmUZkrmAYfX+z5EpvBRVwsNZ4Bc9jSGiBr/RVY
 QRpfx7/ORYdNeogRhQh60vyQK6OSsT9M7PcJj3jDEpUuVxbG9JaPqRacpFdGzVPkIpYO
 bMbrWFpMQAyg26JYjuaphnKdf0+DnXPtbaWNS1x+iPUZ3+3pU/vOHrGGlQvuabuhT1jp
 55Gg==
X-Gm-Message-State: AOAM5327u3vcTR3TK8dpkl4KFNZHSmI5UDIzFUVy9GmYUufJvCS6bPGq
 vhnnwEVI2ZJ+6WatOuwqz6aCl67I35k+ZJ3XBMOfXQ==
X-Google-Smtp-Source: ABdhPJxQey4bTEpAVB5Q/XS6eIQXv7dCR0jaNGwBQ4Ju4xNzD4cuIDJrEp4hDx5tNktgcPxaI5DjNYJbP5+hiIZLjyY=
X-Received: by 2002:adf:fc4e:: with SMTP id e14mr5661847wrs.329.1601510034195; 
 Wed, 30 Sep 2020 16:53:54 -0700 (PDT)
MIME-Version: 1.0
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
 <CACAqsqOSBrdUo4VTUsG68dSDpfZfVOXvnMK5nqmvuhxRCC0gjQ@mail.gmail.com>
 <CALFqKjQP75TdaDeop-bxpcW5PHpmG4RwW-MDjUFGrqUy=xNdoQ@mail.gmail.com>
 <5RgK7X_rcpeMbdOdFxKiWkzg6dVcjD0uF_KI8Wt2w7WCBd7dB552EZuRqNQiBbgF4dGBcojwE9GzdWdJeCNmaAlYGYDMAyz6yzSl2QmLC98=@protonmail.com>
 <CALFqKjQDx7BrGEUJLhN=VXS8c--bVOJV4pvQTV6ag2Cy+GjWbw@mail.gmail.com>
 <SSp6MfYHW3q4TqoWyK-2ZUzLQbAqaWxTzJd62cAwKd1tFRac-embhjUZKogr3m__GcIezY5-llLyO91lur7bamlM6tiHRs-nGCNMxe2UKLE=@protonmail.com>
In-Reply-To: <SSp6MfYHW3q4TqoWyK-2ZUzLQbAqaWxTzJd62cAwKd1tFRac-embhjUZKogr3m__GcIezY5-llLyO91lur7bamlM6tiHRs-nGCNMxe2UKLE=@protonmail.com>
From: Mike Brooks <m@ib.tc>
Date: Wed, 30 Sep 2020 16:53:25 -0700
Message-ID: <CALFqKjSiyjvtkmdSodP8pXdjxw+k0nJn_jTy06CQ6VHe3XTn2g@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000b15aba05b0909c40"
X-Mailman-Approved-At: Thu, 01 Oct 2020 08:51:51 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Mike Brooks <f@in.st.capital>
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: Wed, 30 Sep 2020 23:53:57 -0000

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

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=3DCVE-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 =E2=80=94 it was the time I used DKIM signature-malleability to con=
duct 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 =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.  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 i=
ts
> 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+fee=
s
> 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, b=
y
> 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 mini=
ng
> 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
>

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

<div dir=3D"ltr"><div>ZmnSCPxj,</div><div><br></div><div>The growing tare i=
n growing disagreement continues to divide mining capacity while the networ=
k waits for formation of future blocks - you&#39;ll never get to complete=
=C2=A0consensus=C2=A0unless three is a way to avoid ambiguity in=C2=A0disag=
reement,=C2=A0which you have not addressed.=C2=A0 The topic of my discussio=
n is an exploitable condition, your three block plan does not add up.</div>=
<div><br></div><div>I wrote the exploit before I wrote the paper. It is tel=
ling that still no one here has refenced the threat model, which is the lar=
gest section of the entire 8 page paper.=C2=A0 The security came before the=
 introduction of FPNC because security=C2=A0fundamentals=C2=A0is what drive=
s the necessity for the solution.</div><div><br></div><div>The text you are=
 reading right now was delivered using the mailing list manager=C2=A0<a hre=
f=3D"http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2011-0049" target=
=3D"_blank">Majordomo2, which I shelled in 2011</a> and got a severity metr=
ic and an alert in the DHS newsletter. Correct me if I am wrong, but I bet =
that just of my exploits has probably=C2=A0<a href=3D"https://www.theregist=
er.com/2010/05/11/phpnuke_infection_purged/" target=3D"_blank">popped more =
shells</a> than everyone on this thread combined.=C2=A0=C2=A0 Cryptography?=
=C2=A0 Sure, I&#39;ll brag about the time I hacked Square Inc. This is actu=
ally my current favorite crypto exploit=C2=A0=E2=80=94 it was the time I us=
ed DKIM signature-malleability to conduct a replay-attack that allowed an a=
dversary to replay another user&#39;s transactions an unlimited number of t=
imes. After receiving=C2=A0a normal payment from another Square user you co=
uld empty their account.=C2=A0 This was reported ethically and it was a mut=
ual joy to work with such a great team.=C2=A0

 Now it is not just impact, but I am also getting the feeling that I have c=
ollected more CVEs, all this is to say that I&#39;m not new to difficult ve=
ndors.

</div><div><br></div><div>To be blunt; some of you on this thread are behav=
ing like a virgin=C2=A0reading a trashy love novel and failing to see the p=
oint =E2=80=94 Just because you aren&#39;t excited, doesn&#39;t mean that i=
t isn&#39;t hot.<br></div><div><br></div><div>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. However,=C2=A0if the consensus is a rejec=
tion, then there shouldn&#39;t be any concerns with a sensible 90-day discl=
osure policy.=C2=A0</div><div><br></div><div>Regards,</div><div>Mike Brooks=
</div></div><div dir=3D"auto"></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Wed, Sep 30, 2020, 4:45 PM ZmnSCPxj &lt;<a=
 href=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@protonm=
ail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex">Good morning Mike,<br>
<br>
An observation to be made is that the current &quot;first seen&quot; is mor=
e incentive-compatible than floating-point Nakamoto consensus.<br>
<br>
If a miner A mines a block at height N, then obviously the first block it h=
as seen is that block.<br>
<br>
If due to propagation delays on the network, another miner B mines an alter=
native 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 re=
ject its own version of that block and mine on top of the miner B alternati=
ve version, even if floating-point Nakamoto consensus is deployed by most n=
odes.<br>
<br>
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 b=
lock subsidy and fees of two blocks.<br>
And since block height, as I understand it, trumps over floating-point Naka=
moto consensus, the B version will be reorganized out anyway in that case.<=
br>
If miner A had switched to mining on top of the miner B block, then if it w=
on another block at height N+1, it would have lost the block subsidy+fees o=
f the lower-scoring miner A block at height N.<br>
<br>
<br>
Thus, floating-point Nakamoto consensus is not incentive-compatible, so I d=
oubt it would have any kind of adoption.<br>
<br>
<br>
The problems with stability you mention can be fixed, fairly trivially, by =
simply waiting for 3 confirmations rather than just 1 confirmation.<br>
<br>
<br>
In a relativistic universe, information cannot propagate faster than light-=
speed, and thus there will always be a communications network delay in prop=
agating data.<br>
As I see it, floating-point Nakamoto consensus cannot fix this issue, as it=
 cannot change underlying laws of the universe.<br>
<br>
If your goal is &quot;stability&quot; of some kind, then there is still alw=
ays a possibility that two miners on opposite sides of the Earth will creat=
e blocks at the same height outside of the light cones of each other.<br>
In a relativistic universe, this cannot be eliminated unless all miners occ=
upy the same physical location, i.e. have centralized in the same mining ha=
rdware.<br>
<br>
One of those two blocks created will, with high probability, have a lower s=
core, 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, the=
n switch to the higher-scored block when it arrives to them.<br>
<br>
Thus, floating-point Nakamoto consensus cannot provide complete stability o=
f the network, still, as the universe we operate in does not have instantan=
eous information transfer.<br>
<br>
A wise designer of automated systems will ***still*** wait for 3 confirmati=
ons before doing anything, and by then, the effects of floating-point Nakam=
oto consensus will be literally a thing of the past.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000b15aba05b0909c40--