public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Brooks <m@ib.tc>
To: Franck Royer <franck@coblox.tech>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: Mike Brooks <f@in.st.capital>
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
Date: Tue, 29 Sep 2020 09:00:12 -0700	[thread overview]
Message-ID: <CALFqKjQP75TdaDeop-bxpcW5PHpmG4RwW-MDjUFGrqUy=xNdoQ@mail.gmail.com> (raw)
In-Reply-To: <CACAqsqOSBrdUo4VTUsG68dSDpfZfVOXvnMK5nqmvuhxRCC0gjQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3734 bytes --]

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.

… 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.

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 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]
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 7720 bytes --]

  reply	other threads:[~2020-09-29 16:00 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
2020-09-29 16:00   ` Mike Brooks [this message]
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='CALFqKjQP75TdaDeop-bxpcW5PHpmG4RwW-MDjUFGrqUy=xNdoQ@mail.gmail.com' \
    --to=m@ib.tc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=f@in.st.capital \
    --cc=franck@coblox.tech \
    /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