Content-Type: multipart/mixed;
 boundary=Apple-Mail-76221C1E-812B-468B-B34D-D0497FB044ED
Content-Transfer-Encoding: 7bit
From: Eric Voskuil <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Thu, 7 Jul 2022 09:24:26 -0700
Message-Id: <F6CAB95E-2EDD-42E5-8C80-1E3818D51574@voskuil.org>
References: <Ysbp2QclWW7NzfrS@petertodd.org>
In-Reply-To: <Ysbp2QclWW7NzfrS@petertodd.org>
To: Peter Todd <pete@petertodd.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Cc: John Carvalho <john@synonym.to>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Precedence: list


--Apple-Mail-76221C1E-812B-468B-B34D-D0497FB044ED
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev <bitcoin-dev@lists.li=
nuxfoundation.org> wrote:
>=20
> =EF=BB=BFOn Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitco=
in-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 mere=
ly
> adjusts for changes in the amount of observable, non-51%-attacking, hashin=
g
> power. In the event of a chain split, the difficulty adjustment function d=
oes
> 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, 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.

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.

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=E2=80=99s subsi=
dy, there is no security in any scenario.

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).

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

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.

> We should not imbue real technology with magical qualities.

Precisely. It is economic forces (people), not technology, that provide secu=
rity.

e

>> Bitcoin does not need active economic governanance by devs or meddlers.
>=20
> Yes, active governance would definitely be an exploitable mechanism. On th=
e
> other hand, the status quo of the block reward eventually going away entir=
ely
> 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 before=

>>> the block subsidy becomes too small. Probably in the next 10-15 years. I=

>>> wrote a paper
>=20
> 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 a=
lso
> already an amount low enough that it's much smaller than economic volatili=
ty.
>=20
> Obviously 0% is too small.
>=20
> 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.
>=20
> Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% t=
ax on
> savings; 0.1% works out to be 7.2%
>=20
> These are all amounts that are likely to be dwarfed by economic shifts.
>=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

--Apple-Mail-76221C1E-812B-468B-B34D-D0497FB044ED
Content-Type: application/octet-stream;
	name=signature.asc;
	x-apple-part-url=A962793E-D2B4-4B43-AFE5-A0C2EB768DD8
Content-Disposition: attachment;
	filename=signature.asc
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmLG6dcACgkQLly11TVR
LzfHRQ//dCSdHeUKwvpEN4kUI5n8riCjOzFbzf7DtGjZ8mr5JKk99Y5dvNSt43E0
x5B+fp0jt6NPoQkQ9d/gMChdloyeCpIzI0q5t6upVWWIejE/lE109OhaZJxW2/Fm
8iDZjPbx0agvzxktmsEYoOQ7UHzEz1J78GrhlE3uuR80QY/8YwNvL6348Ycxgzi9
0XdZX5yf9grl1gAJldx5icTHIo0hNEpWQZye2SnLda9NrLPSKgE5UcDSIEIBJBfv
F5HELWV5Gf0F/ruxC70kXUMx+qlIk/Nao6bvEy31YkYStA3GlWo5ZmnuyvdnQ4yr
JuZwQJw/R2RiiOYsK8TMbB7kXwYD3Gzt6QW+bhXpty3K0sKT/70FT2VE+NdMXFNT
EqxJK9AYuUK3WTLZSOda9Ny/eBK3RDMkWbXdxMXAPOsW86BC3j5+KzzSSmIVpU0j
URaqcE0XfXWBvCz+LFH8Mvkxi7xS9kro/XXXzLVO6ZSrpw8z5MmMPy6HdruWZbp2
VpLcaANBFxGUrFbh/zvMJB03vAU8peRtfwWodn9ynWymb38DlZsBZyg2uejnKjYv
ghPGxPdAEXbm/zSWmnVU9jhN/0+7DA7+r0pk8+l6t4iOdqu46l/K8CRxkwKlIOSA
bcTYYeZthY7iTEABS+RNAx/vzP54bxywpPg9HGy/zKmKCT/sDpE=
=I1Dy
-----END PGP SIGNATURE-----

--Apple-Mail-76221C1E-812B-468B-B34D-D0497FB044ED--