From: Eric Voskuil <eric@voskuil.org>
To: Erik Aronesty <erik@q32.com>
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 12:57:56 -0700 [thread overview]
Message-ID: <8438F081-D085-4491-8C1C-4D83FFC7DE84@voskuil.org> (raw)
In-Reply-To: <CAJowKg+OP92w+zHjy4T79tMDL5O0gboUEurhBAuWbp+npsv94A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7282 bytes --]
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: 9318 bytes --]
next prev parent reply other threads:[~2022-07-07 19:58 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 [this message]
2022-07-07 21:11 ` Erik Aronesty
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=8438F081-D085-4491-8C1C-4D83FFC7DE84@voskuil.org \
--to=eric@voskuil.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=erik@q32.com \
--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