public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2022-07-07 21:12 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.9.1657195203.20624.bitcoin-dev@lists.linuxfoundation.org>
2022-07-07 13:24 ` [bitcoin-dev] Bitcoin covenants are inevitable John Carvalho
2022-07-07 14:12   ` Peter Todd
2022-07-07 16:24     ` Eric Voskuil
2022-07-07 17:37       ` Erik Aronesty
2022-07-07 19:57         ` Eric Voskuil
2022-07-07 21:11           ` Erik Aronesty [this message]
2022-07-08  0:28             ` Eric Voskuil
2022-07-08  4:59               ` vjudeu
2022-07-08  7:26                 ` John Carvalho
2022-07-08 15:14               ` Erik Aronesty
2022-07-14  4:55                 ` Billy Tetrud
2022-07-07 22:06     ` Anthony Towns
2022-07-07 22:02   ` Corey Haddad
     [not found] <mailman.9.1654344003.14400.bitcoin-dev@lists.linuxfoundation.org>
2022-06-04 12:27 ` John Carvalho
2022-06-04 13:48   ` Keagan McClelland
2022-06-04 16:12   ` alicexbt
2022-06-06 13:02   ` Erik Aronesty
2022-06-12  3:36     ` Peter Todd
2022-06-12 13:02       ` Erik Aronesty
2022-06-12 16:35         ` Corey Haddad
2022-06-12 19:16       ` alicexbt
2022-06-19 10:31         ` Peter Todd
2022-06-19 15:54           ` Manuel Costa
2022-06-19 18:26             ` Kate Salazar
2022-06-19 22:35             ` Erik Aronesty
2022-06-21 19:00               ` Keagan McClelland
2022-06-21 20:10                 ` Eric Voskuil
2022-06-23 19:17                 ` Peter Todd
2022-06-28  3:55                   ` Billy Tetrud
2022-06-28 16:23                     ` Alex Lee
2022-06-28 23:22                       ` Peter Todd
2022-06-29  5:02                         ` Alex Lee
2022-06-28 23:20                     ` Peter Todd
2022-06-29 10:44                     ` Kate Salazar
2022-06-30 15:25                       ` Billy Tetrud
2022-07-03  9:43                       ` Peter Todd
2022-07-03 10:30                         ` Giuseppe B
2022-07-06  4:28                           ` Corey Haddad
2022-07-06 11:10                             ` vjudeu
2022-07-07  0:46                               ` Billy Tetrud
2022-07-07 12:15                                 ` vjudeu
2022-07-07 14:05                                 ` Erik Aronesty
2022-07-07 14:10                               ` Giuseppe B
2022-07-08  5:03                                 ` Billy Tetrud
2022-06-30 17:04                     ` Erik Aronesty
2022-06-03 18:39 alicexbt
2022-06-04  0:29 ` micaroni
2022-06-04 18:43 ` Jorge Timón
2022-06-05  4:18   ` alicexbt
2022-06-08  3:51     ` Billy Tetrud
2022-06-08  9:22       ` Jorge Timón
2022-06-09  4:30         ` Billy Tetrud
2022-06-09  0:03     ` Ryan Grant
2022-07-19  4:44 ` Anthony Towns
2022-07-19 14:46   ` alicexbt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJowKgJGfkdCjWUnUyWZ9rgnWFOVYg=aizBwC2wEbMxohRMvZg@mail.gmail.com' \
    --to=erik@q32.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=eric@voskuil.org \
    --cc=john@synonym.to \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox