It seems like the more elegant solution could be by using a chainwork parameter 
instead.
i.e. comparison just before halving - if the last 210,000 block interval has a 
higher chainwork difference between the begining and the end of interval
than any other such inter-halving interval before.

LIttle digression yet:
A system in which all users participate in ensuring its security looks better 
than one in which only some (i.e. active) of them participate (and passive 
stakeholders are de facto free riders)
In my opinion this concept above is only the complement of currently missing 
mechanism: achieving equilibrium regarding costs of security between two 
parties with opposing interests.
It's easy to understand and - most important - it has no hardcoded value of 
tail emission - what is the clear proof it is based on a free market.
And last but not least, if someone is 100% sure that income from transactions 
will takeover security support from block subsidy - accepting such proposal is 
like putting the money where the mouth is: this safety measure will never be 
triggered, then (no risk of fork)


Best Regards
Jaroslaw



W dniu 2022-12-23 20:29:20 użytkownik Jaroslaw via bitcoin-dev 
<bitcoin-dev@lists.linuxfoundation.org> napisał:
> 
Necessary or not - it doesn't hurt to plan the robust model, just in case. The 
proposal is:

Let every 210,000 the code calculate the average difficulty of 100 last 
retargets (100 fit well in 210,000 / 2016 = 104.166)
and compare with the maximum of all such values calculated before, every 
210,000 blocks:


if average_diff_of_last_100_retargets > maximum_of_all_previous_average_diffs
        do halving
else
        do nothing


This way:

1. system cannot be played
2. only in case of destructive halving: system waits for the recovery of 
network security


Best Regards
Jaroslaw
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



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

Reply via email to