rich1.0npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnnshttps://nostr.ae/npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnnsnjumphttps://nostr.ae📅 Original date posted:2023-01-02 🗒️ Summary of this message: Delaying halvings may not solve the problem of a catastrophic miner exodus. Hoarding Bitcoin is not necessarily bad, and Gresham's law does not apply. 📝 Original message:> is surely better than not delaying it. I might agree, but I don't think it really solves the problem well enough to be worth it. Any solution that would solve the problem better would make delaying halvings unnecessary. > there is non-zero risk that people will hoard it more and more, according to old Gresham's law Gresham's law doesn't apply here. Gresham's law is about the interaction between two currencies with a fixed, usually government-enforced exchange rate. You seem to be saying that Bitcoin will be hoarded because Bitcoin inflation reduces every halving. But even with 0 inflation, it certainly won't cause all Bitcoin to be hoarded. Also, "hoarding" is also known as "saving", and there's nothing wrong with saving. The spectre of deflation comes from a misunderstanding of deflation and why it happens during bad economic times. It is an effect, not a cause. On Sun, Jan 1, 2023, 15:23 <jk_14 at op.pl> wrote: > > 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.tetrud at 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 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/20230101/6da1a895/attachment.html>