Feedback-ID: i525146e8:Fastmail
Date: Fri, 30 Dec 2022 18:28:58 -0500
From: Peter Todd <pete@petertodd.org>
To: jk_14@op.pl
Message-ID: <Y690OjY0MA/YQ9IL@petertodd.org>
References: <173552838-a7412589a40ea770709d0b227b056bd3@pmq5v.m5r2.onet>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="Bg7LtgAK0yX9Bs4Z"
Content-Disposition: inline
In-Reply-To: <173552838-a7412589a40ea770709d0b227b056bd3@pmq5v.m5r2.onet>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission
Precedence: list


--Bg7LtgAK0yX9Bs4Z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 23, 2022 at 07:43:36PM +0100, jk_14@op.pl wrote:
>=20
> Necessary or not - it doesn't hurt to plan the robust model, just in case=
=2E The proposal is:
>=20
> Let every 210,000 the code calculate the average difficulty of 100 last r=
etargets (100 fit well in 210,000 / 2016 =3D 104.166)
> and compare with the maximum of all such values calculated before, every =
210,000 blocks:
>=20
>=20
> if average_diff_of_last_100_retargets > maximum_of_all_previous_average_d=
iffs
> 	do halving
> else
> 	do nothing
>=20
>=20
> This way:
>=20
> 1. system cannot be played
> 2. only in case of destructive halving: system waits for the recovery of =
network security

First of all - while I suspct you already understand this issue - I should
point out the following:

The immediate danger we have with halvings is that in a competitive market,
profit margins tend towards marginal costs - the cost to produce an additio=
nal
unit of production - rather than total costs - the cost necessary to recover
prior and future expenses. Since the halving is a sudden shock to the syste=
m,
under the right conditions we could have a significant amount of hashing po=
wer
just barely able to afford to hash prior to the halving, resulting in all t=
hat
hashing power immediately having to shut down and fees increasing dramatica=
lly,
and likely, chaotically.  Your proposal does not address that problem as it=
 can
only measure difficulty prior to the halving point.


Other than that problem, I agree that this proposal would, at least in theo=
ry,
be a positive improvement on the status quo. But it is a hard fork and I do=
n't
think there is much hope for such hard forks to be implemented. I believe t=
hat
a demmurrage soft-fork, implemented via a storage fee averaged out over many
future blocks, has a much more plausible route towards implementation.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--Bg7LtgAK0yX9Bs4Z
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmOvdDgACgkQLly11TVR
LzcF7g//Z9S+Zj5O95i/1zET8cZknKkCfMqG/qWerTq1/vQK8tzYwSuxVdph6sCx
TMz/rdrvl2GoJa8fn0XpMqVUHaq3hWveqAy2Mg6M3O2v+lInyJONpWolucKfI2YY
ve/npVymPnYkW3ccgugBfgQBPyNbsI05WgZr7SAWeAiVF7rXAoPypsO7UaN/0Bzy
kc6LekSoil27kRaPbScQYuf1YxQOxKOdybOR69bjlXp/N77hE9XQOPlGwSOFZufr
s1nCZP4M2JriZ6E73P9fhDt6/8IYrwRJt8NP/uj8j0Q3INGc0UZxYFgYwJv6QuX6
wyHxqWtas3+lbZbf+5hVLmGMjmb3qq9Hn7anLZssuzCma7yYvfW4uJiCWIJlpDU9
sGmQU9lk9trdeXTJp2uGaB66ih9RzFMBGlZyBmfUfHFWcIsc3qdvoaYN9rDD1r+S
jrQSbNB+PyHkiH1o2kRpQJGTYHgJE66N0rjLvK0UT5kXMFSxgFTj8nTwRgeffMXP
IuzuO4tMcvr3383/XH2QUt+RFQ0vFehin9Ccy80/Uqv5obqAf0xZdjch500dMcNi
mhd48dEsZh3zlRwX8SXlxzUgzzwSsrdO2u2MgG3Oyq1KMzSiT1MBL7lI7xOWLpEJ
cGsCTH8OaP7R2hC4q6eFqs2HohJfJIFhqqeS7CXlCCsoRL9LSyU=
=qJyA
-----END PGP SIGNATURE-----

--Bg7LtgAK0yX9Bs4Z--