Re: [bitcoin-dev] Floating-Point Nakamoto Consensus

From: Mike Brooks <m@ib•tc>
To: Jeremy <jlrubin@mit•edu>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Floating-Point Nakamoto Consensus
Date: Fri, 25 Sep 2020 10:35:36 -0700	[thread overview]
Message-ID: <CALFqKjTcTVK40XpzRR1Mre42CNURgyP1ppG4ZeTfs5a51WiesA@mail.gmail.com> (raw)
In-Reply-To: <CAD5xwhgBwC337+85vffiuEtBenqb5NDES=E7r+YsAcEtgmBHMw@mail.gmail.com>

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

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
>

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