path: root/d5/37d9525fd18b060b18db6984167a25cd902a6f

Return-Path: <eric@voskuil.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 49280C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  8 Jul 2022 00:29:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 307CF42451
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  8 Jul 2022 00:29:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 307CF42451
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com
 header.i=@voskuil-org.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=F7YVnI9f
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Q7bF0LO4eE0r
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  8 Jul 2022 00:29:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 952884244F
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com
 [IPv6:2607:f8b0:4864:20::42d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 952884244F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  8 Jul 2022 00:29:03 +0000 (UTC)
Received: by mail-pf1-x42d.google.com with SMTP id y9so7966682pff.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 07 Jul 2022 17:29:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=voskuil-org.20210112.gappssmtp.com; s=20210112;
 h=content-transfer-encoding:from:mime-version:subject:date:message-id
 :references:cc:in-reply-to:to;
 bh=KrJvnPSUbMCmTzc/HUXnTz5nZtJhJg/WY6Y7WgSBPQI=;
 b=F7YVnI9fbZMk/m2tp8xEUMUkoJeKK2/8FArO7te3LiATGpuwMFMPnSHhiz1QaIX61Z
 ksNj6SoLlsboW4f+++TaRSl8XV8E1eW1s5Ck6M9kCdpA1jmFz8D+mjtznIpGOLeXOhrP
 qnv1+YL3jtzW7+17/YFy+4nVq4voK234FtyyM/V7VS8Q//kSfLbooNR24nTC+wPdU6kE
 7LLogXlWhWKAue3kbMVy/NY6Na+owP0qZZu7ZgC1peshbOmfPTfCeLjZUg22eeBFXO+w
 MyDtZZHag3eWIs2M+8BsXHqngxpYBX/SPNKDTIHAw3vV+FfMtaRqedv7YgrcQ+v0bGC1
 FpZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:content-transfer-encoding:from:mime-version
 :subject:date:message-id:references:cc:in-reply-to:to;
 bh=KrJvnPSUbMCmTzc/HUXnTz5nZtJhJg/WY6Y7WgSBPQI=;
 b=6UHyx7ZlG2kozwnP4+d8Bz8dfTJ6MIUkfWa+AIw7T8QGKzTtsvBkNc+W1lApT2noYG
 bNNfFLuxPIygGGNSxxGaE17O2+T6WH3AjgFNQZy62X/HUAnGIESarbcUkUVt62960mfL
 A2CdOp1SusvF2F39jjIqK0q0HXFaWxYoP0RAvsY6QvPa07Wts72FhJAbZNt1P6lNx8qX
 5MeR7GPNUxo2YB/U62MNhDmvY1ZA1dpMc22S7CTHtnTYqSaj18Kg4CD36cA03F4ICoMA
 zeccpgxxxEQVBPdFYoApovUwYS3Shy/M5uVWDGQSbNXGLC7IpfsPG+FMJpOM78tGS141
 ihRA==
X-Gm-Message-State: AJIora+J0iyyw0/YMSL22T6TgdN0H8MphBY+ETPL61KIpWa6yDtjjk3W
 6tUxN14mIy1Eeh41JyRUOcyM2siRQcEo+Q==
X-Google-Smtp-Source: AGRyM1vAC1ED/MyEl0GvbumH9ygnuyihddr1OVbgZ/KbSZxWEjd5mRP5JT4FcbdSiZmXs2M1PJXqvw==
X-Received: by 2002:a63:194c:0:b0:408:a9d1:400c with SMTP id
 12-20020a63194c000000b00408a9d1400cmr705978pgz.559.1657240142561; 
 Thu, 07 Jul 2022 17:29:02 -0700 (PDT)
Received: from smtpclient.apple ([2600:380:801f:6202:f47e:c7ca:fad6:7d1])
 by smtp.gmail.com with ESMTPSA id
 d13-20020a170902654d00b0016c0b0fe1c6sm3035801pln.73.2022.07.07.17.29.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 07 Jul 2022 17:29:02 -0700 (PDT)
Content-Type: multipart/alternative;
 boundary=Apple-Mail-ABE9413A-2D40-4779-883D-5190C8D482FB
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Thu, 7 Jul 2022 17:28:36 -0700
Message-Id: <96371DBA-F484-4538-9E12-9D6AB90AF22C@voskuil.org>
References: <CAJowKgJGfkdCjWUnUyWZ9rgnWFOVYg=aizBwC2wEbMxohRMvZg@mail.gmail.com>
In-Reply-To: <CAJowKgJGfkdCjWUnUyWZ9rgnWFOVYg=aizBwC2wEbMxohRMvZg@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
X-Mailer: iPhone Mail (19F77)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 John Carvalho <john@synonym.to>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2022 00:29:06 -0000


--Apple-Mail-ABE9413A-2D40-4779-883D-5190C8D482FB
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Value is subjective, though a constraint of 1tx per 10 minutes seems unlikey=
 to create a fee of 5000x that of 5000tx. This is of course why I stated my a=
ssumption. Yet this simple example should make clear that at some point a re=
duction in confirmation rate reduces reward. Otherwise a rate of zero implie=
s infinite reward.=20

You cannot support the blanket statement (and absent any assumption) that lo=
wer confirmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or =E2=80=9C=
better security=E2=80=9D.

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

You cannot prove what the price of anything will be, nor can any =E2=80=9Cpa=
pers=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 these=
 people are not getting confirmed (economic rationality always assumed).

The assumption of 1 sat txs filling blocks is based on a disproportionately h=
igh 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 continue t=
o keep miners at the same profit level. If demand does not rise to compensat=
e (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 censorship r=
esistance. This of course should make people look closely at such arguments.=


Of course, once you have a censor, block space gets really small for those w=
ho want to resist the censor. Then of course only fees can offset the censor=
ship. Without fee-based tx confirmation (for anonymity), and/or with a dispr=
oportionate subsidy going to the censor, a censor can operate profitably and=
 indefinitely (under the assumption of constant demand). There is no reason t=
o assume demand for censored txs wouldn=E2=80=99t even increase, given the w=
hite market blessing which so many seem to want.

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

e

> On Jul 7, 2022, at 14:11, Erik Aronesty <erik@q32.com> wrote:
>=20
> =EF=BB=BF
> The relationship between block size and fees is not remotely linear.   In a=
 restricted environment, the fee rewards are much higher.
>=20
> **the ones moving more sats will win the top spots and will pay as much as=
 is reasonable**
>=20
> Smaller blocks produce better security for the network both in validation,=
 and in fees.
>=20
> Without a bidding war for space, everyone can post 1 SAT/byte
>=20
> With a bidding war for space, larger transactions will pay much higher rat=
es.   There have been a number of papers written on this but you can concoct=
 a trivial example to prove it.
>=20
>=20
>> 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 t=
he block reward. Assuming half the space implies twice the fee per avg tx th=
e reward remains constant.
>>=20
>> Any additional cost of processing more or less bytes would not matter, be=
cause 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.
>>=20
>> The reason for smaller vs. larger blocks is to ensure that individuals ca=
n afford to validate. That=E2=80=99s a threshold criteria.
>>=20
>> Given unlimited size blocks, miners would still have to fix a point in ti=
me to mine, gathering as much fee as they can optimize in some time period p=
resumably less than 10 minutes. The produces a limit to transaction volume, y=
et neither reward nor profit would be affected given the above assumptions. T=
he difference would be in a tradeoff of per tx fee against the threshold.
>>=20
>> Given Moore=E2=80=99s Law, that threshold is constantly decreasing, which=
 will make it  cheaper over time for more individuals to validate. But the d=
ifference for miners for smaller blocks is largely inconsequential relative t=
o their other costs.
>>=20
>> Increasing demand is the only thing that increases double spend security (=
and censorship resistance assuming fee-based reward). With rising demand the=
re is rising overall hash rate, despite block reward and profit remaining co=
nstant. This makes the cost of attempting to orphan a block higher, therefor=
e lowering the depth/time requirement implied to secure a given tx amount.
>>=20
>> 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 cos=
t 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 pa=
id in side fees, that is a significant anonymity issue.
>>=20
>> e
>>=20
>>>> On Jul 7, 2022, at 10:37, Erik Aronesty <erik@q32.com> wrote:
>>>>=20
>>> =EF=BB=BF
>>> > > We should not imbue real technology with magical qualities.
>>>=20
>>> > Precisely. It is economic forces (people), not technology, that provid=
e security.
>>>=20
>>> Yes, and these forces don't prevent double-spend / 51% attacks if the am=
ounts involved are greater than the incentives.
>>>=20
>>> In addition to "utility", lowering the block size could help prevent thi=
s issue as well... increasing fee pressure and double-spend security while r=
educing the burden on node operators.
>>>=20
>>> Changes to inflation are, very likely, off the table.
>>>=20
>>> =20
>>>=20
>>>> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:
>>>>=20
>>>>=20
>>>> > On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org> wrote:
>>>> >=20
>>>> > =EF=BB=BFOn Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via b=
itcoin-dev wrote:
>>>> >> Billy,
>>>> >>=20
>>>> >> Proof of work and the difficulty adjustment function solve literally=

>>>> >> everything you are talking about already.
>>>> >=20
>>>> > Unfortunately you are quite wrong: the difficulty adjustment function=
 merely
>>>> > adjusts for changes in the amount of observable, non-51%-attacking, h=
ashing
>>>> > power. In the event of a chain split, the difficulty adjustment funct=
ion does
>>>> > nothing; against a 51% attacker, the difficulty adjustment does nothi=
ng;
>>>> > against a censor, the difficulty adjustment does nothing.
>>>>=20
>>>> Consider falling hash rate due to a perpetual 51% attack. Difficulty fa=
lls, possibly to min difficulty if all non-censors stop mining and with all c=
ensors collaborating (one miner). Yet as difficulty falls, so does the cost o=
f countering the censor. At min difficulty everyone can CPU mine again.
>>>>=20
>>>> Given the presumption that fees rise on unconfirmed transactions, there=
 is inherent economic incentive to countering at any level of difficulty. Co=
nsequently the censor is compelled to subsidize the loss resulting from forg=
oing higher fee transactions that are incentivizing its competition.
>>>>=20
>>>> With falling difficulty this incentive is compounded.
>>>>=20
>>>> Comparisons of security in different scenarios presume a consistent lev=
el of demand. If that demand is insufficient to offset the censor=E2=80=99s s=
ubsidy, there is no security in any scenario.
>>>>=20
>>>> Given that the block subsidy (inflation) is paid equally to censoring a=
nd non-censoring miners, it offers no security against censorship whatsoever=
. Trading fee-based block reward for inflation-based is simply trading censo=
rship 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 earns=
 100% of all block rewards).
>>>>=20
>>>> Banks and state monies offer reasonable double spend security. Not sure=
 that=E2=80=99s a trade worth making.
>>>>=20
>>>> 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, th=
ere is no way to reconcile that belief with a model of censorship resistance=
.
>>>>=20
>>>> > We should not imbue real technology with magical qualities.
>>>>=20
>>>> Precisely. It is economic forces (people), not technology, that provide=
 security.
>>>>=20
>>>> e
>>>>=20
>>>> >> Bitcoin does not need active economic governanance by devs or meddle=
rs.
>>>> >=20
>>>> > Yes, active governance would definitely be an exploitable mechanism. O=
n the
>>>> > other hand, the status quo of the block reward eventually going away e=
ntirely
>>>> > is obviously a risky state change too.
>>>> >=20
>>>> >>>> There is also zero agreement on how much security would constitute=
 such
>>>> >>> an optimum.
>>>> >>>=20
>>>> >>> This is really step 1. We need to generate consensus on this long b=
efore
>>>> >>> the block subsidy becomes too small. Probably in the next 10-15 yea=
rs. I
>>>> >>> wrote a paper
>>>> >=20
>>>> > The fact of the matter is that the present amount of security is abou=
t 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 vol=
atility.
>>>> >=20
>>>> > Obviously 0% is too small.
>>>> >=20
>>>> > There's zero reason to stress about finding an "optimal" amount. An a=
mount low
>>>> > enough to be easily affordable, but non-zero, is fine. 1% would be fi=
ne; 0.5%
>>>> > would probably be fine; 0.1% would probably be fine.
>>>> >=20
>>>> > Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 3=
1% tax on
>>>> > savings; 0.1% works out to be 7.2%
>>>> >=20
>>>> > These are all amounts that are likely to be dwarfed by economic shift=
s.
>>>> >=20
>>>> > --=20
>>>> > 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

--Apple-Mail-ABE9413A-2D40-4779-883D-5190C8D482FB
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr"><di=
v style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Value is subject=
ive, though a constraint of 1tx per 10 minutes seems unlikey to create a fee=
 of 5000x that of 5000tx. This is of course why I stated my assumption. Yet t=
his simple example should make clear that at some point a reduction in confi=
rmation rate reduces reward. Otherwise a rate of zero implies infinite rewar=
d.&nbsp;</div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"=
><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Yo=
u cannot support the blanket statement (and absent any assumption) that lowe=
r confirmation rates produce =E2=80=9Cmuch higher fees=E2=80=9D or =E2=80=9C=
better security=E2=80=9D.</div><div style=3D"caret-color: rgb(0, 0, 0); colo=
r: rgb(0, 0, 0);"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: r=
gb(0, 0, 0);">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 th=
ey will pay. This is tautological. What you cannot say is how much more some=
one will pay at any given time for any given good, until they have done it. A=
nd I=E2=80=99m pretty sure Bitcoin hasn=E2=80=99t done it.</div><div style=3D=
"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style=3D"ca=
ret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">You cannot prove what the pri=
ce of anything will be, nor can any =E2=80=9Cpapers=E2=80=9D. The absurdity o=
f S2F should have clearly demonstrated that by now. Value is an individual h=
uman preference.</div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0,=
 0, 0);"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0,=
 0);">If everyone pays 1 sat, then either miners are profitable at 1 sat, or=
 these people are not getting confirmed (economic rationality always assumed=
).</div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br><=
/div><div style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">The assu=
mption of 1 sat txs filling blocks is based on a disproportionately high sub=
sidy. A subsidy of 50btc would imply somewhere in the neighborhood of $200 p=
er tx in fees today, and as $680. As that falls, fees will continue to keep m=
iners at the same profit level. If demand does not rise to compensate (as it=
 always has) then hash rate will fall.</div><div style=3D"caret-color: rgb(0=
, 0, 0); color: rgb(0, 0, 0);"><br></div><div style=3D"caret-color: rgb(0, 0=
, 0); color: rgb(0, 0, 0);">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 p=
roduced at market cost. Yet it will prevent Bitcoin from achieving any meani=
ngful level of censorship resistance. This of course should make people look=
 closely at such arguments.</div><div style=3D"caret-color: rgb(0, 0, 0); co=
lor: rgb(0, 0, 0);"><br></div><div style=3D"caret-color: rgb(0, 0, 0); color=
: rgb(0, 0, 0);">Of course, once you have a censor, block space gets really s=
mall for those who want to resist the censor. Then of course only fees can o=
ffset the censorship. Without fee-based tx confirmation (for anonymity), and=
/or with a disproportionate subsidy going to the censor, a censor can operat=
e profitably and indefinitely (under the assumption of constant demand). The=
re is no reason to assume demand for censored txs wouldn=E2=80=99t even incr=
ease, given the white market blessing which so many seem to want.</div><div s=
tyle=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div styl=
e=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">But there is of course=
 no real issue here. Simply fork off an inflation coin and test your theory.=
 I mean, that=E2=80=99s the only way it can happen anyway.</div><div style=3D=
"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div><div style=3D"ca=
ret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">e</div><div style=3D"caret-co=
lor: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></div></div><div dir=3D"ltr"><b=
lockquote type=3D"cite">On Jul 7, 2022, at 14:11, Erik Aronesty &lt;erik@q32=
.com&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div dir=
=3D"ltr">=EF=BB=BF<div dir=3D"ltr">The relationship between block size and f=
ees is not remotely linear.&nbsp; &nbsp;In a restricted environment, the fee=
 rewards are much higher.<div><div><div><div><br></div></div><div>**the ones=
 moving&nbsp;more sats will win the top spots and will pay as much as is rea=
sonable**</div></div><div><br></div></div><div>Smaller blocks produce better=
 security for the network both in validation, and in fees.</div><div><br></d=
iv><div>Without&nbsp;a bidding war for space, everyone can post 1 SAT/byte</=
div><div><br></div><div>With a bidding war for space, larger transactions wi=
ll pay much higher rates.&nbsp; &nbsp;There have been a number of papers wri=
tten on this but you can concoct a trivial example to prove it.</div><div><b=
r></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Thu, Jul 7, 2022 at 3:58 PM Eric Voskuil &lt;<a href=3D"mailto:eri=
c@voskuil.org">eric@voskuil.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div dir=3D"auto"><div dir=3D"ltr"></div><div d=
ir=3D"ltr">It=E2=80=99s not clear how reducing block size changes the fee as=
pect of the block reward. Assuming&nbsp;<span style=3D"color:rgb(0,0,0)">hal=
f the space implies twice the fee per avg tx the reward remains constant.</s=
pan></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Any additional cost of=
 processing more or less bytes would not matter, because of course this is j=
ust a cost that gets nulled out by difficulty =E2=80=94 average profit (net i=
ncome) is the cost of capital.</div><div dir=3D"ltr"><br></div><div dir=3D"l=
tr">The reason for smaller vs. larger blocks is to ensure that individuals c=
an afford to validate. That=E2=80=99s a threshold criteria.</div><div dir=3D=
"ltr"><br></div><div dir=3D"ltr">Given unlimited size blocks, miners would s=
till have to fix a point in time to mine, gathering as much fee as they can o=
ptimize in some time period presumably less than 10 minutes. The produces a l=
imit to transaction volume, yet neither reward nor profit would be affected g=
iven the above assumptions. The difference would be in a tradeoff of per tx f=
ee against the threshold.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">G=
iven Moore=E2=80=99s Law, that threshold is constantly decreasing, which wil=
l make it &nbsp;cheaper over time for more individuals to validate. But the d=
ifference for miners for smaller blocks is largely inconsequential relative t=
o their other costs.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Increa=
sing demand is the only thing that increases double spend security (and cens=
orship resistance assuming fee-based reward). With rising demand there is ri=
sing overall hash rate, despite block reward and profit remaining constant. T=
his makes the cost of attempting to orphan a block higher, therefore lowerin=
g the depth/time requirement implied to secure a given tx amount.</div><div d=
ir=3D"ltr"><br></div><div dir=3D"ltr">These are the two factors, demand and t=
ime. Less demand implies more time to secure a given amount against double s=
pend, and also implies a lower cost to subsidize a censorship regime. But th=
e latter requires a differential in reward between the censor and non-censor=
ing miners. While this could be paid in side fees, that is a significant ano=
nymity issue.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">e</div><div d=
ir=3D"ltr"><br><blockquote type=3D"cite">On Jul 7, 2022, at 10:37, Erik Aron=
esty &lt;<a href=3D"mailto:erik@q32.com" target=3D"_blank">erik@q32.com</a>&=
gt; wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div dir=3D"l=
tr">=EF=BB=BF<div dir=3D"ltr"><div><span style=3D"color:rgb(80,0,80)">&gt; &=
gt; We should not imbue real technology with magical qualities.</span><br></=
div><div><span style=3D"color:rgb(80,0,80)"><br></span>&gt; Precisely. It is=
 economic forces (people), not technology, that provide security.<font color=
=3D"#888888"><br></font></div><div><br></div><div>Yes, and these forces don'=
t prevent double-spend / 51% attacks if the amounts involved are greater tha=
n the incentives.</div><div><br></div><div>In addition to "utility", lowerin=
g the block size could help prevent this issue as well... increasing fee pre=
ssure and double-spend security while reducing the burden on node operators.=
</div><div><br></div><div>Changes to inflation are, very likely, off the tab=
le.</div><div><br></div><div>&nbsp;</div></div><br><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 7, 2022 at 12:24 PM Eric=
 Voskuil via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
&gt; On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>&gt; wrote:<br>
&gt; <br>
&gt; =EF=BB=BFOn Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bi=
tcoin-dev wrote:<br>
&gt;&gt; Billy,<br>
&gt;&gt; <br>
&gt;&gt; Proof of work and the difficulty adjustment function solve literall=
y<br>
&gt;&gt; everything you are talking about already.<br>
&gt; <br>
&gt; Unfortunately you are quite wrong: the difficulty adjustment function m=
erely<br>
&gt; adjusts for changes in the amount of observable, non-51%-attacking, has=
hing<br>
&gt; power. In the event of a chain split, the difficulty adjustment functio=
n does<br>
&gt; nothing; against a 51% attacker, the difficulty adjustment does nothing=
;<br>
&gt; against a censor, the difficulty adjustment does nothing.<br>
<br>
Consider falling hash rate due to a perpetual 51% attack. Difficulty falls, p=
ossibly to min difficulty if all non-censors stop mining and with all censor=
s collaborating (one miner). Yet as difficulty falls, so does the cost of co=
untering the censor. At min difficulty everyone can CPU mine again.<br>
<br>
Given the presumption that fees rise on unconfirmed transactions, there is i=
nherent economic incentive to countering at any level of difficulty. Consequ=
ently the censor is compelled to subsidize the loss resulting from forgoing h=
igher fee transactions that are incentivizing its competition.<br>
<br>
With falling difficulty this incentive is compounded.<br>
<br>
Comparisons of security in different scenarios presume a consistent level of=
 demand. If that demand is insufficient to offset the censor=E2=80=99s subsi=
dy, there is no security in any scenario.<br>
<br>
Given that the block subsidy (inflation) is paid equally to censoring and no=
n-censoring miners, it offers no security against censorship whatsoever. Tra=
ding fee-based block reward for inflation-based is simply trading censorship=
 resistance for the presumption of double-spend security. But of course, a c=
ensor can double spend profitably in any scenario where the double spend val=
ue (to the censor) exceeds that of blocks orphaned (as the censor earns 100%=
 of all block rewards).<br>
<br>
Banks and state monies offer reasonable double spend security. Not sure that=
=E2=80=99s a trade worth making.<br>
<br>
It=E2=80=99s not clear to me that Satoshi understood this relation. I=E2=80=99=
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 w=
hat transitions Bitcoin from a censorable to a censorship resistant money. I=
f 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.<br>
<br>
&gt; We should not imbue real technology with magical qualities.<br>
<br>
Precisely. It is economic forces (people), not technology, that provide secu=
rity.<br>
<br>
e<br>
<br>
&gt;&gt; Bitcoin does not need active economic governanance by devs or meddl=
ers.<br>
&gt; <br>
&gt; Yes, active governance would definitely be an exploitable mechanism. On=
 the<br>
&gt; other hand, the status quo of the block reward eventually going away en=
tirely<br>
&gt; is obviously a risky state change too.<br>
&gt; <br>
&gt;&gt;&gt;&gt; There is also zero agreement on how much security would con=
stitute such<br>
&gt;&gt;&gt; an optimum.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; This is really step 1. We need to generate consensus on this lo=
ng before<br>
&gt;&gt;&gt; the block subsidy becomes too small. Probably in the next 10-15=
 years. I<br>
&gt;&gt;&gt; wrote a paper<br>
&gt; <br>
&gt; The fact of the matter is that the present amount of security is about 1=
.7% of<br>
&gt; the total coin supply/year, and Bitcoin seems to be working fine. 1.7% i=
s also<br>
&gt; already an amount low enough that it's much smaller than economic volat=
ility.<br>
&gt; <br>
&gt; Obviously 0% is too small.<br>
&gt; <br>
&gt; There's zero reason to stress about finding an "optimal" amount. An amo=
unt low<br>
&gt; enough to be easily affordable, but non-zero, is fine. 1% would be fine=
; 0.5%<br>
&gt; would probably be fine; 0.1% would probably be fine.<br>
&gt; <br>
&gt; Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31=
% tax on<br>
&gt; savings; 0.1% works out to be 7.2%<br>
&gt; <br>
&gt; These are all amounts that are likely to be dwarfed by economic shifts.=
<br>
&gt; <br>
&gt; -- <br>
&gt; <a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">=
https://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D=
"noreferrer" target=3D"_blank">petertodd.org</a><br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/m=
ailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</div></blockquote></div></blockquote></div>
</div></blockquote></body></html>=

--Apple-Mail-ABE9413A-2D40-4779-883D-5190C8D482FB--