Re: [bitcoin-dev] Security problems with relying on transaction fees for security
> Unsure how this solves or relates to the smoothing of block rewards. Let me > know if I misunderstood. This example shows clearly that even if tail supply supporters will win, then no matter how they will introduce new coins to the system, we can still resist that attack by burning those coins, or by locking them in some endless loop, to make it compatible with their malicious soft-fork (because I don't think the community will agree on some hard-fork, when none is needed). And when it comes to smoothing rewards, then if you decide, that for example any miner can take only 0.01 BTC, and the rest should be timelocked to the future blocks, then it will make block rewards more smooth. So, when it comes to making fees more smooth, it is only a matter of choosing the right amount, that miners can agree to introduce (because reducing 6.25 BTC plus fees into 0.01 BTC now, and getting a promise that the block reward will never go below 0.01 BTC, is not something they are likely to support, so different amounts should be chosen). On 2022-07-14 18:34:24 user Manuel Costa via bitcoin-dev wrote: > There is a smarter way. Just send 0.01 BTC per block to the timelocked > outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that > percentage will grow over time, as basic block reward will shrink, and we > will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess > what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it > simply means you can lock 2,100 BTC in an endless circulation loop, and avoid > this "tail supply attack". My understanding of this is that it would basically remove 0.01 BTC rewards from the next 210k blocks, and then do nothing. After 210k blocks have passed, you're just rolling it forward, taking from the anyone can spend output and locking it in a new one for 210k blocks from now. You're basically just using the next 210k block's reward to create a stash of forever locked coins in a loop. Unsure how this solves or relates to the smoothing of block rewards. Let me know if I misunderstood. Gino Pinuto via bitcoin-dev escreveu no dia quinta, 14/07/2022 à(s) 13:18: This is not an argument in line with bitcoin values, on that scenario only rich people will be able to mine and participate to the consensus process. Like George Soros today, he use its financial reserves to monopolize ONG in order to manipulate nation states. I would not define this a "tax", moreover a cost to maintain control over the network. Those rich holders could crate a cartel and without market dynamics all game theory stop to work and the bitcoin network value drop. We should think about how to maximise the network value instead of trying to preserve it with corruptible practices outside of market dynamics principles. On Thu, 14 Jul 2022, 12:53 Erik Aronesty via bitcoin-dev, wrote: Fees and miner rewards are not needed at all for security at all since long term holders can simply invest in mining to secure the value of their stake. Isn't it enough that the protocol has a mechanism to secure value? Sure fees *might* be enough. But in the event that they are not, large holders can burn a bit to make sure the hashrate stays high. I know, I know it's a tax on the rich and it's not fair because smaller holders are less likely to do it, but it's a miniscule tax even in the worst case On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev wrote: > This specific approach would obviously not work as most of those outputs > would be dust and the miner would need to waste an absurd amount of block > space just to grab them, but maybe there's a smarter way to do it. There is a smarter way. Just send 0.01 BTC per block to the timelocked outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that percentage will grow over time, as basic block reward will shrink, and we will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it simply means you can lock 2,100 BTC in an endless circulation loop, and avoid this "tail supply attack". So, fortunately, even if "tail supply attackers" will win, we will still have a chance to counter-attack by burning those coins, or (even better) by locking them in an endless circulation loop, just to satisfy their malicious soft-fork, whatever amount it will require. Because even if it will be mandatory to timelock 0.01 BTC to the current block number plus 210,000, then it is still perfectly valid to move that amount endlessly, without taking it, just to resist this "tail supply attack". On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev wrote: > What about burning all fees and keep a block reward that will smooth out > while keeping the ~21M coins limit ? This would be a hard fork afaict as it would go against the rules of the coinbase transaction following the usual
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
> There is a smarter way. Just send 0.01 BTC per block to the timelocked outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that percentage will grow over time, as basic block reward will shrink, and we will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it simply means you can lock 2,100 BTC in an endless circulation loop, and avoid this "tail supply attack". My understanding of this is that it would basically remove 0.01 BTC rewards from the next 210k blocks, and then do nothing. After 210k blocks have passed, you're just rolling it forward, taking from the anyone can spend output and locking it in a new one for 210k blocks from now. You're basically just using the next 210k block's reward to create a stash of forever locked coins in a loop. Unsure how this solves or relates to the smoothing of block rewards. Let me know if I misunderstood. Gino Pinuto via bitcoin-dev escreveu no dia quinta, 14/07/2022 à(s) 13:18: > This is not an argument in line with bitcoin values, on that scenario only > rich people will be able to mine and participate to the consensus process. > Like George Soros today, he use its financial reserves to monopolize ONG > in order to manipulate nation states. I would not define this a "tax", > moreover a cost to maintain control over the network. > > Those rich holders could crate a cartel and without market dynamics all > game theory stop to work and the bitcoin network value drop. > > We should think about how to maximise the network value instead of trying > to preserve it with corruptible practices outside of market dynamics > principles. > > On Thu, 14 Jul 2022, 12:53 Erik Aronesty via bitcoin-dev, < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Fees and miner rewards are not needed at all for security at all since >> long term holders can simply invest in mining to secure the value of their >> stake. >> >> Isn't it enough that the protocol has a mechanism to secure value? >> >> Sure fees *might* be enough. >> >> But in the event that they are not, large holders can burn a bit to make >> sure the hashrate stays high. >> >> I know, I know it's a tax on the rich and it's not fair because smaller >> holders are less likely to do it, but it's a miniscule tax even in the >> worst case >> >> >> >> >> >> >> >> >> >> On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> > This specific approach would obviously not work as most of those >>> outputs would be dust and the miner would need to waste an absurd amount of >>> block space just to grab them, but maybe there's a smarter way to do it. >>> >>> There is a smarter way. Just send 0.01 BTC per block to the timelocked >>> outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that >>> percentage will grow over time, as basic block reward will shrink, and we >>> will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess >>> what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it >>> simply means you can lock 2,100 BTC in an endless circulation loop, and >>> avoid this "tail supply attack". >>> >>> So, fortunately, even if "tail supply attackers" will win, we will still >>> have a chance to counter-attack by burning those coins, or (even better) by >>> locking them in an endless circulation loop, just to satisfy their >>> malicious soft-fork, whatever amount it will require. Because even if it >>> will be mandatory to timelock 0.01 BTC to the current block number plus >>> 210,000, then it is still perfectly valid to move that amount endlessly, >>> without taking it, just to resist this "tail supply attack". >>> >>> >>> On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> > What about burning all fees and keep a block reward that will smooth >>> out while keeping the ~21M coins limit ? >>> >>> This would be a hard fork afaict as it would go against the rules of the >>> coinbase transaction following the usual halving schedule. >>> >>> However, if instead we added a rule that fees have to be sent to an >>> anyone can spend output with a timelock we might be able to achieve a >>> similar thing. >>> >>> Highly inefficient example: >>> >>> - Split blocks into 144 (about a day) >>> - A mined block takes all the fees and distributes them equally into 144 >>> new outputs (anyone can spend) time locked to each of the 144 blocks of the >>> next day. >>> - Next day, for each block, we'd have available an amount equivalent to >>> the previous day total fees / 144. So we deliver previous day's fees >>> smoothed out. >>> >>> Notes: >>> 144 is arbitrary in the example. >>> This specific approach would obviously not work as most of those outputs >>> would be dust and the miner would need to waste an absurd amount of block >>> space just to grab them, but maybe there's a smarter way
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
it's in line with the values of - immutable supply - enforced by the game theory of hard money and no, it's not only "rich holders"... i mine, and lots of people i know do it's certainly more decentralized than the alternatives On Thu, Jul 14, 2022 at 7:43 AM Gino Pinuto wrote: > This is not an argument in line with bitcoin values, on that scenario only > rich people will be able to mine and participate to the consensus process. > Like George Soros today, he use its financial reserves to monopolize ONG > in order to manipulate nation states. I would not define this a "tax", > moreover a cost to maintain control over the network. > > Those rich holders could crate a cartel and without market dynamics all > game theory stop to work and the bitcoin network value drop. > > We should think about how to maximise the network value instead of trying > to preserve it with corruptible practices outside of market dynamics > principles. > > On Thu, 14 Jul 2022, 12:53 Erik Aronesty via bitcoin-dev, < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Fees and miner rewards are not needed at all for security at all since >> long term holders can simply invest in mining to secure the value of their >> stake. >> >> Isn't it enough that the protocol has a mechanism to secure value? >> >> Sure fees *might* be enough. >> >> But in the event that they are not, large holders can burn a bit to make >> sure the hashrate stays high. >> >> I know, I know it's a tax on the rich and it's not fair because smaller >> holders are less likely to do it, but it's a miniscule tax even in the >> worst case >> >> >> >> >> >> >> >> >> >> On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> > This specific approach would obviously not work as most of those >>> outputs would be dust and the miner would need to waste an absurd amount of >>> block space just to grab them, but maybe there's a smarter way to do it. >>> >>> There is a smarter way. Just send 0.01 BTC per block to the timelocked >>> outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that >>> percentage will grow over time, as basic block reward will shrink, and we >>> will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess >>> what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it >>> simply means you can lock 2,100 BTC in an endless circulation loop, and >>> avoid this "tail supply attack". >>> >>> So, fortunately, even if "tail supply attackers" will win, we will still >>> have a chance to counter-attack by burning those coins, or (even better) by >>> locking them in an endless circulation loop, just to satisfy their >>> malicious soft-fork, whatever amount it will require. Because even if it >>> will be mandatory to timelock 0.01 BTC to the current block number plus >>> 210,000, then it is still perfectly valid to move that amount endlessly, >>> without taking it, just to resist this "tail supply attack". >>> >>> >>> On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev < >>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>> > What about burning all fees and keep a block reward that will smooth >>> out while keeping the ~21M coins limit ? >>> >>> This would be a hard fork afaict as it would go against the rules of the >>> coinbase transaction following the usual halving schedule. >>> >>> However, if instead we added a rule that fees have to be sent to an >>> anyone can spend output with a timelock we might be able to achieve a >>> similar thing. >>> >>> Highly inefficient example: >>> >>> - Split blocks into 144 (about a day) >>> - A mined block takes all the fees and distributes them equally into 144 >>> new outputs (anyone can spend) time locked to each of the 144 blocks of the >>> next day. >>> - Next day, for each block, we'd have available an amount equivalent to >>> the previous day total fees / 144. So we deliver previous day's fees >>> smoothed out. >>> >>> Notes: >>> 144 is arbitrary in the example. >>> This specific approach would obviously not work as most of those outputs >>> would be dust and the miner would need to waste an absurd amount of block >>> space just to grab them, but maybe there's a smarter way to do it. >>> >>> >>> >>> >>> Gino Pinuto via bitcoin-dev >>> escreveu no dia quarta, 13/07/2022 à(s) 13:19: >>> What about burning all fees and keep a block reward that will smooth out >>> while keeping the ~21M coins limit ? >>> >>> >>> Benefits : >>> - Miners would still be incentivized to collect higher fees transaction >>> with the indirect perspective to generate more reward in future. >>> - Revenues are equally distributed over time to all participants and we >>> solve the overnight discrepancy. >>> - Increased velocity of money will reduce the immediate supply of >>> bitcoin cooling down the economy. >>> - Reduction of velocity will have an impact on miners only if it >>> persevere in the long term but short term they will still
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
This is not an argument in line with bitcoin values, on that scenario only rich people will be able to mine and participate to the consensus process. Like George Soros today, he use its financial reserves to monopolize ONG in order to manipulate nation states. I would not define this a "tax", moreover a cost to maintain control over the network. Those rich holders could crate a cartel and without market dynamics all game theory stop to work and the bitcoin network value drop. We should think about how to maximise the network value instead of trying to preserve it with corruptible practices outside of market dynamics principles. On Thu, 14 Jul 2022, 12:53 Erik Aronesty via bitcoin-dev, < bitcoin-dev@lists.linuxfoundation.org> wrote: > Fees and miner rewards are not needed at all for security at all since > long term holders can simply invest in mining to secure the value of their > stake. > > Isn't it enough that the protocol has a mechanism to secure value? > > Sure fees *might* be enough. > > But in the event that they are not, large holders can burn a bit to make > sure the hashrate stays high. > > I know, I know it's a tax on the rich and it's not fair because smaller > holders are less likely to do it, but it's a miniscule tax even in the > worst case > > > > > > > > > > On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > This specific approach would obviously not work as most of those >> outputs would be dust and the miner would need to waste an absurd amount of >> block space just to grab them, but maybe there's a smarter way to do it. >> >> There is a smarter way. Just send 0.01 BTC per block to the timelocked >> outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that >> percentage will grow over time, as basic block reward will shrink, and we >> will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess >> what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it >> simply means you can lock 2,100 BTC in an endless circulation loop, and >> avoid this "tail supply attack". >> >> So, fortunately, even if "tail supply attackers" will win, we will still >> have a chance to counter-attack by burning those coins, or (even better) by >> locking them in an endless circulation loop, just to satisfy their >> malicious soft-fork, whatever amount it will require. Because even if it >> will be mandatory to timelock 0.01 BTC to the current block number plus >> 210,000, then it is still perfectly valid to move that amount endlessly, >> without taking it, just to resist this "tail supply attack". >> >> >> On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> > What about burning all fees and keep a block reward that will smooth >> out while keeping the ~21M coins limit ? >> >> This would be a hard fork afaict as it would go against the rules of the >> coinbase transaction following the usual halving schedule. >> >> However, if instead we added a rule that fees have to be sent to an >> anyone can spend output with a timelock we might be able to achieve a >> similar thing. >> >> Highly inefficient example: >> >> - Split blocks into 144 (about a day) >> - A mined block takes all the fees and distributes them equally into 144 >> new outputs (anyone can spend) time locked to each of the 144 blocks of the >> next day. >> - Next day, for each block, we'd have available an amount equivalent to >> the previous day total fees / 144. So we deliver previous day's fees >> smoothed out. >> >> Notes: >> 144 is arbitrary in the example. >> This specific approach would obviously not work as most of those outputs >> would be dust and the miner would need to waste an absurd amount of block >> space just to grab them, but maybe there's a smarter way to do it. >> >> >> >> >> Gino Pinuto via bitcoin-dev >> escreveu no dia quarta, 13/07/2022 à(s) 13:19: >> What about burning all fees and keep a block reward that will smooth out >> while keeping the ~21M coins limit ? >> >> >> Benefits : >> - Miners would still be incentivized to collect higher fees transaction >> with the indirect perspective to generate more reward in future. >> - Revenues are equally distributed over time to all participants and we >> solve the overnight discrepancy. >> - Increased velocity of money will reduce the immediate supply of bitcoin >> cooling down the economy. >> - Reduction of velocity will have an impact on miners only if it >> persevere in the long term but short term they will still perceive the >> buffered reward. >> >> >> I don't have ideas yet on how to elegantly implement this. >> >> >> >> On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> > The emission curve lasts over 100 years because Bitcoin success state >> requires it to be entrenched globally. >> >> It effectively doesn't. The last 100 years from 2040-2140 only emits a >>
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
Fees and miner rewards are not needed at all for security at all since long term holders can simply invest in mining to secure the value of their stake. Isn't it enough that the protocol has a mechanism to secure value? Sure fees *might* be enough. But in the event that they are not, large holders can burn a bit to make sure the hashrate stays high. I know, I know it's a tax on the rich and it's not fair because smaller holders are less likely to do it, but it's a miniscule tax even in the worst case On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > This specific approach would obviously not work as most of those outputs > would be dust and the miner would need to waste an absurd amount of block > space just to grab them, but maybe there's a smarter way to do it. > > There is a smarter way. Just send 0.01 BTC per block to the timelocked > outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that > percentage will grow over time, as basic block reward will shrink, and we > will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess > what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it > simply means you can lock 2,100 BTC in an endless circulation loop, and > avoid this "tail supply attack". > > So, fortunately, even if "tail supply attackers" will win, we will still > have a chance to counter-attack by burning those coins, or (even better) by > locking them in an endless circulation loop, just to satisfy their > malicious soft-fork, whatever amount it will require. Because even if it > will be mandatory to timelock 0.01 BTC to the current block number plus > 210,000, then it is still perfectly valid to move that amount endlessly, > without taking it, just to resist this "tail supply attack". > > > On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > What about burning all fees and keep a block reward that will smooth out > while keeping the ~21M coins limit ? > > This would be a hard fork afaict as it would go against the rules of the > coinbase transaction following the usual halving schedule. > > However, if instead we added a rule that fees have to be sent to an anyone > can spend output with a timelock we might be able to achieve a similar > thing. > > Highly inefficient example: > > - Split blocks into 144 (about a day) > - A mined block takes all the fees and distributes them equally into 144 > new outputs (anyone can spend) time locked to each of the 144 blocks of the > next day. > - Next day, for each block, we'd have available an amount equivalent to > the previous day total fees / 144. So we deliver previous day's fees > smoothed out. > > Notes: > 144 is arbitrary in the example. > This specific approach would obviously not work as most of those outputs > would be dust and the miner would need to waste an absurd amount of block > space just to grab them, but maybe there's a smarter way to do it. > > > > > Gino Pinuto via bitcoin-dev > escreveu no dia quarta, 13/07/2022 à(s) 13:19: > What about burning all fees and keep a block reward that will smooth out > while keeping the ~21M coins limit ? > > > Benefits : > - Miners would still be incentivized to collect higher fees transaction > with the indirect perspective to generate more reward in future. > - Revenues are equally distributed over time to all participants and we > solve the overnight discrepancy. > - Increased velocity of money will reduce the immediate supply of bitcoin > cooling down the economy. > - Reduction of velocity will have an impact on miners only if it persevere > in the long term but short term they will still perceive the buffered > reward. > > > I don't have ideas yet on how to elegantly implement this. > > > > On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > The emission curve lasts over 100 years because Bitcoin success state > requires it to be entrenched globally. > > It effectively doesn't. The last 100 years from 2040-2140 only emits a > pittance of about 0.4 of all bitcoin. > > What matters for proper distribution is the shape of the emission > curve. If you emit 99% in the first year and 1% in the next 100 years, > your emission "lasts" over 100 years, and you achieve a super low > supply inflation rate immediately after 1 year, but it's obviously a > terrible form of distribution. > > This is easy to quantify as the expected time of emission which would > be 0.99 * 0.5yr + 0.01* 51yr = 2 years. > Bitcoin is not much better in that the expected time of emission of an > bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years. > > Monero appears much better since its tail emission yields an infinite > expected time of emission, but if we avoid infinities by looking at > just the soft total emission [1], which is all that is emitted before > a 1% yearly inflation, then Monero
Re: [bitcoin-dev] Security problems with relying on transaction fees for security
> This specific approach would obviously not work as most of those outputs > would be dust and the miner would need to waste an absurd amount of block > space just to grab them, but maybe there's a smarter way to do it. There is a smarter way. Just send 0.01 BTC per block to the timelocked outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that percentage will grow over time, as basic block reward will shrink, and we will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it simply means you can lock 2,100 BTC in an endless circulation loop, and avoid this "tail supply attack". So, fortunately, even if "tail supply attackers" will win, we will still have a chance to counter-attack by burning those coins, or (even better) by locking them in an endless circulation loop, just to satisfy their malicious soft-fork, whatever amount it will require. Because even if it will be mandatory to timelock 0.01 BTC to the current block number plus 210,000, then it is still perfectly valid to move that amount endlessly, without taking it, just to resist this "tail supply attack". On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev wrote: > What about burning all fees and keep a block reward that will smooth out > while keeping the ~21M coins limit ? This would be a hard fork afaict as it would go against the rules of the coinbase transaction following the usual halving schedule. However, if instead we added a rule that fees have to be sent to an anyone can spend output with a timelock we might be able to achieve a similar thing. Highly inefficient example: - Split blocks into 144 (about a day) - A mined block takes all the fees and distributes them equally into 144 new outputs (anyone can spend) time locked to each of the 144 blocks of the next day. - Next day, for each block, we'd have available an amount equivalent to the previous day total fees / 144. So we deliver previous day's fees smoothed out. Notes: 144 is arbitrary in the example. This specific approach would obviously not work as most of those outputs would be dust and the miner would need to waste an absurd amount of block space just to grab them, but maybe there's a smarter way to do it. Gino Pinuto via bitcoin-dev escreveu no dia quarta, 13/07/2022 à(s) 13:19: What about burning all fees and keep a block reward that will smooth out while keeping the ~21M coins limit ? Benefits : - Miners would still be incentivized to collect higher fees transaction with the indirect perspective to generate more reward in future. - Revenues are equally distributed over time to all participants and we solve the overnight discrepancy. - Increased velocity of money will reduce the immediate supply of bitcoin cooling down the economy. - Reduction of velocity will have an impact on miners only if it persevere in the long term but short term they will still perceive the buffered reward. I don't have ideas yet on how to elegantly implement this. On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, wrote: > The emission curve lasts over 100 years because Bitcoin success state > requires it to be entrenched globally. It effectively doesn't. The last 100 years from 2040-2140 only emits a pittance of about 0.4 of all bitcoin. What matters for proper distribution is the shape of the emission curve. If you emit 99% in the first year and 1% in the next 100 years, your emission "lasts" over 100 years, and you achieve a super low supply inflation rate immediately after 1 year, but it's obviously a terrible form of distribution. This is easy to quantify as the expected time of emission which would be 0.99 * 0.5yr + 0.01* 51yr = 2 years. Bitcoin is not much better in that the expected time of emission of an bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years. Monero appears much better since its tail emission yields an infinite expected time of emission, but if we avoid infinities by looking at just the soft total emission [1], which is all that is emitted before a 1% yearly inflation, then Monero is seen to actually be a lot worse than Bitcoin, due to emitting over 40% in its first year and halving the reward much faster. Ethereum is much worse still with its huge premine and PoS coins like Algorand are scraping the bottom with their expected emission time of 0. There's only one coin whose expected (soft) emission time is larger than bitcoin's, and it's about an order of magnitude larger, at 50 years. [1] https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153 ___ 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
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. Sufficiently advanced tx introspection could be used for this; spend the fees in the coinbase to address A, but also create a 0sat output via a regular tx to the scriptPubKey "1 CSV". Note that tx's txid as B. The next miner claims the bribe B, by spending the 0sat output to itself with a 1-in, 1-out tx, with scriptPubKey C. nVersion = 1 inputs = [txid=B, vout=0, scriptSig="", nSeq=1] outputs = [value=0, scriptPubKey=C] nLocktime = 0 Now we get back to A, and say that it's scriptPubKey uses a script that takes "C" as input, has "B" hardcoded, calculates the txid of the tx above, call it D, and then uses tx introspection to check that one of the inputs of the tx has D as the txid. > I guess that means the bribe has to be by leaving transactions in the > mempool. You *could* make that work if you allow tx's to use the annex to commit to a recent block. That is, if you just mined block 740,000 and its hash was 0005f28764680afdbd8375216ff8f30b17eeb26bd98aac63, you construct a bribe tx paying to "OP_1", but when you sign it, you add "50ee070b4aa0d98aac63" as the annex (tag=ee, length=07, value[0:3]=height=0b4aa0=470k, value[3:]=d98aac63), and (via a soft fork) nodes then only consider that tx valid if the block at "height" ends in "d98aac63". There's then only a 1-in-4B chance that someone who extends a competitor to your block could claim the bribe, at a cost of 11 extra witness bytes. But such txs (and anything that descends from them) would become invalid with as little as a 1-block reorg, which would pretty much defeat the entire purpose of the maturity delay... 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
> What about burning all fees and keep a block reward that will smooth out while keeping the ~21M coins limit ? This would be a hard fork afaict as it would go against the rules of the coinbase transaction following the usual halving schedule. However, if instead we added a rule that fees have to be sent to an anyone can spend output with a timelock we might be able to achieve a similar thing. Highly inefficient example: - Split blocks into 144 (about a day) - A mined block takes all the fees and distributes them equally into 144 new outputs (anyone can spend) time locked to each of the 144 blocks of the next day. - Next day, for each block, we'd have available an amount equivalent to the previous day total fees / 144. So we deliver previous day's fees smoothed out. Notes: 144 is arbitrary in the example. This specific approach would obviously not work as most of those outputs would be dust and the miner would need to waste an absurd amount of block space just to grab them, but maybe there's a smarter way to do it. Gino Pinuto via bitcoin-dev escreveu no dia quarta, 13/07/2022 à(s) 13:19: > What about burning all fees and keep a block reward that will smooth out > while keeping the ~21M coins limit ? > > Benefits : > - Miners would still be incentivized to collect higher fees transaction > with the indirect perspective to generate more reward in future. > - Revenues are equally distributed over time to all participants and we > solve the overnight discrepancy. > - Increased velocity of money will reduce the immediate supply of bitcoin > cooling down the economy. > - Reduction of velocity will have an impact on miners only if it persevere > in the long term but short term they will still perceive the buffered > reward. > > I don't have ideas yet on how to elegantly implement this. > > > On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > The emission curve lasts over 100 years because Bitcoin success state >> requires it to be entrenched globally. >> >> It effectively doesn't. The last 100 years from 2040-2140 only emits a >> pittance of about 0.4 of all bitcoin. >> >> What matters for proper distribution is the shape of the emission >> curve. If you emit 99% in the first year and 1% in the next 100 years, >> your emission "lasts" over 100 years, and you achieve a super low >> supply inflation rate immediately after 1 year, but it's obviously a >> terrible form of distribution. >> >> This is easy to quantify as the expected time of emission which would >> be 0.99 * 0.5yr + 0.01* 51yr = 2 years. >> Bitcoin is not much better in that the expected time of emission of an >> bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years. >> >> Monero appears much better since its tail emission yields an infinite >> expected time of emission, but if we avoid infinities by looking at >> just the soft total emission [1], which is all that is emitted before >> a 1% yearly inflation, then Monero is seen to actually be a lot worse >> than Bitcoin, due to emitting over 40% in its first year and halving >> the reward much faster. Ethereum is much worse still with its huge >> premine and PoS coins like Algorand are scraping the bottom with their >> expected emission time of 0. >> >> There's only one coin whose expected (soft) emission time is larger >> than bitcoin's, and it's about an order of magnitude larger, at 50 >> years. >> >> [1] >> https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153 >> ___ >> 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] Security problems with relying on transaction fees for security
Bitcoin doesn't rely on fees. It relys on users protecting the network out of self interest - running nodes now - mining later It has always been incentivised by holders acting out of self interest If large holders allocating a small percentage to mining to protect their interest, that's all Bitcoin needs Although I can think of other protocols that work that way and people don't like them On Wed, Jul 13, 2022, 4:06 AM Tom Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 7/11/22 15:26, Peter Todd via bitcoin-dev wrote: > > > > Anyway, designing protocols for "price go up forever" hopium is a bad > idea. > > Yet that is the design, and it's a good one. It is equivalent to > relying on bitcoin to steadily grow in utility vs. fiat currencies. > > If it fails to do that, there's no point anyway. > > ___ > 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
What about burning all fees and keep a block reward that will smooth out while keeping the ~21M coins limit ? Benefits : - Miners would still be incentivized to collect higher fees transaction with the indirect perspective to generate more reward in future. - Revenues are equally distributed over time to all participants and we solve the overnight discrepancy. - Increased velocity of money will reduce the immediate supply of bitcoin cooling down the economy. - Reduction of velocity will have an impact on miners only if it persevere in the long term but short term they will still perceive the buffered reward. I don't have ideas yet on how to elegantly implement this. On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, < bitcoin-dev@lists.linuxfoundation.org> wrote: > > The emission curve lasts over 100 years because Bitcoin success state > requires it to be entrenched globally. > > It effectively doesn't. The last 100 years from 2040-2140 only emits a > pittance of about 0.4 of all bitcoin. > > What matters for proper distribution is the shape of the emission > curve. If you emit 99% in the first year and 1% in the next 100 years, > your emission "lasts" over 100 years, and you achieve a super low > supply inflation rate immediately after 1 year, but it's obviously a > terrible form of distribution. > > This is easy to quantify as the expected time of emission which would > be 0.99 * 0.5yr + 0.01* 51yr = 2 years. > Bitcoin is not much better in that the expected time of emission of an > bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years. > > Monero appears much better since its tail emission yields an infinite > expected time of emission, but if we avoid infinities by looking at > just the soft total emission [1], which is all that is emitted before > a 1% yearly inflation, then Monero is seen to actually be a lot worse > than Bitcoin, due to emitting over 40% in its first year and halving > the reward much faster. Ethereum is much worse still with its huge > premine and PoS coins like Algorand are scraping the bottom with their > expected emission time of 0. > > There's only one coin whose expected (soft) emission time is larger > than bitcoin's, and it's about an order of magnitude larger, at 50 > years. > > [1] > https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153 > ___ > 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
> There's only one coin whose expected (soft) emission time is larger > than bitcoin's, and it's about an order of magnitude larger, at 50 > years. Make that two coins. For DOGE it is 33 years. ___ 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 emission curve lasts over 100 years because Bitcoin success state > requires it to be entrenched globally. It effectively doesn't. The last 100 years from 2040-2140 only emits a pittance of about 0.4 of all bitcoin. What matters for proper distribution is the shape of the emission curve. If you emit 99% in the first year and 1% in the next 100 years, your emission "lasts" over 100 years, and you achieve a super low supply inflation rate immediately after 1 year, but it's obviously a terrible form of distribution. This is easy to quantify as the expected time of emission which would be 0.99 * 0.5yr + 0.01* 51yr = 2 years. Bitcoin is not much better in that the expected time of emission of an bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years. Monero appears much better since its tail emission yields an infinite expected time of emission, but if we avoid infinities by looking at just the soft total emission [1], which is all that is emitted before a 1% yearly inflation, then Monero is seen to actually be a lot worse than Bitcoin, due to emitting over 40% in its first year and halving the reward much faster. Ethereum is much worse still with its huge premine and PoS coins like Algorand are scraping the bottom with their expected emission time of 0. There's only one coin whose expected (soft) emission time is larger than bitcoin's, and it's about an order of magnitude larger, at 50 years. [1] https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153 ___ 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 7/11/22 15:26, Peter Todd via bitcoin-dev wrote: Anyway, designing protocols for "price go up forever" hopium is a bad idea. Yet that is the design, and it's a good one. It is equivalent to relying on bitcoin to steadily grow in utility vs. fiat currencies. If it fails to do that, there's no point anyway. ___ 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
BIP119, OP_CTV, allows value to be assigned in a predetermined tree of payments that confirms with a single output. This allows batched transactions in the predetermined tree (e.g. withdrawals from a centralized exchange) to be anchored in a way that disallows double-spending of the inputs, yet allows the recipients to smooth out mining fees for their withdrawal outputs, at their leisure. It's a perfect design for a world where there are always more transactions to be made than block space allows, yet only some of them are urgent. As it applies to concerns mentioned in this thread, it can be used to shift transaction fees to later blocks. Whenever smoothing transaction fees would be a nice-to-have, this is one way to have it. https://utxos.org/uses/scaling/ https://utxos.org/analysis/bip_simulation/ On Tue, Jul 12, 2022 at 9:49 AM Peter wrote: > With 3000 Lightning open/ close tx per block and 6 billion adults > it's 38 years of backlog to onboard the entire adult > population. That's not including corporations. Separately, OP_CTV also allows slightly different payment channels from the existing Lightning Network, that allow non-interactive batched opens. Using this technique, onboarding 6 billion adults to payment channels would be limited only by their willingness to participate. https://utxos.org/uses/non-interactive-channels/ ___ 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
>Probably the only thing Bitcoiners should do is to advertise this rather than >to make it some sort of secret Satoshi made this clear in the beginning that mining will trend to where energy is free. During this stage of bootstrapping we need a security budget to prevent nation state attacks. In the future we will need to lose money mining Bitcoin to prevent the reemergence of a fiat reserve currency. The emission curve lasts over 100 years because Bitcoin success state requires it to be entrenched globally. We all work for Satoshi because he invented a currency that is digital and deflationary. Gold doesn't work as a deflationary currency because of physical limitations. Yes, today people are spending some of their Bitcoin to protect the remainder of their bag. We should expect this to continue into the future. I routinely give away Bitcoin to grow support for it in my local jurisdiction. This is another form of securing Bitcoin (people power). This helps protect my deflationary wealth increase and is net profitable in my view because increased adoption powers deflation. If Bitcoin loses its deflationary promise then it will be abandoned. In the future all the miners will be energy producers. There may be small home miners who have excess energy but most energy is produced by governments today and likely in the future. So, a potential solution is you take 1% of your Bitcoin annually to secure the network for the promise of 10% deflation (increase in purchasing power). More likely large holders will be doing this. Yes, there will be free riders. Today there's also free riders who receive part of our Bitcoins via tax collection and welfare. In the future they receive free deflation instead and are incentived to save Bitcoin to receive this stipend. Regards Peter Kroll Original Message On 12 Jul 2022, 07:57, Erik Aronesty wrote: >> we can expect mining to transition to a public service from the current >> for-profit business model > > I get it now > > Game theory would predict all of the major players mining in the future will > be large holders > > If you're holding a hundred Bitcoin you should take one, sell it for mining > equipment and use it to ensure the rest is stable > > I guess that's perfectly reasonable > > Yeah I'm on board with the idea that this is a non-issue > > Interested parties will continue to maintain the security of the chain with > the same basic game theoretic stuff > > Bitcoin doesn't need a security budget > > Existing holders have the ability the means and the incentive to secure their > funds > > Probably the only thing Bitcoiners should do is to advertise this rather than > to make it some sort of secret > >>___ 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
> > we can expect mining to transition to a public service from the current > for-profit business model > I get it now Game theory would predict all of the major players mining in the future will be large holders If you're holding a hundred Bitcoin you should take one, sell it for mining equipment and use it to ensure the rest is stable I guess that's perfectly reasonable Yeah I'm on board with the idea that this is a non-issue Interested parties will continue to maintain the security of the chain with the same basic game theoretic stuff Bitcoin doesn't need a security budget Existing holders have the ability the means and the incentive to secure their funds Probably the only thing Bitcoiners should do is to advertise this rather than to make it some sort of secret > ___ 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 Bitcoin emission curve requires a 2x value increase per 210,000 blocks to maintain the existing security level. Transactions are practically irreversible when the value the miners expend (not receive) is greater than said transaction value. If you send 1000 gold grams of value in a transaction then it's finalized after 1000 gold grams worth of energy have been spent on mining blocks. Bitcoin is bootstrapping from the English population and its final steady state is to eliminate fiat and be a global reserve currency and a daily transactional currency. So, we should engineer for other language and religious communities to join in. Saturday and Sunday are business days in a large portion of the planet. Bike shedding a tail emission to try to support Bitcoin with the current 2% to 4% global adoption (in terms of holding not spending) as the world's premier pet rock is a poor strategy. We can expect Bitcoin to never have a steady value because businesses turn profits on average of 10% so there will be a steady increase in hoarding to fuel number go up technology. Prices will be more reliably accounted for in gold grams, as well as corporate and government accounts being denominated in gold grams not satoshis. We can expect the boom and bust economic cycle to disappear when the price of money (interest rates) is set by the market. The value of money will still be set by the government via average government wages. With 3000 Lightning open/ close tx per block and 6 billion adults it's 38 years of backlog to onboard the entire adult population. That's not including corporations. If we assume 20% of people use non-custodial Lightning but they each have 5 channels open we are back to 38 years backlog. There's a cost and risk to reorganize the chain to chase fees in a zero block reward world. And as stated miners can leave honey in the mempool pot. We shouldn't expect empty mempools with occational transactions with outlier large fees that cause overnight reorganizations. In a state of victory, nation-states will use solar power during the daytime to ensure local entities have priority access to confirmations and Bitcoin will receive nation-state altruism in such a future as it receives person-based altruism today. Because we as individuals and nation states all win if we keep the Schelling point of 21M bitcoins. We shouldn't make naive miner centralization models when there's national security considerations to keep the chain moving forward in a stable way. Big miners won't take all the fees and put small miners out of business because energy production itself is decentralized and idle energy will always keep a diverse set of miners on the network. Block rewards are no guarantee of security as we have seen with lesser PoW coins (Ethereum Classic and others). And during the Bitcoin immaculate conception period of 2009 to 2012 the block reward served mainly as a distribution method since JP Morgan had enough GPU power to reorganize us to block 0 but that didn't happen. So, the block reward offered little security in those days. Bitcoin works but in order to win it needs global adoption. No amount of arbitrary inflation can ensure a sufficient security budget. Block rewards are to distribute the money we can expect mining to transition to a public service from the current for-profit business model when there's a 38 year backlog and every nation is on board for the game theoretic reason to deny any single nation the power of seigniorage of the global reserve currency. Regards Peter Kroll (pointbiz / BTCCuracao)___ 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:53 PM Peter Todd wrote: > > 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. > I'm not sure what the implications would be of charging coins for moving based on their value times how long since they last moved would be (I *think* that's what you're suggesting). It isn't obviously bad, but feels weird to me. That said, a scheme which would work would be to have a fixed minimum fee of satoshis/vbyte which is required to be repaid out by the miner into a pool and they get back a fixed fraction of what was in that pool. The pool could simply be a rolling coin which keeps the balance. That's still a bit ugly but doesn't lessen block size significantly, is fairly coherent, and is a soft fork. It's the best emergency measure I'm aware of. ___ 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 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
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
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
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] 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
> > 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
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
> 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
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
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] 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 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 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 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
