From: Franck Royer <franck@coblox.tech>
To: Mike Brooks <f@in.st.capital>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
Date: Tue, 29 Sep 2020 11:51:03 +1000 [thread overview]
Message-ID: <CACAqsqOSBrdUo4VTUsG68dSDpfZfVOXvnMK5nqmvuhxRCC0gjQ@mail.gmail.com> (raw)
In-Reply-To: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]
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]
[-- Attachment #2: Type: text/html, Size: 2050 bytes --]
next prev parent reply other threads:[~2020-09-29 1:58 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 19:40 [bitcoin-dev] Floating-Point Nakamoto Consensus Mike Brooks
2020-09-25 15:18 ` bitcoin ml
2020-09-25 16:04 ` Mike Brooks
2020-09-25 16:33 ` Jeremy
2020-09-25 17:35 ` Mike Brooks
2020-09-26 10:11 ` David A. Harding
2020-09-26 11:09 ` Mike Brooks
2020-09-29 1:51 ` Franck Royer [this message]
2020-09-29 16:00 ` Mike Brooks
2020-09-30 6:31 ` ZmnSCPxj
2020-09-30 6:37 ` Mike Brooks
2020-09-30 23:44 ` ZmnSCPxj
2020-09-30 23:53 ` Mike Brooks
2020-10-01 1:36 ` ZmnSCPxj
[not found] ` <CALFqKjT_ZTnqzhvRRpFV4wzVf2pi=_G-qJvSkDmkZkhYwS-3qg@mail.gmail.com>
[not found] ` <LPR_1lQZZGN-sT86purDUy8X_jF0XH35_xxdaqzRXHXPSZDtGVowS-FgIq1RN2mtT1Ds0bBErYvM-1TF7usCSAjojCCfkk5WOnZAvBLFzII=@protonmail.com>
[not found] ` <CALFqKjR+uK2Rr4dUsL+D=ZUba2sroqnkhC1xcGHdjjupvDc7+Q@mail.gmail.com>
2020-10-01 6:47 ` ZmnSCPxj
2020-10-04 15:58 ` Mike Brooks
2020-10-01 16:42 ` Larry Ruane
2020-10-01 19:26 ` Mike Brooks
2020-09-29 3:10 ` LORD HIS EXCELLENCY JAMES HRMH
2020-10-10 1:26 ` Mike Brooks
2020-10-15 16:02 ` yanmaani
2020-10-08 18:43 ` Bob McElrath
2020-10-10 0:59 ` Mike Brooks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACAqsqOSBrdUo4VTUsG68dSDpfZfVOXvnMK5nqmvuhxRCC0gjQ@mail.gmail.com \
--to=franck@coblox.tech \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=f@in.st.capital \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox