From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 68228C0051 for ; 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 ; 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 ; 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 ; Wed, 30 Sep 2020 23:53:55 +0000 (UTC) Received: by mail-wr1-f66.google.com with SMTP id g4so3626604wrs.5 for ; 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: <5RgK7X_rcpeMbdOdFxKiWkzg6dVcjD0uF_KI8Wt2w7WCBd7dB552EZuRqNQiBbgF4dGBcojwE9GzdWdJeCNmaAlYGYDMAyz6yzSl2QmLC98=@protonmail.com> In-Reply-To: From: Mike Brooks Date: Wed, 30 Sep 2020 16:53:25 -0700 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000b15aba05b0909c40" X-Mailman-Approved-At: Thu, 01 Oct 2020 08:51:51 +0000 Cc: Bitcoin Protocol Discussion , Mike Brooks 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 =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 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
ZmnSCPxj,

The growing tare i= n growing disagreement continues to divide mining capacity while the networ= k waits for formation of future blocks - you'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.
=

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.

The text you are= reading right now was delivered using the mailing list manager=C2=A0Majordomo2, which I shelled in 2011 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=A0popped more = shells than everyone on this thread combined.=C2=A0=C2=A0 Cryptography?= =C2=A0 Sure, I'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'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'm not new to difficult ve= ndors.

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't excited, doesn't mean that i= t 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. However,=C2=A0if the consensus is a rejec= tion, then there shouldn't be any concerns with a sensible 90-day discl= osure policy.=C2=A0

Regards,
Mike Brooks=

On Wed, Sep 30, 2020, 4:45 PM ZmnSCPxj <ZmnSCPxj@protonm= ail.com> wrote:
Good morning Mike,

An observation to be made is that the current "first seen" is mor= e incentive-compatible than floating-point Nakamoto consensus.

If a miner A mines a block at height N, then obviously the first block it h= as seen is that block.

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.

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


Thus, floating-point Nakamoto consensus is not incentive-compatible, so I d= oubt 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 prop= agating 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 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.
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.

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.

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.

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.


Regards,
ZmnSCPxj
--000000000000b15aba05b0909c40--