Billy Tetrud [ARCHIVE] on Nostr: đź“… Original date posted:2022-12-30 đź“ť Original message:If the idea is to ensure ...
đź“… Original date posted:2022-12-30
đź“ť Original message:If the idea is to ensure that a catastrophic miner exodus doesn't happen,
the "difference" you're calculating should only care about downward
differences. Upward differences indicate more mining activity and so
shouldn't cause a halving skip.
But I don't think any scheme like this that only acts on the basis of
difficulty will be sufficient. If it gets to the point where a sudden drop
in mining difficulty happens, it is very likely that simply delaying the
next halving or even ending halving all together will not be sufficient to
correct for whatever is causing hashrate to tank. There is also the danger
of simple difficulty stagnation, which this mechanism wouldn't detect.
The relationship between difficulty and security becomes less and less
predictable the longer you want to look ahead. There's no long term
relation between difficulty and any reasonable security target. A security
target might be something like "no colluding group with less than $1
trillion dollars at their disposal could successfully 51% attack the
network (with a probability of blah blah)". There is no way to today
program in any code that detects based on difficult alone when that
criteria is violated. You would have to program in assumptions about the
cost of hashrate projected into the future.
I can't think of any robust automatic way to do this. I think to a certain
degree, it will have to be a change that happens in a fork of some kind
(soft or hard) periodically (every 10 years? 30 years?). The basic
relations needed is really the cost in Bitcoin of the security target (ie
the minimum number of Bitcoin it should take to 51% attack the system) and
the cost in Bitcoin of acquiring a unit of hashrate. This could be simply
input into the code, or could use some complicated oracle system. But with
that relation, the system could be programmed to calculate the difficulty
necessary to keep the system secure.
Once that is in place, the system could automatically adjust the subsidy up
or down to attract more or less miners, or it could adjust the block size
up or down to change the fee market such that more or less total fees are
collected each block to attract more or less miners.
On Tue, Dec 27, 2022, 09:41 Jaroslaw via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221230/1890b675/attachment.html>;
đź“ť Original message:If the idea is to ensure that a catastrophic miner exodus doesn't happen,
the "difference" you're calculating should only care about downward
differences. Upward differences indicate more mining activity and so
shouldn't cause a halving skip.
But I don't think any scheme like this that only acts on the basis of
difficulty will be sufficient. If it gets to the point where a sudden drop
in mining difficulty happens, it is very likely that simply delaying the
next halving or even ending halving all together will not be sufficient to
correct for whatever is causing hashrate to tank. There is also the danger
of simple difficulty stagnation, which this mechanism wouldn't detect.
The relationship between difficulty and security becomes less and less
predictable the longer you want to look ahead. There's no long term
relation between difficulty and any reasonable security target. A security
target might be something like "no colluding group with less than $1
trillion dollars at their disposal could successfully 51% attack the
network (with a probability of blah blah)". There is no way to today
program in any code that detects based on difficult alone when that
criteria is violated. You would have to program in assumptions about the
cost of hashrate projected into the future.
I can't think of any robust automatic way to do this. I think to a certain
degree, it will have to be a change that happens in a fork of some kind
(soft or hard) periodically (every 10 years? 30 years?). The basic
relations needed is really the cost in Bitcoin of the security target (ie
the minimum number of Bitcoin it should take to 51% attack the system) and
the cost in Bitcoin of acquiring a unit of hashrate. This could be simply
input into the code, or could use some complicated oracle system. But with
that relation, the system could be programmed to calculate the difficulty
necessary to keep the system secure.
Once that is in place, the system could automatically adjust the subsidy up
or down to attract more or less miners, or it could adjust the block size
up or down to change the fee market such that more or less total fees are
collected each block to attract more or less miners.
On Tue, Dec 27, 2022, 09:41 Jaroslaw via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221230/1890b675/attachment.html>;