path: root/a7/a7cd91981c6912e2ab40a45483b4981839cad0

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 0FDC2C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 16:00:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 0522685DA5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 16:00:28 +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 gQZq1he1q4Sh
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 16:00:25 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com
 [209.85.221.52])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 07B4F850E9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 16:00:24 +0000 (UTC)
Received: by mail-wr1-f52.google.com with SMTP id s12so5978969wrw.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 29 Sep 2020 09:00:24 -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=MdO1JW6aK5T152rOgXrYHDW+rNDuv0/knsueyRSnAXs=;
 b=jmLGwzkg9eYjI8lteHMwVd4+xlVYrbgFAw+GpW31lw6qa8LPetRPt6aSoe8s4Mc/R4
 ovbZcYWiVjpFsKaO9I+NHlwgal3+DWNHpDUn9MXBgvu6nugSO4WpYgYm1OYm5GtHmQOK
 KQ7nPPud3PqVmedfrqYqEcZ+JcsDMwArGJAw7fZw7I2uBJb0nZwpD4+8vFwn11PTLzyk
 LLpAC1KPPJapoOTazmtbosRCX8anTuxlOEaXoiyaxmwWMzXaj2WvC7htU4c77jtlz8za
 HtaDVbtth52nGXTw+G/PYP6eGJoESywwbvXeDz1juQVEk5PnVC1AeVRcekfuDeQtcH4j
 yarA==
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=MdO1JW6aK5T152rOgXrYHDW+rNDuv0/knsueyRSnAXs=;
 b=pcVJrs6sdf+8buA5lEu2xjMn4TQA0XjVmn/IOgOrzwz8mc3QX+0zS0HfqIwntgmdNR
 m0YchGshWBytj34yFXIviOFXdyrtfU8QNRczP5VjVcQcdN0D+leMGGvyAMakBhRU74uN
 lX67xeMowa3/7oD8Mf0KZ6t4YTxH2Wy0ITiu1bjik3KMmLaxYfV+TKUH8cNm0SWHXd1Z
 dNWMS8GmFJ8w+am99yHsA7cVPauvcMJjWORhyBsJnidhT3im8AhWbI9rTNhipOoYDYfK
 CqYLeCniDZAFlwB705Kqc3XaXgb4O8+cm5RucWJi9Js8fcWNq9Xnockp2ooRSNVvMZ3E
 2ehw==
X-Gm-Message-State: AOAM533ghG1XJG8MGrFzADA6/Q2C5MDTCFiXJ7h5YRDU3E8eaoVBCwVa
 wfRdZcHMPNMe/G7fbwX1KeFNmlbiBB5rAGQ+1jSU9guhBfI=
X-Google-Smtp-Source: ABdhPJw64t60M2ex2zm9RxCOKBWyTy1UqlkVBM5ljhrpHicvAHoUjfL8dYGOrxA3gnS1lwuqbWNK143adyr17gnKfmQ=
X-Received: by 2002:adf:f504:: with SMTP id q4mr5068758wro.353.1601395223325; 
 Tue, 29 Sep 2020 09:00:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
 <CACAqsqOSBrdUo4VTUsG68dSDpfZfVOXvnMK5nqmvuhxRCC0gjQ@mail.gmail.com>
In-Reply-To: <CACAqsqOSBrdUo4VTUsG68dSDpfZfVOXvnMK5nqmvuhxRCC0gjQ@mail.gmail.com>
From: Mike Brooks <m@ib.tc>
Date: Tue, 29 Sep 2020 09:00:12 -0700
Message-ID: <CALFqKjQP75TdaDeop-bxpcW5PHpmG4RwW-MDjUFGrqUy=xNdoQ@mail.gmail.com>
To: Franck Royer <franck@coblox.tech>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000006e808905b075e138"
X-Mailman-Approved-At: Tue, 29 Sep 2020 16:18:56 +0000
Cc: 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: Tue, 29 Sep 2020 16:00:28 -0000

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

Hey Frank,

Firstly, I must commend you on two very good questions.

The reason why I chose to maximize the value is because I approached this
as an optimization problem to be solved with a genetic algorithm, and it
fit with my internal model of a kind of relay race that moves forward
faster. When confronted with the paradox of one side of the solution being
minimized and the other being maximized I thought to myself that a paradox
leading to determinism was beautiful... But it doesn't have to be this way.

Part 2 of your question - what about the inevitable march of difficulty?
And here is where how we quantify fitness starts to matter.  Your right to
point this out condition, maximizing the non-zero value means that re-org
during an epoch won't optimize for having a trailing zero, which is a
conflict that I see now must be avoided.

The solution is to always choose the smallest, and the summation of all
contestant chains must also be minimized. This approach would then be
compatible with an Epoch - so much so that it would not impeed the use of a
continuous difficulty function that pegs a solution at a range of non-zero
values which would avoid a discrete cliff by requiring a whole extra zero.
We need not be a victim of an early implementation - a continuous
difficulty function would add stability to the network and this is worth
unlocking.

With added determinism and a continuous epoch, the network will be a lot
more stable.  At this point very little is stopping us from speeding up
block creation times. PoS networks are proving that conformations can be a
minute or less - why not allow for a block formation time that is 6 or 12
times faster than the current target and have 1/6th (or 1/12th) of the
subsidy to keep an identical inflation target.

=E2=80=A6 The really interesting part is the doors that this patch opens. B=
itcoin
is the best network, we have the most miners and we as developers have the
opportunity to build an even better system - all with incremental
soft-forks - which is so exciting.

What I am proposing is a patch that is ~100 lines of code and is fully
compatible with the current Bitcoin network - because I am running a node
with my changes on the network, and the more miners who adopt my patch the
more lucky we will become.

Thank you everyone,

Mike


On Mon, Sep 28, 2020, 7:18 PM Franck Royer via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Fri, 25 Sep 2020 at 22:09, Mike Brooks via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> [snip]
>
>> The solution above also has 19 prefixed zeros, and is being broadcast fo=
r
>> the same blockheight value of 639254 - and a fitness score of 1.282.  Wi=
th
>> Nakamoto Consensus both of these solutions would be equivalent and a giv=
en
>> node would adopt the one that it received first.  In Floating-Post Nakam=
oto
>> Consensus, we compare the fitness scores and keep the highest.  In this
>> case no matter what happens - some nodes will have to change their tip a=
nd
>> a fitness test makes sure this happens immediately.
>>
>
> Hi Mike,
>
> Any reason why you decided to consider the higher value the "fittest" one
> instead of keeping in line with the difficulty algorithm where smallest
> values, prefixed with more zeroes, are considered more valuable/difficult=
?
>
> Also, can you elaborate if anything special would happen if the
> competitive chains were created around a difficulty adjustment?
>
> Cheers, Franck
>
> [snip]
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto"><div><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:=
0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:arial;font=
-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:basel=
ine;white-space:pre-wrap">Hey Frank,</span></p><br><p dir=3D"ltr" style=3D"=
line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size=
:11pt;font-family:arial;font-variant-numeric:normal;font-variant-east-asian=
:normal;vertical-align:baseline;white-space:pre-wrap">Firstly, I must comme=
nd you on two very good questions.=C2=A0=C2=A0=C2=A0</span></p><br><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:11pt;font-family:arial;font-variant-numeric:normal;font-=
variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">The=
 reason why I chose to maximize the value is because I approached this as a=
n optimization problem to be solved with a genetic algorithm, and it fit wi=
th my internal model of a kind of relay race that moves forward faster. Whe=
n confronted with the paradox of one side of the solution being minimized a=
nd the other being maximized I thought to myself that a paradox leading to =
determinism was beautiful... But it doesn&#39;t have to be this way.=C2=A0<=
/span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margi=
n-bottom:0pt"><span style=3D"font-size:11pt;font-family:arial;font-variant-=
numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white=
-space:pre-wrap">Part 2 of your question - what about the inevitable march =
of difficulty?=C2=A0 And here is where how we quantify fitness starts to ma=
tter.=C2=A0 Your right to point this out condition, maximizing the non-zero=
 value means that re-org during an epoch won&#39;t optimize for having a tr=
ailing zero, which is a conflict that I see now must be avoided.</span></p>=
<br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0=
pt"><span style=3D"font-size:11pt;font-family:arial;font-variant-numeric:no=
rmal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre=
-wrap">The solution is to always choose the smallest, and the summation of =
all contestant chains must also be minimized. This approach would then be c=
ompatible with an Epoch - so much so that it would not impeed the use of a =
continuous difficulty function that pegs a solution at a range of non-zero =
values which would avoid a discrete cliff by requiring a whole extra zero.=
=C2=A0 We need not be a victim of an early implementation - a continuous di=
fficulty function would add stability to the network and this is worth unlo=
cking.=C2=A0</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-=
top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:arial;=
font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:b=
aseline;white-space:pre-wrap">With added determinism and a continuous epoch=
, the network will be a lot more stable.=C2=A0 At this point very little is=
 stopping us from speeding up block creation times. PoS networks are provin=
g that conformations can be a minute or less - why not allow for a block fo=
rmation time that is 6 or 12 times faster than the current target and have =
1/6th (or 1/12th) of the subsidy to keep an identical inflation target.</sp=
an></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-b=
ottom:0pt"><span style=3D"font-size:11pt;font-family:arial;font-variant-num=
eric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-sp=
ace:pre-wrap">=E2=80=A6 The really interesting part is the doors that this =
patch opens. Bitcoin is the best network, we have the most miners and we as=
 developers have the opportunity to build an even better system - all with =
incremental soft-forks - which is so exciting.</span></p><br><p dir=3D"ltr"=
 style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D=
"font-size:11pt;font-family:arial;font-variant-numeric:normal;font-variant-=
east-asian:normal;vertical-align:baseline;white-space:pre-wrap">What I am p=
roposing is a patch that is ~100 lines of code and is fully compatible with=
 the current Bitcoin network - because I am running a node with my changes =
on the network, and the more miners who adopt my patch the more lucky we wi=
ll become.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-to=
p:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:arial;fo=
nt-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:bas=
eline;white-space:pre-wrap">Thank you everyone,</span></p><p dir=3D"ltr" st=
yle=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"fo=
nt-size:11pt;font-family:arial;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;vertical-align:baseline;white-space:pre-wrap">Mike</span></p=
><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Mon, Sep 28, 2020, 7:18 PM Franck Royer via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"norefe=
rrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, 25 Sep 2020 at 22:09,=
 Mike Brooks via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org" rel=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; wrote:<br></div><div>[snip] <br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span id=3D=
"m_-8567650515942928251m_-7931859574589037102gmail-m_3279177725432408729gma=
il-m_2766209350405513116gmail-docs-internal-guid-77a2432b-7fff-62c3-0753-fe=
93652ca512"></span><div><span id=3D"m_-8567650515942928251m_-79318595745890=
37102gmail-m_3279177725432408729gmail-m_2766209350405513116gmail-docs-inter=
nal-guid-77a2432b-7fff-62c3-0753-fe93652ca512"><p dir=3D"ltr" style=3D"line=
-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11p=
t;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-vari=
ant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;w=
hite-space:pre-wrap">The solution above also has 19 prefixed zeros, and is =
being broadcast for the same blockheight value of 639254 - and a fitness sc=
ore of 1.282.=C2=A0 With Nakamoto Consensus both of these solutions would b=
e equivalent and a given node would adopt the one that it received first.=
=C2=A0 In Floating-Post Nakamoto Consensus, we compare the fitness scores a=
nd keep the highest.=C2=A0 In this case no matter what happens - some nodes=
 will have to change their tip and a fitness test makes sure this happens i=
mmediately.=C2=A0</span></p></span></div></div></blockquote><div><br></div>=
<div>Hi Mike,</div><div><br></div><div>Any reason why you decided to consid=
er the higher value the &quot;fittest&quot; one instead of keeping in line =
with the difficulty algorithm where smallest values, prefixed with more zer=
oes, are considered more valuable/difficult?<br></div><div>=C2=A0</div><div=
>Also, can you elaborate if anything special would happen if the competitiv=
e chains were created around a difficulty adjustment?<br></div><div><br></d=
iv><div>Cheers, Franck<br></div><div><br></div><div>[snip] <br></div></div>=
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>

--0000000000006e808905b075e138--