Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu@gazeta.pl
To: "Eric Voskuil <eric@voskuil.org>,
 Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>,
 Erik Aronesty <erik@q32.com>
In-Reply-To: <96371DBA-F484-4538-9E12-9D6AB90AF22C@voskuil.org>
Date: Fri, 08 Jul 2022 06:59:30 +0200
Message-Id: <164031557-1b12d278fcfb3b555675e972f034e87d@pmq7v.m5r2.onet>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 John Carvalho <john@synonym.to>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Precedence: list

> Simply fork off an inflation coin and test your theory. I mean, that=E2=
=80=99s the only way it can happen anyway.

That would be an altcoin. But it can be done in a simpler way: we have 21 m=
illion coins. It doesn't matter if it is 21 million, if it is 100 million, =
or if it is in some normalized range from 0 to 1, where you can always know=
, what fraction of the total supply you have. So, if the total supply is co=
nstant, then it is all about proportions. And that means, you can create so=
me system on top of Bitcoin, that would move coins from users to miners. It=
 is all about that: if all coins are mined, then they can move only if user=
s will move them. So if you want to change that, it is all about encouragin=
g them to put their coins in some evil Lightning channel, when they will lo=
se their coins over time. That's how inflation works.

So, imagine some evil channel, where you can put for example 0.01 BTC, and =
have a time-based fee, so you will pay 1000 satoshis per day. Guess what: 1=
000 days, and your coins are gone! That means, if anyone want to test infla=
tion, it is possible right here and right now. Good luck to convince people=
 to use your inflationary system in a non-obfuscated way, because that's ho=
w it truly looks like: if you double coin supply, you can reach the same by=
 halving all amounts.


On 2022-07-08 02:29:20 user Eric Voskuil via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:


Value is subjective, though a constraint of 1tx per 10 minutes seems unlike=
y to create a fee of 5000x that of 5000tx. This is of course why I stated m=
y assumption. Yet this simple example should make clear that at some point =
a reduction in confirmation rate reduces reward. Otherwise a rate of zero i=
mplies infinite reward.=C2=A0


You cannot support the blanket statement (and absent any assumption) that l=
ower confirmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or =E2=
=80=9Cbetter security=E2=80=9D.


What you call a =E2=80=9Cbidding war=E2=80=9D is merely market pricing, as =
it occurs with any good. People *always* will pay as much as they will pay.=
 This is tautological. What you cannot say is how much more someone will pa=
y at any given time for any given good, until they have done it. And I=E2=
=80=99m pretty sure Bitcoin hasn=E2=80=99t done it.


You cannot prove what the price of anything will be, nor can any =E2=80=9Cp=
apers=E2=80=9D. The absurdity of S2F should have clearly demonstrated that =
by now. Value is an individual human preference.


If everyone pays 1 sat, then either miners are profitable at 1 sat, or thes=
e people are not getting confirmed (economic rationality always assumed).


The assumption of 1 sat txs filling blocks is based on a disproportionately=
 high subsidy. A subsidy of 50btc would imply somewhere in the neighborhood=
 of $200 per tx in fees today, and as $680. As that falls, fees will contin=
ue to keep miners at the same profit level. If demand does not rise to comp=
ensate (as it always has) then hash rate will fall.


Propping up hash rate with subsidy will not be =E2=80=9Cinflationary=E2=80=
=9D, as Bitcoin is a market money. Like gold it is produced at market cost.=
 Yet it will prevent Bitcoin from achieving any meaningful level of censors=
hip resistance. This of course should make people look closely at such argu=
ments.


Of course, once you have a censor, block space gets really small for those =
who want to resist the censor. Then of course only fees can offset the cens=
orship. Without fee-based tx confirmation (for anonymity), and/or with a di=
sproportionate subsidy going to the censor, a censor can operate profitably=
 and indefinitely (under the assumption of constant demand). There is no re=
ason to assume demand for censored txs wouldn=E2=80=99t even increase, give=
n the white market blessing which so many seem to want.


But there is of course no real issue here. Simply fork off an inflation coi=
n and test your theory. I mean, that=E2=80=99s the only way it can happen a=
nyway.


e


On Jul 7, 2022, at 14:11, Erik Aronesty <erik@q32.com> wrote:


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


**the ones moving=C2=A0more sats will win the top spots and will pay as muc=
h as is reasonable**


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


Without=C2=A0a bidding war for space, everyone can post 1 SAT/byte


With a bidding war for space, larger transactions will pay much higher rate=
s.=C2=A0 =C2=A0There have been a number of papers written on this but you c=
an concoct a trivial example to prove it.


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


It=E2=80=99s not clear how reducing block size changes the fee aspect of th=
e block reward. Assuming=C2=A0half 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, beca=
use of course this is just a cost that gets nulled out by difficulty =E2=80=
=94 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=E2=80=99s 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 pr=
esumably 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=E2=80=99s Law, that threshold is constantly decreasing, which w=
ill make it =C2=A0cheaper over time for more individuals to validate. But t=
he difference for miners for smaller blocks is largely inconsequential rela=
tive to their other costs.


Increasing demand is the only thing that increases double spend security (a=
nd censorship resistance assuming fee-based reward). With rising demand the=
re is rising overall hash rate, despite block reward and profit remaining c=
onstant. This makes the cost of attempting to orphan a block higher, theref=
ore 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 t=
o secure a given amount against double spend, and also implies a lower cost=
 to subsidize a censorship regime. But the latter requires a differential i=
n reward between the censor and non-censoring miners. While this could be p=
aid 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 s=
ecurity.


Yes, and these forces don't prevent double-spend / 51% attacks if the amoun=
ts involved are greater than the incentives.


In addition to "utility", lowering the block size could help prevent this i=
ssue as well... increasing fee pressure and double-spend security while red=
ucing 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@l=
ists.linuxfoundation.org> wrote:


> On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:
>
> On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev w=
rote:
>> 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 mer=
ely
> adjusts for changes in the amount of observable, non-51%-attacking, hashi=
ng
> 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 cen=
sors collaborating (one miner). Yet as difficulty falls, so does the cost o=
f 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. Conse=
quently the censor is compelled to subsidize the loss resulting from forgoi=
ng 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 o=
f demand. If that demand is insufficient to offset the censor=E2=80=99s sub=
sidy, there is no security in any scenario.

Given that the block subsidy (inflation) is paid equally to censoring and n=
on-censoring miners, it offers no security against censorship whatsoever. T=
rading fee-based block reward for inflation-based is simply trading censors=
hip resistance for the presumption of double-spend security. But of course,=
 a censor can double spend profitably in any scenario where the double spen=
d value (to the censor) exceeds that of blocks orphaned (as the censor earn=
s 100% of all block rewards).

Banks and state monies offer reasonable double spend security. Not sure tha=
t=E2=80=99s a trade worth making.

It=E2=80=99s not clear to me that Satoshi understood this relation. I=E2=80=
=99ve 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 mo=
ney. If one does not believe there is sufficient demand for such a money, t=
here is no way to reconcile that belief with a model of censorship resistan=
ce.

> We should not imbue real technology with magical qualities.

Precisely. It is economic forces (people), not technology, that provide sec=
urity.

e

>> Bitcoin does not need active economic governanance by devs or meddlers.
>
> Yes, active governance would definitely be an exploitable mechanism. On t=
he
> other hand, the status quo of the block reward eventually going away enti=
rely
> 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 volatil=
ity.
>
> Obviously 0% is too small.
>
> There's zero reason to stress about finding an "optimal" amount. An amoun=
t 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