Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 36611C0051 for ; 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 ; 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 ; 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 ; Fri, 25 Sep 2020 17:44:11 +0000 (UTC) Received: by mail-wm1-f50.google.com with SMTP id l15so2356407wmh.1 for ; 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: In-Reply-To: From: Mike Brooks Date: Fri, 25 Sep 2020 10:35:36 -0700 Message-ID: To: Jeremy , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hey Jeremy,

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.

"First seen" was easy to implement, b= ut has a few undesirable attributes.=C2=A0 =C2=A0One of the big problems is= that I don'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.

But let's dig into this topic more.=C2=A0 What would actually lea= d to "thrashing" 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

-Mike


On Fri, S= ep 25, 2020 at 9:33 AM Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org&g= t; wrote:
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 "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 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.

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's likely the orphan was mined within close range of the other.
<= /div>
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000008605b505b026c085--