From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0FDC2C0051 for ; 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 ; 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 ; 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 ; Tue, 29 Sep 2020 16:00:24 +0000 (UTC) Received: by mail-wr1-f52.google.com with SMTP id s12so5978969wrw.11 for ; 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: In-Reply-To: From: Mike Brooks Date: Tue, 29 Sep 2020 09:00:12 -0700 Message-ID: To: Franck Royer , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000006e808905b075e138" X-Mailman-Approved-At: Tue, 29 Sep 2020 16:18:56 +0000 Cc: Mike Brooks 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

Hey Frank,


Firstly, I must comme= nd you on two very good questions.=C2=A0=C2=A0=C2=A0


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't have to be this way.=C2=A0<= /span>


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't optimize for having a tr= ailing 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 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


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.


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


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.


Thank you everyone,

Mike

O= n 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 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


=
Hi Mike,

Any reason why you decided to consid= er the higher value the "fittest" one instead of keeping in line = with the difficulty algorithm where smallest values, prefixed with more zer= oes, are considered more valuable/difficult?
=C2=A0
Also, can you elaborate if anything special would happen if the competitiv= e chains were created around a difficulty adjustment?

Cheers, Franck

[snip]
=
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.li= nuxfoundation.org/mailman/listinfo/bitcoin-dev
--0000000000006e808905b075e138--