MIME-Version: 1.0
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
In-Reply-To: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
From: Franck Royer <franck@coblox.tech>
Date: Tue, 29 Sep 2020 11:51:03 +1000
Message-ID: <CACAqsqOSBrdUo4VTUsG68dSDpfZfVOXvnMK5nqmvuhxRCC0gjQ@mail.gmail.com>
To: Mike Brooks <f@in.st.capital>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a83d7e05b06a048d"
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
Precedence: list

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

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 for
> the same blockheight value of 639254 - and a fitness score of 1.282.  With
> Nakamoto Consensus both of these solutions would be equivalent and a given
> node would adopt the one that it received first.  In Floating-Post Nakamoto
> 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 and
> 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]

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

<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.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><div>[snip] <br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span id=
=3D"gmail-m_3279177725432408729gmail-m_2766209350405513116gmail-docs-intern=
al-guid-77a2432b-7fff-62c3-0753-fe93652ca512"></span><div><span id=3D"gmail=
-m_3279177725432408729gmail-m_2766209350405513116gmail-docs-internal-guid-7=
7a2432b-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:11pt;font-fam=
ily:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeri=
c:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space=
:pre-wrap">The solution above also has 19 prefixed zeros, and is being broa=
dcast for the same blockheight value of 639254 - and a fitness score of 1.2=
82.=C2=A0 With Nakamoto Consensus both of these solutions would be equivale=
nt and a given node would adopt the one that it received first.=C2=A0 In Fl=
oating-Post Nakamoto Consensus, we compare the fitness scores and keep the =
highest.=C2=A0 In this case no matter what happens - some nodes will have t=
o change their tip and a fitness test makes sure this happens immediately.=
=C2=A0</span></p></span></div></div></blockquote><div><br></div><div>Hi Mik=
e,</div><div><br></div><div>Any reason why you decided to consider the high=
er value the &quot;fittest&quot; one instead of keeping in line with the di=
fficulty algorithm where smallest values, prefixed with more zeroes, are co=
nsidered more valuable/difficult?<br></div><div>=C2=A0</div><div>Also, can =
you elaborate if anything special would happen if the competitive chains we=
re created around a difficulty adjustment?<br></div><div><br></div><div>Che=
ers, Franck<br></div><div><br></div><div>[snip] <br></div></div></div>

--000000000000a83d7e05b06a048d--