📅 Original date posted:2022-07-11
📝 Original message:> 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.
We should carefully define "when" this becomes an issue.
Suppose the reward is 1.5625 BTC. That's not very far away. Assume you
need a 12-month investment in hardware. One-year * 100% mining capacity
at that time is thus incentivised with 82125 bitcoin in losses against a
double spend. If the price remains the same as it is now, that's 1.6
billion. Is that a sufficient security budget?
As the rewards drop, the security of Bitcoin increasingly relies on "price
increases" and "fee pressure". Obviously "price increases" isn't something
anyone should rely on. Therefore the correct thing to address is "fee
pressure".
> 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...
There is abundant evidence that modifying on-chain utility alters fees.
There is little doubt that the lightning network has cut into the security
budget. Future privacy protocols, such as mweb, will cut in even further.
Therefore another solution would be to simply *increase on-chain utility*,
driving up fees in response to the growth of layered transactions.
Proposals like "payment codes" and protocols like "omni" and "omnibolt" all
use on-chain resources without needing a soft fork. Other proposals, like
covenants, may increase fee pressure more. And, of course, promoting the
use of Bitcoin & Lightning in transactions - not just "holding", helps
promote fee growth and helps maintain the security budget.
Even if it's less fixed and predictable than tail-emissions, this approach
seems to make much more sense.
On Mon, Jul 11, 2022 at 2:19 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/c357b407/attachment-0001.html>;
Erik Aronesty [ARCHIVE] /
npub1y2…5taj0
2023-06-07 23:11:40
in reply to nevent1q…xtt9
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Published at
2023-06-07 23:11:40Event JSON
{
"id": "d87c7e5cb8711a55350ae9c7b6f177fe75a066a3ec9d14e0bed66542561cd85c",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1686179500,
"kind": 1,
"tags": [
[
"e",
"7243614b5a040fbb87601bd8f41b59830667774e947157f62a858774b716e8e6",
"",
"root"
],
[
"e",
"a3ee9355e470cf82fdc8ee17df9b4424726cc9d01a33716008f778b5944eea65",
"",
"reply"
],
[
"p",
"3c5d0ac43a0a897fa5855659ca190a7724a4794060ae096f213e63ec7d3acba7"
]
],
"content": "📅 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",
"sig": "d97179cddd332f30128540b07046cc95115ab8d105bbc525e30ffbaaf3f76b285f6a896e8e000612edb6e89fc6121473440af26b225827266bc03c7d220718e9"
}