MIME-Version: 1.0
References: <173647633-76b3b19c83c720cc30cb8fcb603b5251@pmq5v.m5r2.onet>
In-Reply-To: <173647633-76b3b19c83c720cc30cb8fcb603b5251@pmq5v.m5r2.onet>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 30 Dec 2022 12:20:47 -0600
Message-ID: <CAGpPWDZHYN8quCK0Vb4OZxyo5WnGmzayz1tGMsToO=GzSRcSKg@mail.gmail.com>
To: jk_14@op.pl, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000620c7605f10faa52"
Subject: Re: [bitcoin-dev] Pseudocode for robust tail emission
Precedence: list

--000000000000620c7605f10faa52
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.

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 delaying the
next halving 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 simple difficulty stagnation, which this mechanism wouldn't detect.

The relationship between difficulty and security becomes less and less
predictable the longer you want to look ahead. There's no long term
relation between difficulty and any reasonable security target. A security
target might be something like "no colluding group with less than $1
trillion dollars at their disposal could successfully 51% attack the
network (with a probability 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 the future.

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
(soft or hard) periodically (every 10 years? 30 years?). The basic
relations needed 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 the code, or could use some complicated oracle system. But with
that relation, the system could be programmed to calculate the difficulty
necessary to keep the system secure.

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
collected each block to attract more or less miners.

On Tue, Dec 27, 2022, 09:41 Jaroslaw via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> It seems like the more elegant solution could be by using a chainwork
> parameter instead.
> 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
> than any other such inter-halving interval before.
>
> LIttle digression yet:
> A system in which all users participate in ensuring its security looks
> better than one in which only some (i.e. active) of them participate (and
> passive stakeholders are de facto free riders)
> In my opinion this concept above is only the complement of currently
> missing 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
> transactions will takeover security support from block subsidy - acceptin=
g
> such proposal 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 <
> bitcoin-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
> retargets (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:
>
>
> if average_diff_of_last_100_retargets >
> maximum_of_all_previous_average_diffs
>         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
> network 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
>

--000000000000620c7605f10faa52
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"auto">If the idea is to ensure that a catastro=
phic miner exodus doesn&#39;t happen, the &quot;difference&quot; you&#39;re=
 calculating should only care about downward differences. Upward difference=
s indicate more mining activity and so shouldn&#39;t cause a halving skip.<=
div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">But I don=
9;t think any scheme like this that only acts on the basis of difficulty wi=
ll be sufficient. If it gets to the point where a sudden drop in mining dif=
ficulty happens, it is very likely that simply delaying the next halving or=
 even ending halving all together will not be sufficient to correct for wha=
tever is causing hashrate to tank. There is also the danger of simple diffi=
culty stagnation, which this mechanism wouldn&#39;t detect.=C2=A0</div><div=
 dir=3D"auto"><br></div><div>The relationship between difficulty and securi=
ty becomes less and less predictable the longer you want to look ahead. The=
re&#39;s no long term relation between difficulty and any reasonable securi=
ty target. A security target might be something like &quot;no colluding gro=
up with less than $1 trillion dollars at their disposal could successfully =
51% attack the network (with a probability of blah blah)&quot;. There is no=
 way to today program in any code that detects based on difficult alone whe=
n that criteria is violated. You would have to program in assumptions about=
 the cost of hashrate projected into the future.</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">I can&#39;t think of any robust automatic way to d=
o this. I think to a certain degree, it will have to be a change that happe=
ns in a fork of some kind (soft or hard) periodically (every 10 years? 30 y=
ears?). The basic relations needed is really the cost in Bitcoin of the sec=
urity 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 the code, or could use some complicated oracle s=
ystem. But with that relation, the system could be programmed to calculate =
the difficulty necessary to keep the system secure.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Once that is in place, the system could automat=
ically 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 m=
ore or less total fees are collected each block to attract more or less min=
ers.=C2=A0</div></div></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, Dec 27, 2022, 09:41 Jaroslaw via bitc=
oin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><br>
It seems like the more elegant solution could be by using a chainwork param=
eter instead.<br>
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 interva=
l<br>
than any other such inter-halving interval before.<br>
<br>
LIttle digression yet:<br>
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)<br>
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.<br>
It&#39;s easy to understand and - most important - it has no hardcoded valu=
e 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% 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)<br>
<br>
<br>
Best Regards<br>
Jaroslaw<br>
<br>
<br>
<br>
W dniu 2022-12-23 20:29:20 u=C5=BCytkownik Jaroslaw via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; napisa=C5=82:=
<br>
&gt; <br>
Necessary or not - it doesn&#39;t hurt to plan the robust model, just in ca=
se. The proposal is:<br>
<br>
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)<br>
and compare with the maximum of all such values calculated before, every 21=
0,000 blocks:<br>
<br>
<br>
if average_diff_of_last_100_retargets &gt; maximum_of_all_previous_average_=
diffs<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 do halving<br>
else<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 ne=
twork security<br>
<br>
<br>
Best Regards<br>
Jaroslaw<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000620c7605f10faa52--