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