path: root/ca/2c97cc3a836be22503977b89588307f86a725d

Return-Path: <m@ib.tc>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B3EC3C0859
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Sep 2020 11:09:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id A22E22043E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Sep 2020 11:09:37 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Jd24QyGPPCvW
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Sep 2020 11:09:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com
 [209.85.128.43])
 by silver.osuosl.org (Postfix) with ESMTPS id CCA872043A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Sep 2020 11:09:35 +0000 (UTC)
Received: by mail-wm1-f43.google.com with SMTP id e17so1791521wme.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Sep 2020 04:09:35 -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=4vc5gkDVEoYExViUOSbjVMXB8JiYNabiqYKISiUCuSE=;
 b=h8dq3ourGiqjIS1dJ7goxhG3L6dxGJCafpw8y4/jaLgdSTcm4BXYjTrolOafnKFyTQ
 3wFl6BrRAdpdgmNvVVF+oPnaJlG+rbadjwH4H28jyIF13fcPz6FFBsW1UkeEWQPb09ob
 AaOgDU3ln5I8CiUOYhml350jAAnaeIOJ/4g/RDEoPjPnS3IljFasA7RofDJGB+RgA1tc
 0oOV2hGnSEWur1FJYPbMtpn5VDqK5Ixgxe9nVnJUmAhopR6G7NeFfwCg6yi+IDYfDBbJ
 WQfe1wuOO6eZXEOZ9zzyTyjaVgq1LZuzUXmzXQrU4Fo7ZXdhN6CVs86rwD4Z6+LAoAqP
 1lsg==
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=4vc5gkDVEoYExViUOSbjVMXB8JiYNabiqYKISiUCuSE=;
 b=W9oLl0DQtsHK0Ge0hE9zwGcVhVPp0+9BTvxhWGzrU5TpjsRQKV4Olq1ALjSKzFrike
 Xrs+ZC5NeJKbyKTx+uBO/rlyuFLXyUeuSpu4qX71yeZURk61RZ0Nyni9GF6lYLJLf4mh
 R+PB5FYb3Rg8m5xxYQ5Iiw0TR0EWPWldNicjpVDFTHnKXvyimCbgx1LepLp7m9WPc7yA
 TppN2OekfrjovgnTH297JjlvplJmps1ukx95JrbLIXN5QOUw6eRGsSucL8UoFg0tfzlU
 FD+0HonBTdTuK9IKG7TdeCLxWzQJZncgEZI2UJHzvMc/516A6qBHejGbIBX9pj+HQjR6
 B02w==
X-Gm-Message-State: AOAM530XXD3sp2yL641jlSfPSIdh6jCdqXhh8B8TNTsa8m/6t8heQAws
 kcpzMe9ZneyPnb45BDnKunagnLJY+f9t4L0bZBS1MjX79Lo=
X-Google-Smtp-Source: ABdhPJw5t2pfglCiWr8tpKQ40yw3p20Mv7JBv/wEJrtE1m9njaw8kAbEBvaworSi4b+mii2PboH+lroJNDiSuxib5GQ=
X-Received: by 2002:a1c:6555:: with SMTP id z82mr2156360wmb.101.1601118574057; 
 Sat, 26 Sep 2020 04:09:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
 <dbb83152-bca4-9ac6-a7cc-9f39ece7a2e4@thomaskerin.io>
 <CAD5xwhgBwC337+85vffiuEtBenqb5NDES=E7r+YsAcEtgmBHMw@mail.gmail.com>
 <CALFqKjTcTVK40XpzRR1Mre42CNURgyP1ppG4ZeTfs5a51WiesA@mail.gmail.com>
 <20200926101123.utnxzs7kx5ozwedm@ganymede>
In-Reply-To: <20200926101123.utnxzs7kx5ozwedm@ganymede>
From: Mike Brooks <m@ib.tc>
Date: Sat, 26 Sep 2020 04:09:23 -0700
Message-ID: <CALFqKjTOiyBJFJokya88CmMnGUsYajDmX8oKo07vFkuD2uJxmA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000d9b22305b0357734"
X-Mailman-Approved-At: Sat, 26 Sep 2020 11:14:58 +0000
Cc: Bitcoin Protocol Discussion <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: Sat, 26 Sep 2020 11:09:37 -0000

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

Very interesting find - there are similarities here, but this is hardly
identical.

>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003584.html

I am largely in agreement with Quinn (from 2013) - simply using the lowest
block value was a bad idea because the value cannot be carried forward to
resolve disagreements greater than N+1. Simply picking a lower value in big
edian is a nieve approach to disagreement resolution that would result in
trashing. I thought of this before writing the paper, and then thought
better of it.

The zero-prefix component can be thought of driving a lower numeric value
in big-edian which is the verifiable proof-of-work we know to expect.  The
remaining value could be minimized or maximized in any edeness - so long as
it is consistent - but more importantly the winner needs to be ahead of the
race for the next block, and we need to add a mechanism by which to make it
more expencive to replace an existing block than producing a new block -
all three components solve the issue at hand, cutting one of these out
isn't a complete answer.

As to Quinn's point - I don't think it should be random.  The miner's
choice of picking the most fit soluton means the any future children of the
winning solution will also be further ahead.  "Survival of the fittest"
block -  The winners have the home field advantage of being in the lead for
the next round - and any miners that disagree are fools to start from a
starting line that is further behind.

The difference between the 2013 post and FPNC is the alignment of
incentives.

-Mike


On Sat, Sep 26, 2020, 3:12 AM David A. Harding <dave@dtrt.org> wrote:

> On Fri, Sep 25, 2020 at 10:35:36AM -0700, Mike Brooks via bitcoin-dev
> wrote:
> > -  with a fitness test you have a 100% chance of a new block from being
> > accepted, and only a 50% or less chance for replacing a block which has
> > already been mined.   This is all about keeping incentives moving
> forward.
>
> FYI, I think this topic has been discussed on the list before (in
> response to the selfish mining paper).  See this proposal:
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003583.html
>
> Of its responses, I thought these two stood out in particular:
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003584.html
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003588.html
>
> I think there may be some related contemporary discussion from
> BitcoinTalk as well; here's a post that's not directly related to the
> idea of using hash values but which does describe some of the challenges
> in replacing first seen as the tip disambiguation method.  There may be
> other useful posts in that thread---I didn't take the time to skim all
> 11 pages.
>
>   https://bitcointalk.org/index.php?topic=324413.msg3476697#msg3476697
>
> -Dave
>

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

<div dir=3D"auto"><div dir=3D"auto">Very interesting find - there are simil=
arities here, but this is hardly identical.=C2=A0</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">&gt; <a href=3D"https://lists.linuxfoundation.org=
/pipermail/bitcoin-dev/2013-November/003584.html">https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2013-November/003584.html</a><br></div><div =
dir=3D"auto"><br></div>I am largely in agreement with Quinn (from 2013) - s=
imply using the lowest block value was a bad idea because the value cannot =
be carried forward to resolve disagreements greater than N+1. Simply pickin=
g a lower value in big edian is a nieve approach to disagreement resolution=
 that would result in trashing. I thought of this before writing the paper,=
 and then thought better of it.=C2=A0<div dir=3D"auto"><br></div><div dir=
=3D"auto">The zero-prefix component can be thought of driving a lower numer=
ic value in big-edian which is the verifiable proof-of-work we know to expe=
ct.=C2=A0 The remaining value could be minimized or maximized in any edenes=
s - so long as it is consistent - but more importantly the winner needs to =
be ahead of the race for the next block, and we need to add a mechanism by =
which to make it more expencive to replace an existing block than producing=
 a new block - all three components solve the issue at hand, cutting one of=
 these out isn&#39;t a complete answer.=C2=A0</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">As to Quinn&#39;s point - I don&#39;t think it should=
 be random.=C2=A0 The miner&#39;s choice of picking the most fit soluton me=
ans the any future children of the winning solution will also be further ah=
ead.=C2=A0 &quot;Survival of the fittest&quot; block -=C2=A0 The winners ha=
ve the home field advantage of being in the lead for the next round - and a=
ny miners that disagree are fools to start from a starting line that is fur=
ther behind.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The differe=
nce between the 2013 post and FPNC is the alignment of incentives.=C2=A0</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">-Mike</div><div dir=3D"aut=
o"><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Sat, Sep 26, 2020, 3:12 AM David A. Harding &lt;<a href=3D"=
mailto:dave@dtrt.org" rel=3D"noreferrer noreferrer" target=3D"_blank">dave@=
dtrt.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep=
 25, 2020 at 10:35:36AM -0700, Mike Brooks via bitcoin-dev wrote:<br>
&gt; -=C2=A0 with a fitness test you have a 100% chance of a new block from=
 being<br>
&gt; accepted, and only a 50% or less chance for replacing a block which ha=
s<br>
&gt; already been mined.=C2=A0 =C2=A0This is all about keeping incentives m=
oving forward.<br>
<br>
FYI, I think this topic has been discussed on the list before (in<br>
response to the selfish mining paper).=C2=A0 See this proposal:<br>
<br>
=C2=A0 <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2=
013-November/003583.html" rel=3D"noreferrer noreferrer noreferrer noreferre=
r" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2013-November/003583.html</a><br>
<br>
Of its responses, I thought these two stood out in particular:<br>
<br>
=C2=A0 <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2=
013-November/003584.html" rel=3D"noreferrer noreferrer noreferrer noreferre=
r" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2013-November/003584.html</a><br>
=C2=A0 <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2=
013-November/003588.html" rel=3D"noreferrer noreferrer noreferrer noreferre=
r" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2013-November/003588.html</a><br>
<br>
I think there may be some related contemporary discussion from<br>
BitcoinTalk as well; here&#39;s a post that&#39;s not directly related to t=
he<br>
idea of using hash values but which does describe some of the challenges<br=
>
in replacing first seen as the tip disambiguation method.=C2=A0 There may b=
e<br>
other useful posts in that thread---I didn&#39;t take the time to skim all<=
br>
11 pages.<br>
<br>
=C2=A0 <a href=3D"https://bitcointalk.org/index.php?topic=3D324413.msg34766=
97#msg3476697" rel=3D"noreferrer noreferrer noreferrer noreferrer" target=
=3D"_blank">https://bitcointalk.org/index.php?topic=3D324413.msg3476697#msg=
3476697</a><br>
<br>
-Dave<br>
</blockquote></div>

--000000000000d9b22305b0357734--