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 <dave@dtrt.org> 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