From: Mike Brooks <m@ib•tc>
To: "David A. Harding" <dave@dtrt•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
Date: Sat, 26 Sep 2020 04:09:23 -0700 [thread overview]
Message-ID: <CALFqKjTOiyBJFJokya88CmMnGUsYajDmX8oKo07vFkuD2uJxmA@mail.gmail.com> (raw)
In-Reply-To: <20200926101123.utnxzs7kx5ozwedm@ganymede>
[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 4380 bytes --]
next prev parent reply other threads:[~2020-09-26 11:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 19:40 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 [this message]
2020-09-29 1:51 ` Franck Royer
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=CALFqKjTOiyBJFJokya88CmMnGUsYajDmX8oKo07vFkuD2uJxmA@mail.gmail.com \
--to=m@ib$(echo .)tc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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