rich1.0npub183ws43p6p2yhlfv92evu5xg2wuj2g72qvzhqjmep8e37clf6ewnsrl5sgyhttps://nostr.ae/npub183ws43p6p2yhlfv92evu5xg2wuj2g72qvzhqjmep8e37clf6ewnsrl5sgynjumphttps://nostr.ae📅 Original date posted:2022-07-11 📝 Original message:The expectation is that in a few years a space in the block will be very competitive / expensive and be used only as a bridge for second layers or big transactions. Who would have thought in 2017 that one day we would be worried about cheap rates! Anyway, it seems like a good point and I suggest giving this issue some name for easy and later reference. On Mon, Jul 11, 2022 at 3:20 PM Bram Cohen via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > If transaction fees came in at an even rate over time all at the exact > same level then they work fine for security, acting similarly to fixed > block rewards. Unfortunately that isn't how it works in the real world. > There's a very well established day/night cycle with fees going to zero > overnight and even longer gaps on weekends and holidays. If in the future > Bitcoin is entirely dependent on fees for security (scheduled very > strongly) and this pattern keeps up (overwhelmingly likely) then this is > going to become a serious problem. > > What's likely to happen is that at first there will simply be no or very > few blocks mined overnight. There are likely to be some, as miners at first > turn off their mining rigs completely overnight then adopt the more > sophisticated strategy of waiting until there are enough fees in the > mempool to warrant attempting to make a block and only then doing it. > Unfortunately the gaming doesn't end there. Eventually the miners with > lower costs of operation will figure out that they can collectively reorg > the last hour (or some time period) of the day overnight and this will be > profitable. That's likely to cause the miners with more expensive > operations to stop attempting mining the last hour of the day preemptively. > > What happens after that I'm not sure. There are a small enough number of > miners with a quirky enough distribution of costs of operation and > profitability that the dynamic is heavily dependent on those specifics, but > the beginnings of a slippery slope to a mining cabal which reorgs everyone > else out of existence and eventually 51% attacks the whole thing have > begun. It even gets worse than that because once there's a cabal > aggressively reorging anyone else out when they make a block other miners > will shut down and rapidly lose the ability to quickly spin up again, so > the threshold needed for that 51% attack will keep going down. > > In short, relying completely on transaction fees for security is likely to > be a disaster. What we can say from existing experience is that having > transaction fees be about 10% of rewards on average works well. It's enough > to incentivize collecting fees but not so much that it makes incentives get > all weird. 90% transaction fees is probably very bad. 50% works but runs > the risk of spikes getting too high. > > There are a few possible approaches to fixes. One would be to drag most of > east asia eastward to a later time zone thus smoothing out the day/night > cycle but that's probably unrealistic. Another would be to hard fork in > fixed rewards in perpetuity, which is slightly less unrealistic but still > extremely problematic. > > Much more actionable are measures which smooth out fees over time. Having > wallets opportunistically collect their dust during times of low > transaction fees would help and would save users on fees. Also making UX > which clarifies when things are likely to take a day or week but that it's > reliable would be a reasonable thing to do, but users unfortunately are > very averse to transactions taking a while. > _______________________________________________ > 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/20220711/9e338c0a/attachment.html>