Yes, the idea is:
if mining activity is growing - let's execute consecutive halvings
but if miner exodus has happened - let's delay next halving until mining
activity is recovered to previous levels
If it gets to the point where a sudden drop in mining difficulty happens -
delaying the next halving may be not sufficient to correct, but is surely
better than not delaying it.
While Bitcoin is better and better money with every halving in comparision to
other types of money - there is non-zero risk that people will hoard it more
and more, according to old Gresham's law ("HODL"). And this way decreasing
liquidity / transactions volume. The positive feedback loop - is my real
concern here.
Regarding the relationship between difficulty and security - I fully agree.
But ASIC technology is already matured. And also any technology breakthrough is
a short event within 4 years period.
So growth of difficulty could be gained by technology breakthrough, but any
sudden drop of difficulty would be always an issue, while there is no such
thing as: ASIC technology regression.
Obviously, not complicated solution would be better than complicated one.
W dniu 2022-12-30 19:21:10 użytkownik Billy Tetrud <billy.tet...@gmail.com>
napisał:
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@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@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_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
