Re: [bitcoin-dev] Security problems with relying on transaction fees for security

From: Erik Aronesty <erik@q32•com>
To: Gino Pinuto <gino.pinuto@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Security problems with relying on transaction fees for security
Date: Thu, 14 Jul 2022 12:01:39 -0400	[thread overview]
Message-ID: <CAJowKg+cYDK_r6-hXOxH83HCZhzQTMGUyhrx0+wk0aZCYH-C5w@mail.gmail.com> (raw)
In-Reply-To: <CAA3CggE4cJO_=8YR82qYOS=9PR34mSVsGznOuexTNpHbRuW6hw@mail.gmail.com>

[-- 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 --]