{"type":"rich","version":"1.0","author_name":"npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","author_url":"https://nostr.ae/npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-07-11\n📝 Original message:\u003e If in the future Bitcoin is entirely dependent on fees for security\n(scheduled very strongly) and this pattern keeps up (overwhelmingly likely)\nthen this is going to become a serious problem.\n\nWe should carefully define \"when\" this becomes an issue.\n\nSuppose the reward is 1.5625 BTC.   That's not very far away.   Assume you\nneed a 12-month investment in hardware.   One-year * 100% mining capacity\nat that time is thus incentivised with 82125 bitcoin in losses against a\ndouble spend.   If the price remains the same as it is now, that's 1.6\nbillion.  Is that a sufficient security budget?\n\nAs the rewards drop, the security of Bitcoin increasingly relies on \"price\nincreases\" and \"fee pressure\".  Obviously \"price increases\" isn't something\nanyone should rely on.   Therefore the correct thing to address is \"fee\npressure\".\n\n\u003e There are a few possible approaches to fixes. One would be to drag most\nof east asia eastward to a later time zone thus smoothing out the day/night\ncycle but that's probably unrealistic. Another would be to hard fork in\nfixed rewards in perpetuity...\n\nThere is abundant evidence that modifying on-chain utility alters fees.\nThere is little doubt that the lightning network has cut into the security\nbudget.  Future privacy protocols, such as mweb, will cut in even further.\n\nTherefore another solution would be to simply *increase on-chain utility*,\ndriving up fees in response to the growth of layered transactions.\n\nProposals like \"payment codes\" and protocols like \"omni\" and \"omnibolt\" all\nuse on-chain resources without needing a soft fork.   Other proposals, like\ncovenants, may increase fee pressure more.   And, of course, promoting the\nuse of Bitcoin \u0026 Lightning in transactions - not just \"holding\", helps\npromote fee growth and helps maintain the security budget.\n\nEven if it's less fixed and predictable than tail-emissions, this approach\nseems to make much more sense.\n\n\nOn Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e If transaction fees came in at an even rate over time all at the exact\n\u003e same level then they work fine for security, acting similarly to fixed\n\u003e block rewards. Unfortunately that isn't how it works in the real world.\n\u003e There's a very well established day/night cycle with fees going to zero\n\u003e overnight and even longer gaps on weekends and holidays. If in the future\n\u003e Bitcoin is entirely dependent on fees for security (scheduled very\n\u003e strongly) and this pattern keeps up (overwhelmingly likely) then this is\n\u003e going to become a serious problem.\n\u003e\n\u003e What's likely to happen is that at first there will simply be no or very\n\u003e few blocks mined overnight. There are likely to be some, as miners at first\n\u003e turn off their mining rigs completely overnight then adopt the more\n\u003e sophisticated strategy of waiting until there are enough fees in the\n\u003e mempool to warrant attempting to make a block and only then doing it.\n\u003e Unfortunately the gaming doesn't end there. Eventually the miners with\n\u003e lower costs of operation will figure out that they can collectively reorg\n\u003e the last hour (or some time period) of the day overnight and this will be\n\u003e profitable. That's likely to cause the miners with more expensive\n\u003e operations to stop attempting mining the last hour of the day preemptively.\n\u003e\n\u003e What happens after that I'm not sure. There are a small enough number of\n\u003e miners with a quirky enough distribution of costs of operation and\n\u003e profitability that the dynamic is heavily dependent on those specifics, but\n\u003e the beginnings of a slippery slope to a mining cabal which reorgs everyone\n\u003e else out of existence and eventually 51% attacks the whole thing have\n\u003e begun. It even gets worse than that because once there's a cabal\n\u003e aggressively reorging anyone else out when they make a block other miners\n\u003e will shut down and rapidly lose the ability to quickly spin up again, so\n\u003e the threshold needed for that 51% attack will keep going down.\n\u003e\n\u003e In short, relying completely on transaction fees for security is likely to\n\u003e be a disaster. What we can say from existing experience is that having\n\u003e transaction fees be about 10% of rewards on average works well. It's enough\n\u003e to incentivize collecting fees but not so much that it makes incentives get\n\u003e all weird. 90% transaction fees is probably very bad. 50% works but runs\n\u003e the risk of spikes getting too high.\n\u003e\n\u003e There are a few possible approaches to fixes. One would be to drag most of\n\u003e east asia eastward to a later time zone thus smoothing out the day/night\n\u003e cycle but that's probably unrealistic. Another would be to hard fork in\n\u003e fixed rewards in perpetuity, which is slightly less unrealistic but still\n\u003e extremely problematic.\n\u003e\n\u003e Much more actionable are measures which smooth out fees over time. Having\n\u003e wallets opportunistically collect their dust during times of low\n\u003e transaction fees would help and would save users on fees. Also making UX\n\u003e which clarifies when things are likely to take a day or week but that it's\n\u003e reliable would be a reasonable thing to do, but users unfortunately are\n\u003e very averse to transactions taking a while.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220711/c357b407/attachment-0001.html\u003e"}