Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
I very much agree with AJ here. This is something I remember discussing on Bitcointalk back in 2011: I find it highly intuitive that the amount of lost coins is not a constant fraction of the supply, because people get better at keeping their coins with increasing value, distribution and technology/best practices. I also think that we have observed this effect in practice since then. The bulk of coins that are supposed to be lost (via onchain analysis) haven't been moved since at least 2010. Of course, in most cases, we'll never know, but the assumption of constant loss rate seems unreasonable. Cheers Stefan Anthony Towns via bitcoin-dev schrieb am Mo., 11. Juli 2022, 04:32: > On Sat, Jul 09, 2022 at 08:46:47AM -0400, Peter Todd via bitcoin-dev wrote: > > title: "Surprisingly, Tail Emission Is Not Inflationary" > > > Of course, this isn't realistic as coins are constantly being lost due to > > deaths, forgotten passphrases, boating accidents, etc. These losses are > > independent: > > This isn't necessarily true: if the losses are due to a common cause, > then they'll be heavily correlated rather than independent; for example > losses could be caused by a bug in a popular wallet/exchange software > that sends funds to invalid addresses, or by a war or natural disaster > that damages key storage hardware. They're also not independent over > time -- people improve their key storage habits over time; eg switching > to less buggy wallets/exchanges, validating addresses before using them, > using distributed multisig to prevent a localised disaster from being > catastrophic. > > > the *rate* of coin loss at time $$t$$ is > > proportional to the total supply *at that moment* in time. > > This is the key assumption that produces the claimed result. > > If you're losing a constant fraction, x (Peter's \lambda), of Bitcoins > each year, then as soon as the supply increases enough that the constant > reward, k, corresponds to the constant fraction, ie k = x*N(t), then > you've hit an equilibrium. (Likewise if you're losing more than you're > increasing -- you just need to wait until N(t) decreases enough that you > reach the same equilibrium point) You don't really need any fancy maths. > > But that assumption doesn't need to be true; coins could primarily be > lost in "black swan" events (due to bugs, wars or disasters) rather > than at a predictable rate -- with actions taken thereafter such that > the same event repeating is no longer the same level of catastrophe, > but instead another new black swan event is required to maintain the same > loss rate. If that's the case, then the rate at which funds are lost will > vary chaotically, leading to "inflationary" periods in between events, > and comparatively strong deflationary shocks when these events occur. > > Alternatively, losses could be at a predictable rate that's entirely > different to the one Peter assumes. > > One alternative predictable rate that seems plausible to me is if funds > are lost due to people not be careful about losing small amounts; even > though they are careful when amounts are larger. So when 10k BTC was > worth $40, maybe it doesn't matter if you misplace a hard drive with > 7500 BTC on it since that's only worth $30; but by the time 7500 BTC > is worth $150M, maybe you take a bit more care with that, but are still > not too worried if you lose 1.5mBTC, since that's also only worth $30. > > To mathematise that, perhaps there are K people holding Bitcoin, and with > probability p, each loses $100 (in constant 2009 dollars say, so that we > can ignore inflation) of that Bitcoin a year through carelessness. For > an equilibrium to occur in that case, you need: > > N(t) + k - (100/P * Kp) = N(t) > > where P is the price of Bitcoin (again in constant 2009 dollars) and k > is Peter's fixed tail subsidy. Simplifying gives: > > P = K * 100p/k > > But k and p are constant by assumption in this scenario, so equilibrium > is reached only if price (P) is exactly proportional to number of > users (K). That requires you to have a non-inflationary currency > (supply is constant) with constant adoption (assume K doesn't change) > that maintains a constant price (P=K*100p/k) in real terms even if the > economy is otherwise expanding or contracting. > > More importantly, just from a goals point of view, x is something we > should be finding ways to minimise it over time, not leave constant. > In fact, you could argue for an even stronger goal: "the real value held > in BTC lost each year should decrease", that is, x should be decreasing > faster than 1/(N(t)*P). > > Cheers, > aj > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
On Mon, Jul 11, 2022 at 2:19 PM Bram Cohen via bitcoin-dev < bitcoin-dev@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. > Miners will learn to create anyone-can-spend outputs to bribe other miners to build on their block rather than reorg it. (Due to the coinbase maturity, this will require some amount of floating capital.) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
On Mon, Jul 11, 2022 at 10:00 AM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > If you actually do the numbers on this, you'll realize it takes absolutely > catastrophic black swan events that make WW2 look like a minor conflict to > make > even insignificant inflation rate changes due to changes in lost coins. > That somewhat depends on what you mean by 'significant' and 'catastrophic' but I believe the way the model goes is that if X% of coins are lost that means that the value of all outstanding coins will go up by X%, and if the rate of breakage goes from Y% annually to Y*Z% annually then the value of all coins will go up by a factor of Z. This is of course an idealized model in steady state, but gives some idea of scale. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
I believe it's foolish to attempt objective definitions of things that we
define collectively, like "Bitcoin." The best any one of us can do is to
be consistent with a subjective personal definition. I believe most people
do that with the term "Bitcoin" and that the capped supply is intrinsic to
their subjective definitions. It is to mine. Leading bodies, such as the
Bitcoin core team, the Ethereum foundation, and every government, are
constantly in danger of confusing objective reality with their own
decisions. Since people have autonomy, the best a leading body can do is
recommend their decisions. The common error is one made by governments,
where they react violently to defiance of the definitions they make.
Shadows of that error show up in nongovernmental leading bodies as
ostracism, criticism, and even sometimes illegal activity against such
defiance of decisions. What I mean here is that John is right in a sense
(" removing this limit results in something that can no longer be called
Bitcoin. "), but I don't think the way he expressed it is as helpful as it
could be. There are many who will not call it Bitcoin, and I am among them.
On Sat, Jul 9, 2022 at 8:13 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sat, Jul 09, 2022 at 04:57:57PM +0200, John Tromp via bitcoin-dev wrote:
> > > New blog post:
> > >
> https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
> >
> > A Tail Emission is best described as disinflationary; the yearly
> > supply inflation steadily decreases toward zero.
>
> _Apparently_ inflation. True monetary inflation includes lost coins - both
> intentionally and accidentally lost. It's quite possible that even with
> tail
> emission Monero is currently a monetarily deflationary coin, as the lost
> coin
> rate might be higher than the 0.8% apparent tail emission rate.
>
> We just don't know. Doubly so in the case of monero where its privacy
> features
> hide coin activity.
>
> > > If an existing coin decides to implement tail emission as a means to
> fund security, choosing an appropriate emission rate is simple: decide on
> the maximum amount of inflation you are willing to have in the worst case,
> and set the tail emission accordingly.
> >
> > Any coin without a premine starts with infinite inflation. Bitcoin in
> > its first 4 years had yearly inflation rates of inf, 100%, 50%, and
> > 33%. So deciding on a maximum amount of inflation is deciding on a
> > premine.
>
> Hence why I specified an *existing* coin.
>
> > While in the long term, a capped supply doesn't meaningfully differ
> > from un uncapped supply [1], the 21M limit is central to Bitcoin's
> > identity, and removing this limit results in something that can no
> > longer be called Bitcoin.
>
> Personally I think basing your identity on a technical point that isn't
> even
> correct is stupid. And I suspect than when push comes to shove, if in ~10
> years
> or whatever Bitcoin turns out to be unstable without a reward, the market
> as a
> whole will be happy to redefine Bitcoin to remove the 21M limit. Whether
> or not
> it can do that fast enough to avoid Bitcoin dying first is an open
> question.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I own Litmocracy and Meme Racing
(in alpha).
I'm the webmaster for The Voluntaryist which
now accepts Bitcoin.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Security problems with relying on transaction fees for security
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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] No Order Mnemonic
Sorry, I totally forgot the checksum. You can take my ops-per-second and multiply it by about 16 (because of the 4 check bits), making a delete + two swaps or 4 swaps, etc. still pretty reasonable. On Mon, Jul 11, 2022 at 9:11 AM Erik Aronesty wrote: > 1. You can swap two positions, and then your recovery algorithm can > brute-force the result by trying all 132 possible swaps. > 2. You can make a single deletion and only have to brute 2048 > 3. You can keep doing these, being aware that it becomes geometrically > more difficult each time (deletion + swap = 270k ops) > 4. A home PC can make 20k secpk256 operations per second per core, so try > to keep your number under a few million ops and it's still a decent UX > (under a minute) > > > On Sat, Jul 9, 2022 at 8:01 PM Anton Shevchenko via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I would say removing ordering from 12-word seed reduces 25 bits of >> entropy, not 29. Additional 4 bits come from checksum (12 words encode 132 >> bits, not 128). >> >> My idea [for developing this project] was to feed its output to some kind >> of AI story generator (GPT-3 based?) so a user can remember a story, not >> ordered words. But as others pointed out, having 12 words without order is >> probably good enough. So at this point there's not much sense of using the >> proposed encoding. Unless a remembered story has wholes/errors. In this >> case recovering few words would be easier with unordered encoding. Any >> thoughts? >> >> -- Anton Shevchenko >> >> >> On Sat, Jul 9, 2022, at 1:31 PM, Zac Greenwood via bitcoin-dev wrote: >> >> Sorting a seed alphabetically reduces entropy by ~29 bits. >> >> A 12-word seed has (12, 12) permutations or 479 million, which is >> ln(469m) / ln(2) ~= 29 bits of entropy. Sorting removes this entropy >> entirely, reducing the seed entropy from 128 to 99 bits. >> >> Zac >> >> >> On Fri, 8 Jul 2022 at 16:09, James MacWhyte via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> >> What do you do if the "first" word (of 12), happens to be the last word >> in the list alphabetically? >> >> >> That couldn't happen. If one word is the very last from the wordlist, it >> would end up at the end of your mnemonic once you rearrange your 12 words >> alphabetically. >> >> However! >> >> (@vjudeu) Choosing 11 random words and then sorting them alphabetically >> before assigning a checksum would reduce entropy considerably. If you think >> about it, to bruteforce the entire keyspace one would only need to come up >> with every possible combination of 11 words + 1 checksum. I'm not the best >> at napkin math, but I think that leaves you with around 10 trillion >> combinations, which would only take a couple months to exhaust with >> hardware that can do 1 million guesses per second. >> >> >> James >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
>
>
> Alternatively, losses could be at a predictable rate that's entirely
> different to the one Peter assumes.
>
No, peter only assumes that there *is* a rate.
Regardless of what the rate is, if it is any value for which there exists
*any fixed central tendency*, tail emission is *evenually* non inflationary.
But you are correct about the other two things:
1. If people are improving custody faster than 1/(N(t)*P) than tail
emission can still be inflationary. This seems far-fetched, imo.
2. The rate will be somewhat stochastic ("black swan envets"). Plausible
(popular wallet loses keys in coding error), but also... "true no matter
what". And not really relevant to tail-emission being non-inflationary.
Over a long enough time period, even these events can be factored into a
fixed central tendency. Even if it's 100 years, etc.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] No Order Mnemonic
1. You can swap two positions, and then your recovery algorithm can brute-force the result by trying all 132 possible swaps. 2. You can make a single deletion and only have to brute 2048 3. You can keep doing these, being aware that it becomes geometrically more difficult each time (deletion + swap = 270k ops) 4. A home PC can make 20k secpk256 operations per second per core, so try to keep your number under a few million ops and it's still a decent UX (under a minute) On Sat, Jul 9, 2022 at 8:01 PM Anton Shevchenko via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I would say removing ordering from 12-word seed reduces 25 bits of > entropy, not 29. Additional 4 bits come from checksum (12 words encode 132 > bits, not 128). > > My idea [for developing this project] was to feed its output to some kind > of AI story generator (GPT-3 based?) so a user can remember a story, not > ordered words. But as others pointed out, having 12 words without order is > probably good enough. So at this point there's not much sense of using the > proposed encoding. Unless a remembered story has wholes/errors. In this > case recovering few words would be easier with unordered encoding. Any > thoughts? > > -- Anton Shevchenko > > > On Sat, Jul 9, 2022, at 1:31 PM, Zac Greenwood via bitcoin-dev wrote: > > Sorting a seed alphabetically reduces entropy by ~29 bits. > > A 12-word seed has (12, 12) permutations or 479 million, which is ln(469m) > / ln(2) ~= 29 bits of entropy. Sorting removes this entropy entirely, > reducing the seed entropy from 128 to 99 bits. > > Zac > > > On Fri, 8 Jul 2022 at 16:09, James MacWhyte via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > What do you do if the "first" word (of 12), happens to be the last word in > the list alphabetically? > > > That couldn't happen. If one word is the very last from the wordlist, it > would end up at the end of your mnemonic once you rearrange your 12 words > alphabetically. > > However! > > (@vjudeu) Choosing 11 random words and then sorting them alphabetically > before assigning a checksum would reduce entropy considerably. If you think > about it, to bruteforce the entire keyspace one would only need to come up > with every possible combination of 11 words + 1 checksum. I'm not the best > at napkin math, but I think that leaves you with around 10 trillion > combinations, which would only take a couple months to exhaust with > hardware that can do 1 million guesses per second. > > > James > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP proposal] Private Payments
Update: Bob doesn't have to watch all address types he's advertising. When notifying Bob, Alice will pick one address type out of the ones Bob is advertising and include it in the notification. That way even if Bob's wallet accepts many address types, he still doesn't have to watch all of them for each Alice. The previous spec reads: > Alice then constructs a 72-byte OP_RETURN output whose value is set to > `BIP + notification + N_Alice` (`+` is concat) and sends it in a > transaction containing no other outputs ( to be replaced once a BIP > number is assigned). We can extended the payload to 73 bytes and define it as: `BIP + notification + N_Alice + address_type`, where `address_type` is a single byte containing the desired address type index (1 out of 16, limited by Bob's payment code). If Alice ever wants to start sending to a different address type, she can simply re-notify Bob and Bob will switch to a new address type in the case of Alice. Alfred ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
I think the discussion has some anecdotic interest but has zero relevance as far as any decision making is concerned. Any extension of block rewards after the current deadline should only be done if and only if the community agrees that it is the only way to keep the network secure. The fact that a mild inflation is sometimes compensated by coin loss is like a bonus. On Mon, Jul 11, 2022, 11:56 AM Stefan Richter via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I very much agree with AJ here. This is something I remember discussing on > Bitcointalk back in 2011: I find it highly intuitive that the amount of > lost coins is not a constant fraction of the supply, because people get > better at keeping their coins with increasing value, distribution and > technology/best practices. I also think that we have observed this effect > in practice since then. The bulk of coins that are supposed to be lost (via > onchain analysis) haven't been moved since at least 2010. Of course, in > most cases, we'll never know, but the assumption of constant loss rate > seems unreasonable. > > Cheers > Stefan > > Anthony Towns via bitcoin-dev > schrieb am Mo., 11. Juli 2022, 04:32: > >> On Sat, Jul 09, 2022 at 08:46:47AM -0400, Peter Todd via bitcoin-dev >> wrote: >> > title: "Surprisingly, Tail Emission Is Not Inflationary" >> >> > Of course, this isn't realistic as coins are constantly being lost due >> to >> > deaths, forgotten passphrases, boating accidents, etc. These losses are >> > independent: >> >> This isn't necessarily true: if the losses are due to a common cause, >> then they'll be heavily correlated rather than independent; for example >> losses could be caused by a bug in a popular wallet/exchange software >> that sends funds to invalid addresses, or by a war or natural disaster >> that damages key storage hardware. They're also not independent over >> time -- people improve their key storage habits over time; eg switching >> to less buggy wallets/exchanges, validating addresses before using them, >> using distributed multisig to prevent a localised disaster from being >> catastrophic. >> >> > the *rate* of coin loss at time $$t$$ is >> > proportional to the total supply *at that moment* in time. >> >> This is the key assumption that produces the claimed result. >> >> If you're losing a constant fraction, x (Peter's \lambda), of Bitcoins >> each year, then as soon as the supply increases enough that the constant >> reward, k, corresponds to the constant fraction, ie k = x*N(t), then >> you've hit an equilibrium. (Likewise if you're losing more than you're >> increasing -- you just need to wait until N(t) decreases enough that you >> reach the same equilibrium point) You don't really need any fancy maths. >> >> But that assumption doesn't need to be true; coins could primarily be >> lost in "black swan" events (due to bugs, wars or disasters) rather >> than at a predictable rate -- with actions taken thereafter such that >> the same event repeating is no longer the same level of catastrophe, >> but instead another new black swan event is required to maintain the same >> loss rate. If that's the case, then the rate at which funds are lost will >> vary chaotically, leading to "inflationary" periods in between events, >> and comparatively strong deflationary shocks when these events occur. >> >> Alternatively, losses could be at a predictable rate that's entirely >> different to the one Peter assumes. >> >> One alternative predictable rate that seems plausible to me is if funds >> are lost due to people not be careful about losing small amounts; even >> though they are careful when amounts are larger. So when 10k BTC was >> worth $40, maybe it doesn't matter if you misplace a hard drive with >> 7500 BTC on it since that's only worth $30; but by the time 7500 BTC >> is worth $150M, maybe you take a bit more care with that, but are still >> not too worried if you lose 1.5mBTC, since that's also only worth $30. >> >> To mathematise that, perhaps there are K people holding Bitcoin, and with >> probability p, each loses $100 (in constant 2009 dollars say, so that we >> can ignore inflation) of that Bitcoin a year through carelessness. For >> an equilibrium to occur in that case, you need: >> >> N(t) + k - (100/P * Kp) = N(t) >> >> where P is the price of Bitcoin (again in constant 2009 dollars) and k >> is Peter's fixed tail subsidy. Simplifying gives: >> >> P = K * 100p/k >> >> But k and p are constant by assumption in this scenario, so equilibrium >> is reached only if price (P) is exactly proportional to number of >> users (K). That requires you to have a non-inflationary currency >> (supply is constant) with constant adoption (assume K doesn't change) >> that maintains a constant price (P=K*100p/k) in real terms even if the >> economy is otherwise expanding or contracting. >> >> More importantly, just from a goals point of view, x is something we >> should be finding ways to minimise it
Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
On Mon, Jul 11, 2022 at 12:32:47PM +1000, Anthony Towns wrote: > This isn't necessarily true: if the losses are due to a common cause, > then they'll be heavily correlated rather than independent; for example > losses could be caused by a bug in a popular wallet/exchange software > that sends funds to invalid addresses, or by a war or natural disaster > that damages key storage hardware. They're also not independent over > time -- people improve their key storage habits over time; eg switching > to less buggy wallets/exchanges, validating addresses before using them, > using distributed multisig to prevent a localised disaster from being > catastrophic. People clearly continue to make downright irrational decisions about coin security, doing things putting their entire crypto savings at risk for claimed 5% returns. Even if people were rational, the coin loss rate would clearly reach a floor because as the probability of coin loss goes down, bothering to spend extra effort to decrease that already small chance is pointless. You mentioning black swan events actually strengthens my point: at low coin loss rates the true loss rate is dominated by black swan events. So it's pointless to go to extra effort to prevent them. Finally, you're forgetting that coin loss also includes *intentional* losses from proof-of-sacrifice protocols. There are a number of examples on Bitcoin. Again, they put a floor on how much coin loss could diminish. > loss rate. If that's the case, then the rate at which funds are lost will > vary chaotically, leading to "inflationary" periods in between events, > and comparatively strong deflationary shocks when these events occur. Give me an example of an *actual* inflation rate you expect to see, given a disaster of a given magnitude. If you actually do the numbers on this, you'll realize it takes absolutely catastrophic black swan events that make WW2 look like a minor conflict to make even insignificant inflation rate changes due to changes in lost coins. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
On Mon, Jul 11, 2022 at 05:36:52PM -0400, Peter Todd via bitcoin-dev wrote: > On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via bitcoin-dev > wrote: > > > What happens after that I'm not sure. > > > > > > > Miners will learn to create anyone-can-spend outputs to bribe other miners > > to build on their block rather than reorg it. (Due to the coinbase > > maturity, this will require some amount of floating capital.) > > ...and that's a disaster for mining centralization, because the smaller miners > need to pay larger bribes than larger miners. Not to mention having to keep > capital around to do it. Also, note how from a practical point of view, we'll need to add a new type of tx that's only valid in a specific block, or other miners will just reorg those anyone-can-spend outputs to steal them. It's not all that trivial to actually do that... you'd have to have a signature that commits to the non-segwit part of the coinbase outputs. Ugh. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
On Tue, Jul 12, 2022 at 02:01:09AM +0200, James MacWhyte wrote: > On Tue, Jul 12, 2022 at 12:26 AM Peter Todd wrote: > > > Anyway, designing protocols for "price go up forever" hopium is a bad idea. > > > > I'm quite disappointed that this is what you've reduced my argument to. The > price doesn't need hopium; if it stays between where it is now and the all > time high, that is enough to make mining rewards appealing. > > Anyway, once the LA dinner rush ends at 8PM it is already noon in Tokyo. > The Pacific is big, but not *that* big. > > Certainly we should be designing protocols in anticipation of increased > adoption, and not assuming the world will always be exactly as it is today? We should design protocols that do reasonably well in *both* scenarios. Because the future is unknown. Hell, I won't be surprised if further developments come along that reduce demand for on-chain txs even further. The fact is basing security budget in part on the total value of the coin being secured very cleanly solves the problem of ensuring that there is sufficient mining reward. Similarly, we also have to plan for the potential environment where fee demand is very high. And we've done a good job of that, including Lightning, replace-by-fee, etc. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via bitcoin-dev wrote: > > What happens after that I'm not sure. > > > > Miners will learn to create anyone-can-spend outputs to bribe other miners > to build on their block rather than reorg it. (Due to the coinbase > maturity, this will require some amount of floating capital.) ...and that's a disaster for mining centralization, because the smaller miners need to pay larger bribes than larger miners. Not to mention having to keep capital around to do it. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
On Mon, Jul 11, 2022 at 11:12:52AM -0700, Bram Cohen via bitcoin-dev 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. Note that a tricky thing here is that smoothing out fees is made difficult by the fact that users can by-pass the fee system by including anyone-can-spend outputs in their transactions. Or worse, by simply paying large miners out-of-band to get their txs confirmed. So any smothing scheme that tries to smooth the market-based fees we already have will fail. The only type of fee-smoothing scheme that is feasible is to smooth an entirely separate category of fees that are made mandatory. For example, you could achieve the economic impact of inflation by having a fixed value*time based fee that goes to timelocked anyone-can-spend outputs in the coinbase to push the fee forward to other miners. Doing this is of course a gigantic accounting headache, and problematic for existing L2 protocols, because you are reducing the value of txouts as they age (demurrage). But at least it's a soft-fork. Interestingly, if you look at transaction fees in blocks right now, people regularly pay far higher transaction fees than necessary. There seem to be a bunch of high value users, eg $1 million txs, without terrible fee estimation. And I suspect the reason why this happens is simply that for a $1 million tx, overpaying 100x with a $100 tx fee is irrelevant. Of course, this is also a problem from the re-org point of view... > Having > wallets opportunistically collect their dust during times of low > transaction fees would help and would save users on fees. You're assuming wallets will even have dust to collect. With widespread use of Lightning that will likely not be true. Indeed, with sufficiently efficient L2 solutions it's really unclear as to how much demand there will be for block space. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
On Tue, Jul 12, 2022 at 12:19:06AM +0200, James MacWhyte via bitcoin-dev wrote: > I think many of these discussions about the loss of the mining reward are > fatally shortsighted. > > It's always daytime somewhere--when you talk about volume dropping at > night, that simply means there is not enough activity outside the US. If > Bitcoin continues its rise in price, mining rewards will still be > substantial for decades to come. Given another 10 years, I'm fairly > confident there will be enough adoption worldwide to make mining profitable > around the clock, even if the mining reward were minimal. Earth's population is extremely uneven over the earths surface, and the pacific ocean is enormous and sparsely populated: https://earthsky.org/earth/99-percent-worlds-population-receive-sunlight/ Anyway, designing protocols for "price go up forever" hopium is a bad idea. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
> 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@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
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
This problem can be solved by mining decentralization. > What's likely to happen is that at first there will simply be no or very few > blocks mined overnight. Why? When it comes to energy usage, there are also cycles, because energy usage during the day is definitely higher than at night. You can clearly see that there are different prices for energy usage, and it depends if you use that energy overnight or not (usually, energy at night is cheaper, in the same way as other resources like Internet bandwidth limits, which are lower at night). If less energy is used at night, then that energy is cheaper, and that means mining at night is more profitable. > 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. Again, that's the problem that should be solved by decentralized mining. Each reward of each miner should depend on all fees collected by that miner. It is easier to think about it if you assume zero basic block reward, where the whole coinbase transaction is based only on transaction fees. So, all that is needed, is to make it possible to get some transaction fees, related to mined transactions. So, it is far better to think about some kind of commit-and-reveal scheme, where each miner will independently mine a share of the block, and commit the block header on-chain. Then, it will be later possible to prove that such share was created at a given point in time, and to claim some reward (even off-chain), based on that proof. > 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 would mean on-chain transaction fees are very low. And that would mean off-chain transaction fees are higher (because if that's not the case, then it would mean that people stopped making any transactions at all, on all monetary systems globally, including all altcoins, and all fiat currencies). So, that case is possible in a situation, where Lightning Network will handle the most of the traffic, and where there will be almost no need to touch on-chain coins, because all of them will fly inside other networks like LN, sidechains, or Merge-Mined altcoins. > In short, relying completely on transaction fees for security is likely to be > a disaster. Note that if you want to rely on something else than fees, then you have three options: big blocks, tail supply, or Merged Mining. Big blocks were discussed heavily in the past, tail supply is discussed now, and Merged Mining is still not touched correctly (to get it right, it is needed to track the heaviest chain of Proof of Work headers, and to distribute a fractions of coins, based on that, not like NameCoin, where you have a separate difficulty, so you can 51% attack NameCoin, even if you don't have 51% on Bitcoin). So, why not Merged Mining? Or what else could it be? And if it will be tail supply, then why hard-fork is needed at all? Make it explicitly, take single satoshis from all UTXOs in existence, and make it crystal clear, what this proposal is about: it is about taking a tiny fractions of satoshis or even smaller amounts from all UTXOs to form the future block rewards, that's what it is truly about, and users should be aware of that. > 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. What is unrealistic? Trustless mining on someone's behalf and being rewarded for doing that in P2P way is unrealistic? It is perfectly possible to deploy any "I will pay you for increasing block reward for block 100" scheme. We have OP_CHECKLOCKTIMEVERIFY for that, anyone can do that, even non-mining users can send their own coins to the future block numbers to increase future rewards with their own coins. > Another would be to hard fork in fixed rewards in perpetuity, which is > slightly less unrealistic but still extremely problematic. No hard-fork is needed. Moving coins to OP_CHECKLOCKTIMEVERIFY outputs is a no-fork. Enforcing that on consensus level to make block rewards more smooth is a soft-fork. Creating a Merge-Mined sidechain for that is a no-fork (because new coins are produced out of thin air, so Proof of Work alone, and tracking the main chain is enough, no new rules are needed on the main chain). > Much more actionable are measures which smooth out fees over time. What about RSK and their way of making fees more smooth? On 2022-07-11 20:19:51 user Bram Cohen via bitcoin-dev 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
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
> > Miners will learn to create anyone-can-spend outputs to bribe other miners > to build on their block rather than reorg it. (Due to the coinbase > maturity, this will require some amount of floating capital.) > (reward + avg fee) * 144 * 365 (one year) == approximate investment needed to reorg the chain for a double-spend attack in 30 years, assuming fees are still negligible (why wouldn't they be? layer 2 works and layer 3 is coming), that's only 1200 bitcoin. not really a lot. there's only few things that allow that security budget to be ok - we assume the price goes up a lot - we assume transactions get a lot more expensive - we don't care about double-spend attacks for very large transactions i'd rather engineer block demand than ignore it ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
On Mon, Jul 11, 2022 at 08:21:40PM -0400, Russell O'Connor via bitcoin-dev wrote: > Oops, you are right. We need the bribe to be the output of the coinbase, > but due to the maturity rule, it isn't really a bribe. > > Too bad coinbases cannot take other coinbase outputs as inputs to bypass > the maturity rule. > > I guess that means the bribe has to be by leaving transactions in the > mempool. ...and that's hardly a bribe. That's just being unable to mine competitively because your operation is too small. Anyway, I think all this is a good example of how mining being dependent on fee-income makes mining much more complex, and harder to do as a small player. Not good. > Also your point about centralization pressure is well taken. Thanks -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
On 11 Jul 2022, at 19:12, Bram Cohen via bitcoin-dev wrote: > 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. This may be true today when adoption is still low but will likely change if/when Bitcoin drives the world economy and is used 24/7 globally. There's a good chance our grandchildren will never see an empty mempool. signature.asc Description: Message signed with OpenPGP ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
On Tue, Jul 12, 2022 at 12:26 AM Peter Todd wrote: > Anyway, designing protocols for "price go up forever" hopium is a bad idea. > I'm quite disappointed that this is what you've reduced my argument to. The price doesn't need hopium; if it stays between where it is now and the all time high, that is enough to make mining rewards appealing. Anyway, once the LA dinner rush ends at 8PM it is already noon in Tokyo. The Pacific is big, but not *that* big. Certainly we should be designing protocols in anticipation of increased adoption, and not assuming the world will always be exactly as it is today? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
I think many of these discussions about the loss of the mining reward are fatally shortsighted. It's always daytime somewhere--when you talk about volume dropping at night, that simply means there is not enough activity outside the US. If Bitcoin continues its rise in price, mining rewards will still be substantial for decades to come. Given another 10 years, I'm fairly confident there will be enough adoption worldwide to make mining profitable around the clock, even if the mining reward were minimal. James On Mon, Jul 11, 2022 at 8:19 PM Bram Cohen via bitcoin-dev < bitcoin-dev@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
On Sun, Jul 10, 2022 at 3:05 AM vjudeu via bitcoin-dev wrote: > > Not really, because people that run full nodes, just accepted Segwit > and Taproot. They had no choice. And in case of zero satoshis, it could > be the same: you would see zero if you look at raw bytes, but you will > see non-zero values, if you use some upgraded client, that will support > amount hiding, or other features. > > Segwit: old nodes see no new signatures, new nodes see all signatures > Zero satoshis: old nodes see new zero amounts, new nodes see all amounts > > It is that simple. I see what you mean, have the P2P messages depend on whether the peer is running old code (doesn't know about tail emission) or new code (does know about it). I don't think this can work in this case. It worked for Segwit because the P2P differences involved only signatures (which determine whether the transaction is valid), not the *effect* of the transaction, that is, how it changes the UTXO set. Consensus requires all nodes to always agree on the UTXO set. Larry Ruane ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
On Mon, Jul 11, 2022 at 11:12:52AM -0700, Bram Cohen via bitcoin-dev 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. That just becomes a market design question. There's been some trivial effort put into that for bitcoin (ie, getting people to actually chooses fees based on the weight of their transaction, and having weight be the sole limiting factor for miners), but not a lot, and there's evidence both from previous times in Bitcoin's history and from altcoin's that the market can support higher fees. Should we work on that today, though? It doesn't seem smart to me: the subsidy is already quite substantial ($6.5 billion USD per year at current prices) so raising fees to 10% of block reward would transfer another $650M USD from bitcoin users to miners (or ASIC manfucturers and electricity producers) each year, achieving what? Refuting some FUD? Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary
On Mon, Jul 11, 2022 at 08:56:04AM -0400, Erik Aronesty via bitcoin-dev wrote: > > Alternatively, losses could be at a predictable rate that's entirely > > different to the one Peter assumes. > No, peter only assumes that there *is* a rate. No, he assumes it's a constant rate. His integration step gives a different result if lambda changes with t: https://www.wolframalpha.com/input?i=dN%2Fdt+%3D+k+-+lambda%28t%29*N On Mon, Jul 11, 2022 at 12:59:53PM -0400, Peter Todd via bitcoin-dev wrote: > Give me an example of an *actual* inflation rate you expect to see, given a > disaster of a given magnitude. All I was doing was saying your proof is incorrect (or, rather, relies on a highly unrealistic assumption), since I hadn't seen anybody else point that out already. But even if the proof were correct, I don't think it provides a useful mechanism (since there's no reason to think miners gaining all the coins lost in a year will be sufficient for anything), and I don't really think the "security budget" framework (ie, that the percentage of total supply given to miners each year is what's important for security) you're implicitly relying on is particularly meaningful. So no, not particularly interested in diving into it any deeper. Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
Oops, you are right. We need the bribe to be the output of the coinbase, but due to the maturity rule, it isn't really a bribe. Too bad coinbases cannot take other coinbase outputs as inputs to bypass the maturity rule. I guess that means the bribe has to be by leaving transactions in the mempool. Also your point about centralization pressure is well taken. On Mon, Jul 11, 2022 at 5:56 PM Peter Todd wrote: > On Mon, Jul 11, 2022 at 05:36:52PM -0400, Peter Todd via bitcoin-dev wrote: > > On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via > bitcoin-dev wrote: > > > > What happens after that I'm not sure. > > > > > > > > > > Miners will learn to create anyone-can-spend outputs to bribe other > miners > > > to build on their block rather than reorg it. (Due to the coinbase > > > maturity, this will require some amount of floating capital.) > > > > ...and that's a disaster for mining centralization, because the smaller > miners > > need to pay larger bribes than larger miners. Not to mention having to > keep > > capital around to do it. > > Also, note how from a practical point of view, we'll need to add a new > type of > tx that's only valid in a specific block, or other miners will just reorg > those > anyone-can-spend outputs to steal them. It's not all that trivial to > actually > do that... you'd have to have a signature that commits to the non-segwit > part > of the coinbase outputs. Ugh. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
