Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: jk_14@op.pl
To: bitcoin-dev@lists.linuxfoundation.org
Date: Tue, 27 Dec 2022 16:34:07 +0100
Message-Id: <173647633-76b3b19c83c720cc30cb8fcb603b5251@pmq5v.m5r2.onet>
X-ONET_PL-MDA-SEGREGATION: 0
X-Mailman-Approved-At: Tue, 27 Dec 2022 15:41:42 +0000
Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission
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: Tue, 27 Dec 2022 15:34:21 -0000


It seems like the more elegant solution could be by using a chainwork param=
eter instead.
i.e. comparison just before halving - if the last 210,000 block interval ha=
s a higher chainwork difference between the begining and the end of interval
than any other such inter-halving interval before.

LIttle digression yet:
A system in which all users participate in ensuring its security looks bett=
er than one in which only some (i.e. active) of them participate (and passi=
ve stakeholders are de facto free riders)
In my opinion this concept above is only the complement of currently missin=
g mechanism: achieving equilibrium regarding costs of security between two =
parties with opposing interests.
It's easy to understand and - most important - it has no hardcoded value of=
 tail emission - what is the clear proof it is based on a free market.
And last but not least, if someone is 100% sure that income from transactio=
ns will takeover security support from block subsidy - accepting such propo=
sal is like putting the money where the mouth is: this safety measure will =
never be triggered, then (no risk of fork)


Best Regards
Jaroslaw


W dniu 2022-12-23 20:29:20 u=C5=BCytkownik Jaroslaw via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> napisa=C5=82:
> =

Necessary or not - it doesn't hurt to plan the robust model, just in case. =
The proposal is:

Let every 210,000 the code calculate the average difficulty of 100 last ret=
argets (100 fit well in 210,000 / 2016 =3D 104.166)
and compare with the maximum of all such values calculated before, every 21=
0,000 blocks:


if average_diff_of_last_100_retargets > maximum_of_all_previous_average_dif=
fs
	do halving
else
	do nothing


This way:

1. system cannot be played
2. only in case of destructive halving: system waits for the recovery of ne=
twork security


Best Regards
Jaroslaw
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev