* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
@ 2022-07-12 3:56 Peter
2022-07-12 11:57 ` Erik Aronesty
0 siblings, 1 reply; 35+ messages in thread
From: Peter @ 2022-07-12 3:56 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3582 bytes --]
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)
[-- Attachment #2: Type: text/html, Size: 4102 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-12 3:56 [bitcoin-dev] Security problems with relying on transaction fees for security Peter
@ 2022-07-12 11:57 ` Erik Aronesty
2022-07-12 15:08 ` Peter
2022-07-12 17:46 ` Ryan Grant
0 siblings, 2 replies; 35+ messages in thread
From: Erik Aronesty @ 2022-07-12 11:57 UTC (permalink / raw)
To: Peter, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]
>
> 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
>
[-- Attachment #2: Type: text/html, Size: 1999 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-12 11:57 ` Erik Aronesty
@ 2022-07-12 15:08 ` Peter
2022-07-12 17:46 ` Ryan Grant
1 sibling, 0 replies; 35+ messages in thread
From: Peter @ 2022-07-12 15:08 UTC (permalink / raw)
To: erik, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2698 bytes --]
>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
>
>>
[-- Attachment #2: Type: text/html, Size: 4252 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-12 11:57 ` Erik Aronesty
2022-07-12 15:08 ` Peter
@ 2022-07-12 17:46 ` Ryan Grant
1 sibling, 0 replies; 35+ messages in thread
From: Ryan Grant @ 2022-07-12 17:46 UTC (permalink / raw)
To: Bitcoin Protocol Discussion; +Cc: Peter
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 <dizzle@pointbiz•com> 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/
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-14 16:27 ` Manuel Costa
@ 2022-07-15 6:03 ` vjudeu
0 siblings, 0 replies; 35+ messages in thread
From: vjudeu @ 2022-07-15 6:03 UTC (permalink / raw)
To: Manuel Costa <manecosta@gmail•com>,
Bitcoin Protocol Discussion, Gino Pinuto,
Bitcoin Protocol Discussion
> 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 <bitcoin-dev@lists•linuxfoundation.org> 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 <bitcoin-dev@lists•linuxfoundation.org> 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 to do it.
Gino Pinuto via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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
_______________________________________________
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-14 11:42 ` Gino Pinuto
2022-07-14 16:01 ` Erik Aronesty
@ 2022-07-14 16:27 ` Manuel Costa
2022-07-15 6:03 ` vjudeu
1 sibling, 1 reply; 35+ messages in thread
From: Manuel Costa @ 2022-07-14 16:27 UTC (permalink / raw)
To: Gino Pinuto, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 8841 bytes --]
> 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 <bitcoin-dev@lists•linuxfoundation.org>
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 to do it.
>>>
>>>
>>>
>>>
>>> Gino Pinuto via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
>>> 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
>>>
>> _______________________________________________
>> 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
>
[-- Attachment #2: Type: text/html, Size: 11738 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-14 11:42 ` Gino Pinuto
@ 2022-07-14 16:01 ` Erik Aronesty
2022-07-14 16:27 ` Manuel Costa
1 sibling, 0 replies; 35+ messages in thread
From: Erik Aronesty @ 2022-07-14 16:01 UTC (permalink / raw)
To: Gino Pinuto; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7880 bytes --]
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 <gino.pinuto@gmail•com> 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 <bitcoin-dev@lists•linuxfoundation.org>
>>> 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
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
[-- Attachment #2: Type: text/html, Size: 10659 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-14 9:57 ` Erik Aronesty
@ 2022-07-14 11:42 ` Gino Pinuto
2022-07-14 16:01 ` Erik Aronesty
2022-07-14 16:27 ` Manuel Costa
0 siblings, 2 replies; 35+ messages in thread
From: Gino Pinuto @ 2022-07-14 11:42 UTC (permalink / raw)
To: Erik Aronesty, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7368 bytes --]
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 <bitcoin-dev@lists•linuxfoundation.org>
>> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 9862 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-14 9:33 ` vjudeu
@ 2022-07-14 9:57 ` Erik Aronesty
2022-07-14 11:42 ` Gino Pinuto
0 siblings, 1 reply; 35+ messages in thread
From: Erik Aronesty @ 2022-07-14 9:57 UTC (permalink / raw)
To: vjudeu, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6255 bytes --]
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 <bitcoin-dev@lists•linuxfoundation.org>
> 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
>
[-- Attachment #2: Type: text/html, Size: 8165 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-13 13:29 ` Manuel Costa
@ 2022-07-14 9:33 ` vjudeu
2022-07-14 9:57 ` Erik Aronesty
0 siblings, 1 reply; 35+ messages in thread
From: vjudeu @ 2022-07-14 9:33 UTC (permalink / raw)
To: Manuel Costa <manecosta@gmail•com>,
Bitcoin Protocol Discussion, Gino Pinuto,
Bitcoin Protocol Discussion
> 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 <bitcoin-dev@lists•linuxfoundation.org> 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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-12 0:21 ` Russell O'Connor
2022-07-12 0:37 ` Peter Todd
@ 2022-07-14 0:54 ` Anthony Towns
1 sibling, 0 replies; 35+ messages in thread
From: Anthony Towns @ 2022-07-14 0:54 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
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
00000000000000000005f28764680afdbd8375216ff8f30b17eeb26bd98aac63,
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-13 12:11 ` Gino Pinuto
@ 2022-07-13 13:29 ` Manuel Costa
2022-07-14 9:33 ` vjudeu
0 siblings, 1 reply; 35+ messages in thread
From: Manuel Costa @ 2022-07-13 13:29 UTC (permalink / raw)
To: Gino Pinuto, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4043 bytes --]
> 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 <bitcoin-dev@lists•linuxfoundation.org>
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
>
[-- Attachment #2: Type: text/html, Size: 5464 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-13 0:38 ` Tom Harding
@ 2022-07-13 12:18 ` Erik Aronesty
0 siblings, 0 replies; 35+ messages in thread
From: Erik Aronesty @ 2022-07-13 12:18 UTC (permalink / raw)
To: Tom Harding, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 1954 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-13 9:43 ` John Tromp
2022-07-13 11:56 ` John Tromp
@ 2022-07-13 12:11 ` Gino Pinuto
2022-07-13 13:29 ` Manuel Costa
1 sibling, 1 reply; 35+ messages in thread
From: Gino Pinuto @ 2022-07-13 12:11 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2540 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 3496 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-13 9:43 ` John Tromp
@ 2022-07-13 11:56 ` John Tromp
2022-07-13 12:11 ` Gino Pinuto
1 sibling, 0 replies; 35+ messages in thread
From: John Tromp @ 2022-07-13 11:56 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
> 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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
[not found] <mailman.82083.1657699581.8511.bitcoin-dev@lists.linuxfoundation.org>
@ 2022-07-13 9:43 ` John Tromp
2022-07-13 11:56 ` John Tromp
2022-07-13 12:11 ` Gino Pinuto
0 siblings, 2 replies; 35+ messages in thread
From: John Tromp @ 2022-07-13 9:43 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
> 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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 22:26 ` Peter Todd
2022-07-12 0:01 ` James MacWhyte
@ 2022-07-13 0:38 ` Tom Harding
2022-07-13 12:18 ` Erik Aronesty
1 sibling, 1 reply; 35+ messages in thread
From: Tom Harding @ 2022-07-13 0:38 UTC (permalink / raw)
To: bitcoin-dev
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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 21:53 ` Peter Todd
@ 2022-07-12 2:47 ` Bram Cohen
0 siblings, 0 replies; 35+ messages in thread
From: Bram Cohen @ 2022-07-12 2:47 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
On Mon, Jul 11, 2022 at 2:53 PM Peter Todd <pete@petertodd•org> 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.
[-- Attachment #2: Type: text/html, Size: 1443 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-12 0:21 ` Russell O'Connor
@ 2022-07-12 0:37 ` Peter Todd
2022-07-14 0:54 ` Anthony Towns
1 sibling, 0 replies; 35+ messages in thread
From: Peter Todd @ 2022-07-12 0:37 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 829 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-12 0:01 ` James MacWhyte
@ 2022-07-12 0:31 ` Peter Todd
0 siblings, 0 replies; 35+ messages in thread
From: Peter Todd @ 2022-07-12 0:31 UTC (permalink / raw)
To: James MacWhyte; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]
On Tue, Jul 12, 2022 at 02:01:09AM +0200, James MacWhyte wrote:
> On Tue, Jul 12, 2022 at 12:26 AM Peter Todd <pete@petertodd•org> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 21:56 ` Peter Todd
@ 2022-07-12 0:21 ` Russell O'Connor
2022-07-12 0:37 ` Peter Todd
2022-07-14 0:54 ` Anthony Towns
0 siblings, 2 replies; 35+ messages in thread
From: Russell O'Connor @ 2022-07-12 0:21 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]
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 <pete@petertodd•org> 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
>
[-- Attachment #2: Type: text/html, Size: 2182 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 22:26 ` Peter Todd
@ 2022-07-12 0:01 ` James MacWhyte
2022-07-12 0:31 ` Peter Todd
2022-07-13 0:38 ` Tom Harding
1 sibling, 1 reply; 35+ messages in thread
From: James MacWhyte @ 2022-07-12 0:01 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
On Tue, Jul 12, 2022 at 12:26 AM Peter Todd <pete@petertodd•org> 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?
[-- Attachment #2: Type: text/html, Size: 1008 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 18:12 Bram Cohen
` (6 preceding siblings ...)
2022-07-11 22:19 ` James MacWhyte
@ 2022-07-11 23:29 ` Anthony Towns
7 siblings, 0 replies; 35+ messages in thread
From: Anthony Towns @ 2022-07-11 23:29 UTC (permalink / raw)
To: Bram Cohen, Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 22:19 ` James MacWhyte
@ 2022-07-11 22:26 ` Peter Todd
2022-07-12 0:01 ` James MacWhyte
2022-07-13 0:38 ` Tom Harding
0 siblings, 2 replies; 35+ messages in thread
From: Peter Todd @ 2022-07-11 22:26 UTC (permalink / raw)
To: James MacWhyte, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 955 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 18:12 Bram Cohen
` (5 preceding siblings ...)
2022-07-11 21:53 ` Peter Todd
@ 2022-07-11 22:19 ` James MacWhyte
2022-07-11 22:26 ` Peter Todd
2022-07-11 23:29 ` Anthony Towns
7 siblings, 1 reply; 35+ messages in thread
From: James MacWhyte @ 2022-07-11 22:19 UTC (permalink / raw)
To: Bram Cohen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3923 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 4685 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 21:36 ` Peter Todd
@ 2022-07-11 21:56 ` Peter Todd
2022-07-12 0:21 ` Russell O'Connor
0 siblings, 1 reply; 35+ messages in thread
From: Peter Todd @ 2022-07-11 21:56 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 18:12 Bram Cohen
` (4 preceding siblings ...)
2022-07-11 21:18 ` Pox
@ 2022-07-11 21:53 ` Peter Todd
2022-07-12 2:47 ` Bram Cohen
2022-07-11 22:19 ` James MacWhyte
2022-07-11 23:29 ` Anthony Towns
7 siblings, 1 reply; 35+ messages in thread
From: Peter Todd @ 2022-07-11 21:53 UTC (permalink / raw)
To: Bram Cohen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4691 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 20:35 ` Russell O'Connor
2022-07-11 20:52 ` Erik Aronesty
@ 2022-07-11 21:36 ` Peter Todd
2022-07-11 21:56 ` Peter Todd
1 sibling, 1 reply; 35+ messages in thread
From: Peter Todd @ 2022-07-11 21:36 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 591 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 18:12 Bram Cohen
` (3 preceding siblings ...)
2022-07-11 20:35 ` Russell O'Connor
@ 2022-07-11 21:18 ` Pox
2022-07-11 21:53 ` Peter Todd
` (2 subsequent siblings)
7 siblings, 0 replies; 35+ messages in thread
From: Pox @ 2022-07-11 21:18 UTC (permalink / raw)
To: Bram Cohen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 652 bytes --]
On 11 Jul 2022, at 19:12, Bram Cohen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
<snip>
> 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.
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 20:35 ` Russell O'Connor
@ 2022-07-11 20:52 ` Erik Aronesty
2022-07-11 21:36 ` Peter Todd
1 sibling, 0 replies; 35+ messages in thread
From: Erik Aronesty @ 2022-07-11 20:52 UTC (permalink / raw)
To: Russell O'Connor, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 767 bytes --]
>
> 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
[-- Attachment #2: Type: text/html, Size: 1217 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 18:12 Bram Cohen
` (2 preceding siblings ...)
2022-07-11 19:45 ` vjudeu
@ 2022-07-11 20:35 ` Russell O'Connor
2022-07-11 20:52 ` Erik Aronesty
2022-07-11 21:36 ` Peter Todd
2022-07-11 21:18 ` Pox
` (3 subsequent siblings)
7 siblings, 2 replies; 35+ messages in thread
From: Russell O'Connor @ 2022-07-11 20:35 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]
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.)
[-- Attachment #2: Type: text/html, Size: 2027 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 18:12 Bram Cohen
2022-07-11 18:38 ` micaroni
2022-07-11 18:43 ` Erik Aronesty
@ 2022-07-11 19:45 ` vjudeu
2022-07-11 20:35 ` Russell O'Connor
` (4 subsequent siblings)
7 siblings, 0 replies; 35+ messages in thread
From: vjudeu @ 2022-07-11 19:45 UTC (permalink / raw)
To: Bram Cohen <bram@chia•net>,
Bitcoin Protocol Discussion, Bitcoin Protocol Discussion
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 1000000" 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 <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.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 18:12 Bram Cohen
2022-07-11 18:38 ` micaroni
@ 2022-07-11 18:43 ` Erik Aronesty
2022-07-11 19:45 ` vjudeu
` (5 subsequent siblings)
7 siblings, 0 replies; 35+ messages in thread
From: Erik Aronesty @ 2022-07-11 18:43 UTC (permalink / raw)
To: Bram Cohen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5322 bytes --]
> 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 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
>
[-- Attachment #2: Type: text/html, Size: 6176 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [bitcoin-dev] Security problems with relying on transaction fees for security
2022-07-11 18:12 Bram Cohen
@ 2022-07-11 18:38 ` micaroni
2022-07-11 18:43 ` Erik Aronesty
` (6 subsequent siblings)
7 siblings, 0 replies; 35+ messages in thread
From: micaroni @ 2022-07-11 18:38 UTC (permalink / raw)
To: Bram Cohen, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3764 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 5213 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
* [bitcoin-dev] Security problems with relying on transaction fees for security
@ 2022-07-11 18:12 Bram Cohen
2022-07-11 18:38 ` micaroni
` (7 more replies)
0 siblings, 8 replies; 35+ messages in thread
From: Bram Cohen @ 2022-07-11 18:12 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3021 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 3207 bytes --]
^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2022-07-15 6:04 UTC | newest]
Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-12 3:56 [bitcoin-dev] Security problems with relying on transaction fees for security Peter
2022-07-12 11:57 ` Erik Aronesty
2022-07-12 15:08 ` Peter
2022-07-12 17:46 ` Ryan Grant
[not found] <mailman.82083.1657699581.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-07-13 9:43 ` John Tromp
2022-07-13 11:56 ` John Tromp
2022-07-13 12:11 ` Gino Pinuto
2022-07-13 13:29 ` Manuel Costa
2022-07-14 9:33 ` vjudeu
2022-07-14 9:57 ` Erik Aronesty
2022-07-14 11:42 ` Gino Pinuto
2022-07-14 16:01 ` Erik Aronesty
2022-07-14 16:27 ` Manuel Costa
2022-07-15 6:03 ` vjudeu
-- strict thread matches above, loose matches on Subject: below --
2022-07-11 18:12 Bram Cohen
2022-07-11 18:38 ` micaroni
2022-07-11 18:43 ` Erik Aronesty
2022-07-11 19:45 ` vjudeu
2022-07-11 20:35 ` Russell O'Connor
2022-07-11 20:52 ` Erik Aronesty
2022-07-11 21:36 ` Peter Todd
2022-07-11 21:56 ` Peter Todd
2022-07-12 0:21 ` Russell O'Connor
2022-07-12 0:37 ` Peter Todd
2022-07-14 0:54 ` Anthony Towns
2022-07-11 21:18 ` Pox
2022-07-11 21:53 ` Peter Todd
2022-07-12 2:47 ` Bram Cohen
2022-07-11 22:19 ` James MacWhyte
2022-07-11 22:26 ` Peter Todd
2022-07-12 0:01 ` James MacWhyte
2022-07-12 0:31 ` Peter Todd
2022-07-13 0:38 ` Tom Harding
2022-07-13 12:18 ` Erik Aronesty
2022-07-11 23:29 ` Anthony Towns
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox