path: root/41/f2ed0151b3f82f3039f403f48960bcf95a50fc

Return-Path: <m@ib.tc>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 36611C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Sep 2020 17:44:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 1EC06875B8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Sep 2020 17:44:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id pM5SEebS3kqV
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Sep 2020 17:44:12 +0000 (UTC)
X-Greylist: delayed 00:08:01 by SQLgrey-1.7.6
Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com
 [209.85.128.50])
 by hemlock.osuosl.org (Postfix) with ESMTPS id D4415875B0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Sep 2020 17:44:11 +0000 (UTC)
Received: by mail-wm1-f50.google.com with SMTP id l15so2356407wmh.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Sep 2020 10:44:11 -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=EdHWtZ0nN03CjYCafTFgmEAErZG8oqstumNrR4LfDsk=;
 b=n1WOtxQMIROuQ5d5NDwBTeoD41ZAF801K+nqasRNbomTO/rdSASNe06mk1HLoHo/Kh
 MuH0F1Zpz5KkYOOBaisv2GS4msKOq+OjndVldNBXsiHdMWbN9dU1+IvLwEfOgxPkPU6m
 c3rd6qUCQsoKZSj0bwkjbe6PGhFvhVeF6lkc/Lq1BPi3zynBLkVIK08281YILbHNesD5
 wyAD1iAg68SsyGm6Y/VmImfH0wZ9ffKypZAg6ussUzdg2n5gR7pG9kxbzwBVAguUURvm
 1lJOQHTreNYqYx2KZGHgKi+Ud/Dh9h9VBgu/B5TjCI1az/0crcohhJnBA4Le4T/A1lly
 dzgg==
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=EdHWtZ0nN03CjYCafTFgmEAErZG8oqstumNrR4LfDsk=;
 b=N25vJeHvoENNODD/wbpLF0lMC81m++YId/7sNuC1pabkEcW6oZO+2tfiUr9a34rDJn
 pKvbSWlK/vB8rgURHfVLST3iNtz7wJynPNQYKFHOU7R7rw0LgITWNPoRv+Ai3uc8XGD6
 GgwAi/V+MQhvhy3fOfYQ1laEnLdGiIO5i0VTgHMnVCk2mlR7u1xafZo+PClmOoUCFY1U
 +51SCBz8wk3jqrq8JVlgOJpgDIX7m1e/4GbYbmKIPy8Xg00FQbySe2uWGV6VmhG/xNJ/
 PMBuiC/u9PkZ+HOOO+VpyUwohJO89kGacgJQPbgW3OF8b95Yd2zDzY7bpeEUz9nbPs00
 pEbQ==
X-Gm-Message-State: AOAM530TOlsjD1Y9Ehurgznw+HftKP2wyOHxmDjIAjOucLqFbFQCwFwW
 autKNVzs+S6qqDDXRl+tGhtTORrBNKb89vERtFm5sHfgvzA=
X-Google-Smtp-Source: ABdhPJxIlt5x7SSCIN/LFHAgYzvR+4MSUBmu2D17rtVh+CLoN6FE+/FWhSfv1JyJvTMCzqOH8yGYXJnp6NJ06L0mLuU=
X-Received: by 2002:a1c:9a0c:: with SMTP id c12mr4384578wme.85.1601055368801; 
 Fri, 25 Sep 2020 10:36:08 -0700 (PDT)
MIME-Version: 1.0
References: <CAPaMHfTSqyDDBfmdM=z-FtLRTUxed2pNmoOFx-t2w0MyZ_mgCg@mail.gmail.com>
 <dbb83152-bca4-9ac6-a7cc-9f39ece7a2e4@thomaskerin.io>
 <CAD5xwhgBwC337+85vffiuEtBenqb5NDES=E7r+YsAcEtgmBHMw@mail.gmail.com>
In-Reply-To: <CAD5xwhgBwC337+85vffiuEtBenqb5NDES=E7r+YsAcEtgmBHMw@mail.gmail.com>
From: Mike Brooks <m@ib.tc>
Date: Fri, 25 Sep 2020 10:35:36 -0700
Message-ID: <CALFqKjTcTVK40XpzRR1Mre42CNURgyP1ppG4ZeTfs5a51WiesA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008605b505b026c085"
X-Mailman-Approved-At: Fri, 25 Sep 2020 17:52:18 +0000
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Sep 2020 17:44:16 -0000

--0000000000008605b505b026c085
Content-Type: text/plain; charset="UTF-8"

Hey Jeremy,

Thanks for your response, but I think you misunderstood a crucial feature
-  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.

"First seen" was easy to implement, but has a few undesirable attributes.
 One of the big problems is that I don't think it is fair to allow for a
miner to ignore a solution block and still have an unpenalized opportunity
to replace it - this is very much possible with the first scene and an
eclipse of the network to dictate which solution will be seen first by
affected nodes.   Making it more expensive to replace hard work instead of
contributing to new work is a useful feature for stability.  Eclipsing
allows the attacker to make sure that one solution will be seen before
another - but this race condition is resolved uniformly if we have a
fitness test.

But let's dig into this topic more.  What would actually lead to
"thrashing" or unnecessary replacement of the tip?  A malicious miner who
has observed the creation of a new block and intends to replace it - would
have to exceed the work needed to generate a new block - and crucially will
have less time to perform this task than the entire network as whole.
Fitness introduces a neat boundary, whereby it is always cheaper to make a
new block than replace the existing block - which means it would take at
least a 51% attack to overcome this attribute.   That being said, without
this feature - less than 51% is needed when you have miners that will work
for you for free.

-Mike



On Fri, Sep 25, 2020 at 9:33 AM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If I understand correctly, this is purely a policy level decision to
> accept first-seen or a secondary deterministic test, but the most-work
> chain is still always better than a "more fit" but less work chain.
>
> In any case, I'm skeptical of the properties of this change. First-seen
> has a nice property that once you receive a block, you have a substantially
> reduced incentive to try to orphan it because the rest of the network is
> going to work on building on that block. With fitness, I have a 50% shot if
> I mine a block of mine being accepted, so floating point would have the
> effect of destabilizing consensus convergence at the tip.
>
> I could see using a fitness rule like this be useful if you see both
> blocks within some very small window, e.g., 10 seconds, as it could
> decrease partition risk if it's likely the orphan was mined within close
> range of the other.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000008605b505b026c085
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hey Jeremy,</div><div><br></div><div>Thanks for your =
response, but I think you misunderstood a crucial=C2=A0feature -=C2=A0 with=
 a fitness=C2=A0test you have a 100% chance of a new block from being accep=
ted, and only a 50% or less chance for replacing a block which has already=
=C2=A0been mined.=C2=A0 =C2=A0This is all about keeping incentives moving f=
orward.</div><div><br></div>&quot;First seen&quot; was easy to implement, b=
ut has a few undesirable attributes.=C2=A0 =C2=A0One of the big problems is=
 that I don&#39;t think it is fair to allow for a miner to ignore a solutio=
n block and still have an unpenalized opportunity to replace it - this is v=
ery much possible with the first scene and an eclipse of the network to dic=
tate which solution will be seen first by affected nodes.=C2=A0 =C2=A0Makin=
g it more expensive=C2=A0to replace hard work instead of contributing to ne=
w work is a useful feature for stability.=C2=A0 Eclipsing allows the attack=
er to make sure that one solution will be seen before another - but this ra=
ce condition is resolved uniformly if we have a fitness test.<div><br></div=
><div>But let&#39;s dig into this topic more.=C2=A0 What would actually lea=
d to &quot;thrashing&quot; or unnecessary=C2=A0replacement of the tip?=C2=
=A0 A malicious miner who has observed the creation of a new block and inte=
nds to replace it - would have to exceed=C2=A0the work needed to generate=
=C2=A0a new block - and crucially will have less time to perform this task =
than the entire network as whole.=C2=A0 Fitness introduces a neat boundary,=
 whereby it is always cheaper to make a new block than replace the existing=
 block - which means it would take at least a 51% attack to overcome this a=
ttribute.=C2=A0 =C2=A0That being said, without this feature - less than 51%=
 is needed when you have miners that will work for you for free.=C2=A0</div=
><div><br></div><div>-Mike<br><div><br><div><br></div></div></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, S=
ep 25, 2020 at 9:33 AM Jeremy via bitcoin-dev &lt;<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">If I unders=
tand correctly, this is purely a policy level decision to accept first-seen=
 or a secondary deterministic test, but the most-work chain is still always=
 better than a &quot;more fit&quot; but less work chain.</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">In any=
 case, I&#39;m skeptical of the properties of this change. First-seen has a=
 nice property that once you receive a block, you have a substantially redu=
ced incentive to try to orphan it because the rest of the network is going =
to work on building on that block. With fitness, I have a 50% shot if I min=
e a block of mine being accepted, so floating point would have the effect o=
f destabilizing consensus convergence at the tip.</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I could see u=
sing a fitness rule like this be useful if you see both blocks within some =
very small window, e.g., 10 seconds, as it could decrease partition risk if=
 it&#39;s likely the orphan was mined within close range of the other.<br><=
/div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000008605b505b026c085--