path: root/3f/145998bf91748fa82acc1ed84654a4889c1939

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1953CC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 30 Dec 2022 18:21:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id D929840A05
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 30 Dec 2022 18:21:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D929840A05
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=RwuLZLTV
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mE8SygaOi0ae
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 30 Dec 2022 18:21:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D73B04099F
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com
 [IPv6:2a00:1450:4864:20::534])
 by smtp4.osuosl.org (Postfix) with ESMTPS id D73B04099F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 30 Dec 2022 18:21:10 +0000 (UTC)
Received: by mail-ed1-x534.google.com with SMTP id u28so26532575edd.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 30 Dec 2022 10:21:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=RgJXnSBM92Cf3Jrc2/6p6SaM66ivkOH8u8q/13BCxtY=;
 b=RwuLZLTVf7HOol+jNMoS9HPmn1CjhEAyTKvAqoLbMxOr/+SUdIHDZ+JnIQvY9/TOiY
 SaTp/9lpIlFb6vYSTpuMwfPlHpr1ghitwctSMAkzesyQC07VL8a6PVHxevePRpFQTnzI
 AhH3D34rQUAB9Ki00DJavG1sCOyN8VieIHpKArC6ojOy+Qkxj86z91RDAZEgGU5hs3pC
 zQdjKJPKeKaeFBQRo66DEknL4fiXiswqWl1VPQHz1/bhL0WjVkY1wLzfKOrDfqNyw8jT
 Zu+VD5JUm9ryEREj/eNipRBRW+I76SrgcRTV4JMRjZt9JZpkUcLjrFQCEoEZVrE80Vd4
 oarA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=RgJXnSBM92Cf3Jrc2/6p6SaM66ivkOH8u8q/13BCxtY=;
 b=6jn4ALp5zGOoM8CDIRB0dYA3BIgN8yAWlyloSVVbEJ2inSDja2zDMtG1Y+85fcZiXi
 25ldpcr75tQQ/t1eIE1pbzV6hK4LgcPZka0fITIwQJYVHWNNH78KOCrdTgGAkQXSFpgF
 2yHFgXp03LuDI2cUSl7CMOh4TxjPzf1LHYbIVFidLiGcPDijjE9UlMvQIU3tzKAFDJGQ
 l9wrOuyv5I1p+e15uGBbQ9Jm2aBK5Pp2OHyj3u7h4eSlkj06AMD7WJwqyE/ZubmiQhjs
 kShYk89vgO3ZgBsMqrTWpFL6OQNFi/tmVbHnlt9+YqMxTM4GDvLw14FzLBz8+QM5+FOc
 nIZA==
X-Gm-Message-State: AFqh2kqz0hTffD9Dt0Zu/euD5BbaaY0e4csYcwVKzYvZ+5vqj3vdX3UH
 ZA1p+l9+cktH60mo8SjAVKEKfixSRyzJgrcvOLEO1o6y
X-Google-Smtp-Source: AMrXdXtUVEi5qqVkzFkZ4QG6UZ5BZlOHGBTFhyKkFLGHK6AszMc9fd8JjN8r8gQ/0bymUtsN0eRs0rR7phl2o6id07w=
X-Received: by 2002:a50:8710:0:b0:47d:de33:4a6e with SMTP id
 i16-20020a508710000000b0047dde334a6emr3193888edb.101.1672424468907; Fri, 30
 Dec 2022 10:21:08 -0800 (PST)
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"
X-Mailman-Approved-At: Fri, 30 Dec 2022 18:23:40 +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: Fri, 30 Dec 2022 18:21:13 -0000

--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&#3=
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--