{"type":"rich","version":"1.0","author_name":"npub1dalwmzu6f0yqdl0cy8qeaa6zcrzkara3jh8jjv7zky5s0tuypatsu07r9n","author_url":"https://nostr.ae/npub1dalwmzu6f0yqdl0cy8qeaa6zcrzkara3jh8jjv7zky5s0tuypatsu07r9n","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-01-01\n🗒️ Summary of this message: A proposal for a halving system based on average difficulty is suggested, but it does not address the immediate danger of profit margins and hashing power. A demurrage soft-fork may be a more plausible solution.\n📝 Original message:Is a storage fee averaged out over many future blocks - but not hardcoded value and regulated by a free market?\n\n\nThe problem with demurrage I see is that the fee is taken when you spend. There is no additional income for miners if people are still hoarding.\nIn tail emission even if people are still hoarding - the fee is taken immediately and is distributed to miners.\n\nWe have a hope there is still the global adoption ahead (most of countries are like El Salvador). It may increase price and marketcap of Bitcoin by order of magnitude.\nAnd that's why hoarding in demurrage may still exist: due to extremely appealing long-term risk/reward (i.e. relatively small, delayed tax versus huge possible profit)\n\n\n\n\nW dniu 2022-12-31 00:29:08 użytkownik Peter Todd \u003cpete at petertodd.org\u003e napisał:\n\u003e On Fri, Dec 23, 2022 at 07:43:36PM +0100, jk_14 at op.pl wrote:\n\u003e \n\u003e Necessary or not - it doesn't hurt to plan the robust model, just in case. The proposal is:\n\u003e \n\u003e Let every 210,000 the code calculate the average difficulty of 100 last retargets (100 fit well in 210,000 / 2016 = 104.166)\n\u003e and compare with the maximum of all such values calculated before, every 210,000 blocks:\n\u003e \n\u003e \n\u003e if average_diff_of_last_100_retargets \u003e maximum_of_all_previous_average_diffs\n\u003e \tdo halving\n\u003e else\n\u003e \tdo nothing\n\u003e \n\u003e \n\u003e This way:\n\u003e \n\u003e 1. system cannot be played\n\u003e 2. only in case of destructive halving: system waits for the recovery of network security\n\nFirst of all - while I suspct you already understand this issue - I should\npoint out the following:\n\nThe immediate danger we have with halvings is that in a competitive market,\nprofit margins tend towards marginal costs - the cost to produce an additional\nunit of production - rather than total costs - the cost necessary to recover\nprior and future expenses. Since the halving is a sudden shock to the system,\nunder the right conditions we could have a significant amount of hashing power\njust barely able to afford to hash prior to the halving, resulting in all that\nhashing power immediately having to shut down and fees increasing dramatically,\nand likely, chaotically.  Your proposal does not address that problem as it can\nonly measure difficulty prior to the halving point.\n\n\nOther than that problem, I agree that this proposal would, at least in theory,\nbe a positive improvement on the status quo. But it is a hard fork and I don't\nthink there is much hope for such hard forks to be implemented. I believe that\na demmurrage soft-fork, implemented via a storage fee averaged out over many\nfuture blocks, has a much more plausible route towards implementation.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org"}