Re: [bitcoin-dev] Bitcoin covenants are inevitable

From: Erik Aronesty <erik@q32•com>
To: Eric Voskuil <eric@voskuil•org>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	John Carvalho <john@synonym•to>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Date: Thu, 7 Jul 2022 17:11:47 -0400	[thread overview]
Message-ID: <CAJowKgJGfkdCjWUnUyWZ9rgnWFOVYg=aizBwC2wEbMxohRMvZg@mail.gmail.com> (raw)
In-Reply-To: <8438F081-D085-4491-8C1C-4D83FFC7DE84@voskuil.org>

[-- Attachment #1: Type: text/plain, Size: 8166 bytes --]

The relationship between block size and fees is not remotely linear.   In a
restricted environment, the fee rewards are much higher.

**the ones moving more sats will win the top spots and will pay as much as
is reasonable**

Smaller blocks produce better security for the network both in validation,
and in fees.

Without a bidding war for space, everyone can post 1 SAT/byte

With a bidding war for space, larger transactions will pay much higher
rates.   There have been a number of papers written on this but you can
concoct a trivial example to prove it.

On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil <eric@voskuil•org> wrote:

> It’s not clear how reducing block size changes the fee aspect of the block
> reward. Assuming half the space implies twice the fee per avg tx the
> reward remains constant.
>
> Any additional cost of processing more or less bytes would not matter,
> because of course this is just a cost that gets nulled out by difficulty —
> average profit (net income) is the cost of capital.
>
> The reason for smaller vs. larger blocks is to ensure that individuals can
> afford to validate. That’s a threshold criteria.
>
> Given unlimited size blocks, miners would still have to fix a point in
> time to mine, gathering as much fee as they can optimize in some time
> period presumably less than 10 minutes. The produces a limit to transaction
> volume, yet neither reward nor profit would be affected given the above
> assumptions. The difference would be in a tradeoff of per tx fee against
> the threshold.
>
> Given Moore’s Law, that threshold is constantly decreasing, which will
> make it  cheaper over time for more individuals to validate. But the
> difference for miners for smaller blocks is largely inconsequential
> relative to their other costs.
>
> Increasing demand is the only thing that increases double spend security
> (and censorship resistance assuming fee-based reward). With rising demand
> there is rising overall hash rate, despite block reward and profit
> remaining constant. This makes the cost of attempting to orphan a block
> higher, therefore lowering the depth/time requirement implied to secure a
> given tx amount.
>
> These are the two factors, demand and time. Less demand implies more time
> to secure a given amount against double spend, and also implies a lower
> cost to subsidize a censorship regime. But the latter requires a
> differential in reward between the censor and non-censoring miners. While
> this could be paid in side fees, that is a significant anonymity issue.
>
> e
>
> On Jul 7, 2022, at 10:37, Erik Aronesty <erik@q32•com> wrote:
>
> 
> > > We should not imbue real technology with magical qualities.
>
> > Precisely. It is economic forces (people), not technology, that provide
> security.
>
> Yes, and these forces don't prevent double-spend / 51% attacks if the
> amounts involved are greater than the incentives.
>
> In addition to "utility", lowering the block size could help prevent this
> issue as well... increasing fee pressure and double-spend security while
> reducing the burden on node operators.
>
> Changes to inflation are, very likely, off the table.
>
>
>
> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>>
>>
>> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>> >
>> > On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via
>> bitcoin-dev wrote:
>> >> Billy,
>> >>
>> >> Proof of work and the difficulty adjustment function solve literally
>> >> everything you are talking about already.
>> >
>> > Unfortunately you are quite wrong: the difficulty adjustment function
>> merely
>> > adjusts for changes in the amount of observable, non-51%-attacking,
>> hashing
>> > power. In the event of a chain split, the difficulty adjustment
>> function does
>> > nothing; against a 51% attacker, the difficulty adjustment does nothing;
>> > against a censor, the difficulty adjustment does nothing.
>>
>> Consider falling hash rate due to a perpetual 51% attack. Difficulty
>> falls, possibly to min difficulty if all non-censors stop mining and with
>> all censors collaborating (one miner). Yet as difficulty falls, so does the
>> cost of countering the censor. At min difficulty everyone can CPU mine
>> again.
>>
>> Given the presumption that fees rise on unconfirmed transactions, there
>> is inherent economic incentive to countering at any level of difficulty.
>> Consequently the censor is compelled to subsidize the loss resulting from
>> forgoing higher fee transactions that are incentivizing its competition.
>>
>> With falling difficulty this incentive is compounded.
>>
>> Comparisons of security in different scenarios presume a consistent level
>> of demand. If that demand is insufficient to offset the censor’s subsidy,
>> there is no security in any scenario.
>>
>> Given that the block subsidy (inflation) is paid equally to censoring and
>> non-censoring miners, it offers no security against censorship whatsoever.
>> Trading fee-based block reward for inflation-based is simply trading
>> censorship resistance for the presumption of double-spend security. But of
>> course, a censor can double spend profitably in any scenario where the
>> double spend value (to the censor) exceeds that of blocks orphaned (as the
>> censor earns 100% of all block rewards).
>>
>> Banks and state monies offer reasonable double spend security. Not sure
>> that’s a trade worth making.
>>
>> It’s not clear to me that Satoshi understood this relation. I’ve seen no
>> indication of it. However the decision to phase out subsidy, once a
>> sufficient number of units (to assure divisibility) had been issued, is
>> what transitions Bitcoin from a censorable to a censorship resistant money.
>> If one does not believe there is sufficient demand for such a money, there
>> is no way to reconcile that belief with a model of censorship resistance.
>>
>> > We should not imbue real technology with magical qualities.
>>
>> Precisely. It is economic forces (people), not technology, that provide
>> security.
>>
>> e
>>
>> >> Bitcoin does not need active economic governanance by devs or meddlers.
>> >
>> > Yes, active governance would definitely be an exploitable mechanism. On
>> the
>> > other hand, the status quo of the block reward eventually going away
>> entirely
>> > is obviously a risky state change too.
>> >
>> >>>> There is also zero agreement on how much security would constitute
>> such
>> >>> an optimum.
>> >>>
>> >>> This is really step 1. We need to generate consensus on this long
>> before
>> >>> the block subsidy becomes too small. Probably in the next 10-15
>> years. I
>> >>> wrote a paper
>> >
>> > The fact of the matter is that the present amount of security is about
>> 1.7% of
>> > the total coin supply/year, and Bitcoin seems to be working fine. 1.7%
>> is also
>> > already an amount low enough that it's much smaller than economic
>> volatility.
>> >
>> > Obviously 0% is too small.
>> >
>> > There's zero reason to stress about finding an "optimal" amount. An
>> amount low
>> > enough to be easily affordable, but non-zero, is fine. 1% would be
>> fine; 0.5%
>> > would probably be fine; 0.1% would probably be fine.
>> >
>> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a
>> 31% tax on
>> > savings; 0.1% works out to be 7.2%
>> >
>> > These are all amounts that are likely to be dwarfed by economic shifts.
>> >
>> > --
>> > https://petertodd.org 'peter'[:-1]@petertodd.org
>> > _______________________________________________
>> > 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: 10327 bytes --]