Hey Frank,


Firstly, I must commend you on two very good questions.   


The reason why I chose to maximize the value is because I approached this as an optimization problem to be solved with a genetic algorithm, and it fit with my internal model of a kind of relay race that moves forward faster. When confronted with the paradox of one side of the solution being minimized and the other being maximized I thought to myself that a paradox leading to determinism was beautiful... But it doesn't have to be this way. 


Part 2 of your question - what about the inevitable march of difficulty?  And here is where how we quantify fitness starts to matter.  Your right to point this out condition, maximizing the non-zero value means that re-org during an epoch won't optimize for having a trailing zero, which is a conflict that I see now must be avoided.


The solution is to always choose the smallest, and the summation of all contestant chains must also be minimized. This approach would then be compatible with an Epoch - so much so that it would not impeed the use of a continuous difficulty function that pegs a solution at a range of non-zero values which would avoid a discrete cliff by requiring a whole extra zero.  We need not be a victim of an early implementation - a continuous difficulty function would add stability to the network and this is worth unlocking. 


With added determinism and a continuous epoch, the network will be a lot more stable.  At this point very little is stopping us from speeding up block creation times. PoS networks are proving that conformations can be a minute or less - why not allow for a block formation time that is 6 or 12 times faster than the current target and have 1/6th (or 1/12th) of the subsidy to keep an identical inflation target.


… The really interesting part is the doors that this patch opens. Bitcoin is the best network, we have the most miners and we as developers have the opportunity to build an even better system - all with incremental soft-forks - which is so exciting.


What I am proposing is a patch that is ~100 lines of code and is fully compatible with the current Bitcoin network - because I am running a node with my changes on the network, and the more miners who adopt my patch the more lucky we will become.


Thank you everyone,

Mike



On Mon, Sep 28, 2020, 7:18 PM Franck Royer via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On Fri, 25 Sep 2020 at 22:09, Mike Brooks via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
[snip]

The solution above also has 19 prefixed zeros, and is being broadcast for the same blockheight value of 639254 - and a fitness score of 1.282.  With Nakamoto Consensus both of these solutions would be equivalent and a given node would adopt the one that it received first.  In Floating-Post Nakamoto Consensus, we compare the fitness scores and keep the highest.  In this case no matter what happens - some nodes will have to change their tip and a fitness test makes sure this happens immediately. 


Hi Mike,

Any reason why you decided to consider the higher value the "fittest" one instead of keeping in line with the difficulty algorithm where smallest values, prefixed with more zeroes, are considered more valuable/difficult?
 
Also, can you elaborate if anything special would happen if the competitive chains were created around a difficulty adjustment?

Cheers, Franck

[snip]
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev