From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id B3EC3C0859 for ; Sat, 26 Sep 2020 11:09:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id A22E22043E for ; Sat, 26 Sep 2020 11:09:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd24QyGPPCvW for ; Sat, 26 Sep 2020 11:09:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by silver.osuosl.org (Postfix) with ESMTPS id CCA872043A for ; Sat, 26 Sep 2020 11:09:35 +0000 (UTC) Received: by mail-wm1-f43.google.com with SMTP id e17so1791521wme.0 for ; Sat, 26 Sep 2020 04:09:35 -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=4vc5gkDVEoYExViUOSbjVMXB8JiYNabiqYKISiUCuSE=; b=h8dq3ourGiqjIS1dJ7goxhG3L6dxGJCafpw8y4/jaLgdSTcm4BXYjTrolOafnKFyTQ 3wFl6BrRAdpdgmNvVVF+oPnaJlG+rbadjwH4H28jyIF13fcPz6FFBsW1UkeEWQPb09ob AaOgDU3ln5I8CiUOYhml350jAAnaeIOJ/4g/RDEoPjPnS3IljFasA7RofDJGB+RgA1tc 0oOV2hGnSEWur1FJYPbMtpn5VDqK5Ixgxe9nVnJUmAhopR6G7NeFfwCg6yi+IDYfDBbJ WQfe1wuOO6eZXEOZ9zzyTyjaVgq1LZuzUXmzXQrU4Fo7ZXdhN6CVs86rwD4Z6+LAoAqP 1lsg== 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=4vc5gkDVEoYExViUOSbjVMXB8JiYNabiqYKISiUCuSE=; b=W9oLl0DQtsHK0Ge0hE9zwGcVhVPp0+9BTvxhWGzrU5TpjsRQKV4Olq1ALjSKzFrike Xrs+ZC5NeJKbyKTx+uBO/rlyuFLXyUeuSpu4qX71yeZURk61RZ0Nyni9GF6lYLJLf4mh R+PB5FYb3Rg8m5xxYQ5Iiw0TR0EWPWldNicjpVDFTHnKXvyimCbgx1LepLp7m9WPc7yA TppN2OekfrjovgnTH297JjlvplJmps1ukx95JrbLIXN5QOUw6eRGsSucL8UoFg0tfzlU FD+0HonBTdTuK9IKG7TdeCLxWzQJZncgEZI2UJHzvMc/516A6qBHejGbIBX9pj+HQjR6 B02w== X-Gm-Message-State: AOAM530XXD3sp2yL641jlSfPSIdh6jCdqXhh8B8TNTsa8m/6t8heQAws kcpzMe9ZneyPnb45BDnKunagnLJY+f9t4L0bZBS1MjX79Lo= X-Google-Smtp-Source: ABdhPJw5t2pfglCiWr8tpKQ40yw3p20Mv7JBv/wEJrtE1m9njaw8kAbEBvaworSi4b+mii2PboH+lroJNDiSuxib5GQ= X-Received: by 2002:a1c:6555:: with SMTP id z82mr2156360wmb.101.1601118574057; Sat, 26 Sep 2020 04:09:34 -0700 (PDT) MIME-Version: 1.0 References: <20200926101123.utnxzs7kx5ozwedm@ganymede> In-Reply-To: <20200926101123.utnxzs7kx5ozwedm@ganymede> From: Mike Brooks Date: Sat, 26 Sep 2020 04:09:23 -0700 Message-ID: To: "David A. Harding" Content-Type: multipart/alternative; boundary="000000000000d9b22305b0357734" X-Mailman-Approved-At: Sat, 26 Sep 2020 11:14:58 +0000 Cc: Bitcoin Protocol Discussion 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: Sat, 26 Sep 2020 11:09:37 -0000 --000000000000d9b22305b0357734 Content-Type: text/plain; charset="UTF-8" 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 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 > --000000000000d9b22305b0357734 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Very interesting find - there are simil= arities here, but this is hardly identical.=C2=A0

I am largely in agreement with Quinn (from 2013) - s= imply using the lowest block value was a bad idea because the value cannot = be carried forward to resolve disagreements greater than N+1. Simply pickin= g 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.=C2=A0

The zero-prefix component can be thought of driving a lower numer= ic value in big-edian which is the verifiable proof-of-work we know to expe= ct.=C2=A0 The remaining value could be minimized or maximized in any edenes= s - 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.=C2=A0

As to Quinn's point - I don't think it should= be random.=C2=A0 The miner's choice of picking the most fit soluton me= ans the any future children of the winning solution will also be further ah= ead.=C2=A0 "Survival of the fittest" block -=C2=A0 The winners ha= ve the home field advantage of being in the lead for the next round - and a= ny miners that disagree are fools to start from a starting line that is fur= ther behind.

The differe= nce between the 2013 post and FPNC is the alignment of incentives.=C2=A0

-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:
> -=C2=A0 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 ha= s
> already been mined.=C2=A0 =C2=A0This is all about keeping incentives m= oving forward.

FYI, I think this topic has been discussed on the list before (in
response to the selfish mining paper).=C2=A0 See this proposal:

=C2=A0 https://lists.linuxfoundation.org/pipermail/bitcoin-de= v/2013-November/003583.html

Of its responses, I thought these two stood out in particular:

=C2=A0 https://lists.linuxfoundation.org/pipermail/bitcoin-de= v/2013-November/003584.html
=C2=A0 https://lists.linuxfoundation.org/pipermail/bitcoin-de= v/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 t= he
idea of using hash values but which does describe some of the challenges in replacing first seen as the tip disambiguation method.=C2=A0 There may b= e
other useful posts in that thread---I didn't take the time to skim all<= br> 11 pages.

=C2=A0 https://bitcointalk.org/index.php?topic=3D324413.msg3476697#msg= 3476697

-Dave
--000000000000d9b22305b0357734--