path: root/d0/67a8ce85544bcbfc5dd17b18b1f6e1db15608f

Return-Path: <jk_14@op.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 54DF9C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  1 Jan 2023 21:23:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 1B5404033A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  1 Jan 2023 21:23:50 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1B5404033A
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256
 header.s=2011 header.b=IRwGZAww
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-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 VcdS4OP6ah5q
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  1 Jan 2023 21:23:48 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CBC41402DD
Received: from smtpo91.poczta.onet.pl (smtpo91.poczta.onet.pl
 [213.180.149.144])
 by smtp4.osuosl.org (Postfix) with ESMTPS id CBC41402DD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  1 Jan 2023 21:23:47 +0000 (UTC)
Received: from pmq1v.m5r2.onet (pmq1v.m5r2.onet [10.174.32.67])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4NlX6h0fg4z1x6Y;
 Sun,  1 Jan 2023 22:23:40 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011;
 t=1672608220; bh=KHbhmexbAVx5YbILH72QPr/EwCotRX5Zmpei87bfxW4=;
 h=From:To:Date:Subject:From;
 b=IRwGZAwwQWDVVo472Rlcod5Z/+fmCq9DpTgZFNGki9ROoWG/hthwWwKKuM/QJhVjx
 g+PvZJJ8x+U+I9M6Hs/ikmK/OKcXQAZjWLnjB1K5Nntbrr8wxQlRRSkqLMRirZLIAS
 5Kk9SyBNaKvLwyQHQMXlbBzs4HYpN1otqxBzMy18=
Content-Type: multipart/alternative;
 boundary="===============3965289198520836362=="
MIME-Version: 1.0
Received: from [89.64.64.238] by pmq1v.m5r2.onet via HTTP id ;
 Sun, 01 Jan 2023 22:23:40 +0100
From: jk_14@op.pl
X-Priority: 3
To: Billy Tetrud <billy.tetrud@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Sun, 01 Jan 2023 22:23:37 +0100
Message-Id: <174623371-de649b28ce46dea2e588f2ef794decdb@pmq1v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <jk_144@onet.pl>;89.64.64.238;PL;2
X-ONET_PL-MDA-SEGREGATION: 0
X-Mailman-Approved-At: Sun, 01 Jan 2023 21:42:31 +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: Sun, 01 Jan 2023 21:23:50 -0000

This is a multi-part message in MIME format.
--===============3965289198520836362==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Yes, the idea is:
if mining activity is growing - let's execute consecutive halvings
but if miner exodus has happened - let's delay next halving until mining ac=
tivity is recovered to previous levels
If it gets to the point where a sudden drop in mining difficulty happens - =
delaying the next halving may be not sufficient to correct, but is surely b=
etter than not delaying it.
While Bitcoin is better and better money with every halving in comparision =
to other types of money - there is non-zero risk that people will hoard it =
more and more, according to old Gresham's law ("HODL"). And this way decrea=
sing liquidity / transactions volume. The positive feedback loop - is my re=
al concern here.
Regarding the relationship between difficulty and security - I fully agree.
But ASIC technology is already matured. And also any technology breakthroug=
h is a short event within 4 years period.
So growth of difficulty could be gained by technology breakthrough, but any=
 sudden drop of difficulty would be always an issue, while there is no such=
 thing as: ASIC technology regression.
Obviously, not complicated solution would be better than complicated one.
=C2=A0
=C2=A0
W dniu 2022-12-30 19:21:10 u=C5=BCytkownik Billy Tetrud <billy.tetrud@gmail=
.com> napisa=C5=82:
If the idea is to ensure that a catastrophic miner exodus doesn't happen, t=
he "difference" you're calculating should only care about downward differen=
ces. Upward differences indicate more mining activity and so shouldn't caus=
e a halving skip. =C2=A0
But I don't think any scheme like this that only acts on the basis of diffi=
culty will be sufficient. If it gets to the point where a sudden drop in mi=
ning difficulty happens, it is very likely that simply delaying the next ha=
lving or even ending halving all together will not be sufficient to correct=
 for whatever is causing hashrate to tank. There is also the danger of simp=
le difficulty stagnation, which this mechanism wouldn't detect.=C2=A0
=C2=A0
The relationship between difficulty and security becomes less and less pred=
ictable the longer you want to look ahead. There's no long term relation be=
tween difficulty and any reasonable security target. A security target migh=
t be something like "no colluding group with less than $1 trillion dollars =
at their disposal could successfully 51% attack the network (with a probabi=
lity of blah blah)". There is no way to today program in any code that dete=
cts based on difficult alone when that criteria is violated. You would have=
 to program in assumptions about the cost of hashrate projected into the fu=
ture.
=C2=A0
I can't think of any robust automatic way to do this. I think to a certain =
degree, it will have to be a change that happens in a fork of some kind (so=
ft or hard) periodically (every 10 years? 30 years?). The basic relations n=
eeded is really the cost in Bitcoin of the security target (ie the minimum =
number of Bitcoin it should take to 51% attack the system) and the cost in =
Bitcoin of acquiring a unit of hashrate. This could be simply input into th=
e code, or could use some complicated oracle system. But with that relation=
, the system could be programmed to calculate the difficulty necessary to k=
eep the system secure.
=C2=A0
Once that is in place, the system could automatically adjust the subsidy up=
 or down to attract more or less miners, or it could adjust the block size =
up or down to change the fee market such that more or less total fees are c=
ollected each block to attract more or less miners.=C2=A0
On Tue, Dec 27, 2022, 09:41 Jaroslaw via bitcoin-dev <bitcoin-dev@lists.lin=
uxfoundation.org> wrote:
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
=C2=A0 =C2=A0 =C2=A0 =C2=A0 do halving
else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--===============3965289198520836362==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div><br />Yes, the idea is:<br />if mining activity is growing - let's exe=
cute consecutive halvings<br />but if miner exodus has happened - let's del=
ay next halving until mining activity is recovered to previous levels<br />=
<br />If it gets to the point where a sudden drop in mining difficulty happ=
ens - delaying the next halving may be not sufficient to correct, but is su=
rely better than not delaying it.<br /><br />While Bitcoin is better and be=
tter money with every halving in comparision to other types of money - ther=
e is non-zero risk that people will hoard it more and more, according to ol=
d Gresham's law ("HODL"). And this way decreasing liquidity / transactions =
volume. The positive feedback loop - is my real concern here.<br /><br />Re=
garding the relationship between difficulty and security - I fully agree.<b=
r />But ASIC technology is already matured. And also any technology breakth=
rough is a short event within 4 years period.<br />So growth of difficulty =
could be gained by technology breakthrough, but any sudden drop of difficul=
ty would be always an issue, while there is no such thing as: ASIC technolo=
gy regression.</div>
<div><br />Obviously, not complicated solution would be better than complic=
ated one.</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>W dniu 2022-12-30 19:21:10 u=C5=BCytkownik Billy Tetrud &lt;billy.tetr=
ud@gmail.com&gt; napisa=C5=82:</div>
<blockquote style=3D"margin-right: 0; margin-left: 7px; border-left: 2px so=
lid orange; padding-left: 8px;">
<div dir=3D"ltr">
<div dir=3D"auto">If the idea is to ensure that a catastrophic miner exodus=
 doesn't happen, the "difference" you're calculating should only care about=
 downward differences. Upward differences indicate more mining activity and=
 so shouldn't cause a halving skip.
<div dir=3D"auto">
<div dir=3D"auto">&nbsp;</div>
<div dir=3D"auto">But I don't think any scheme like this that only acts on =
the basis of difficulty will be sufficient. If it gets to the point where a=
 sudden drop in mining difficulty happens, it is very likely that simply de=
laying the next halving or even ending halving all together will not be suf=
ficient to correct for whatever is causing hashrate to tank. There is also =
the danger of simple difficulty stagnation, which this mechanism wouldn't d=
etect.&nbsp;</div>
<div dir=3D"auto">&nbsp;</div>
<div>The relationship between difficulty and security becomes less and less=
 predictable the longer you want to look ahead. There's no long term relati=
on between difficulty and any reasonable security target. A security target=
 might be something like "no colluding group with less than $1 trillion dol=
lars at their disposal could successfully 51% attack the network (with a pr=
obability of blah blah)". There is no way to today program in any code that=
 detects based on difficult alone when that criteria is violated. You would=
 have to program in assumptions about the cost of hashrate projected into t=
he future.</div>
<div dir=3D"auto">&nbsp;</div>
<div dir=3D"auto">I can't think of any robust automatic way to do this. I t=
hink to a certain degree, it will have to be a change that happens in a for=
k of some kind (soft or hard) periodically (every 10 years? 30 years?). The=
 basic relations needed is really the cost in Bitcoin of the security targe=
t (ie the minimum number of Bitcoin it should take to 51% attack the system=
) and the cost in Bitcoin of acquiring a unit of hashrate. This could be si=
mply input into the code, or could use some complicated oracle system. But =
with that relation, the system could be programmed to calculate the difficu=
lty necessary to keep the system secure.</div>
<div dir=3D"auto">&nbsp;</div>
<div dir=3D"auto">Once that is in place, the system could automatically adj=
ust the subsidy up or down to attract more or less miners, or it could adju=
st the block size up or down to change the fee market such that more or les=
s total fees are collected each block to attract more or less miners.&nbsp;=
</div>
</div>
</div>
</div>
<br />
<div class=3D"gmail_quote">
<div class=3D"gmail_attr" dir=3D"ltr">On Tue, Dec 27, 2022, 09:41 Jaroslaw =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
" target=3D"_blank" rel=3D"noopener">bitcoin-dev@lists.linuxfoundation.org<=
/a>&gt; wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid #cccccc; padding-left: 1ex;"><br />It seems like the more=
 elegant solution could be by using a chainwork parameter instead.<br />i.e=
. comparison just before halving - if the last 210,000 block interval has a=
 higher chainwork difference between the begining and the end of interval<b=
r />than any other such inter-halving interval before.<br /><br />LIttle di=
gression yet:<br />A system in which all users participate in ensuring its =
security looks better than one in which only some (i.e. active) of them par=
ticipate (and passive stakeholders are de facto free riders)<br />In my opi=
nion this concept above is only the complement of currently missing mechani=
sm: achieving equilibrium regarding costs of security between two parties w=
ith opposing interests.<br />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.<br />And last but not least, if someone is 100% su=
re that income from transactions will takeover security support from block =
subsidy - accepting such proposal is like putting the money where the mouth=
 is: this safety measure will never be triggered, then (no risk of fork)<br=
 /><br /><br />Best Regards<br />Jaroslaw<br /><br /><br /><br />W dniu 202=
2-12-23 20:29:20 u=C5=BCytkownik Jaroslaw via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"noopen=
er noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; napisa=C5=82:<=
br />&gt; <br />Necessary or not - it doesn't hurt to plan the robust model=
, just in case. The proposal is:<br /><br />Let every 210,000 the code calc=
ulate the average difficulty of 100 last retargets (100 fit well in 210,000=
 / 2016 =3D 104.166)<br />and compare with the maximum of all such values c=
alculated before, every 210,000 blocks:<br /><br /><br />if average_diff_of=
_last_100_retargets &gt; maximum_of_all_previous_average_diffs<br />&nbsp; =
&nbsp; &nbsp; &nbsp; do halving<br />else<br />&nbsp; &nbsp; &nbsp; &nbsp; =
do nothing<br /><br /><br />This way:<br /><br />1. system cannot be played=
<br />2. only in case of destructive halving: system waits for the recovery=
 of network security<br /><br /><br />Best Regards<br />Jaroslaw<br />_____=
__________________________________________<br />bitcoin-dev mailing list<br=
 /><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k" rel=3D"noopener noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br=
 /><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-de=
v" target=3D"_blank" rel=3D"noopener noreferrer noreferrer">https://lists.l=
inuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /><br /><br /><br />=
_______________________________________________<br />bitcoin-dev mailing li=
st<br /><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank" rel=3D"noopener noreferrer">bitcoin-dev@lists.linuxfoundation.org</=
a><br /><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitco=
in-dev" target=3D"_blank" rel=3D"noopener noreferrer noreferrer">https://li=
sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></blockquote>
</div>
</blockquote>

--===============3965289198520836362==--