Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 68870C002D for ; Mon, 2 Jan 2023 04:53:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 2EF6041477 for ; Mon, 2 Jan 2023 04:53:59 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2EF6041477 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=goH1fOD4 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 NZDy1mWtsx5W for ; Mon, 2 Jan 2023 04:53:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E33424086F Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by smtp4.osuosl.org (Postfix) with ESMTPS id E33424086F for ; Mon, 2 Jan 2023 04:53:56 +0000 (UTC) Received: by mail-ej1-x632.google.com with SMTP id ud5so64467191ejc.4 for ; Sun, 01 Jan 2023 20:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HvydMIiOOo6Kokv/hdFuz8ueytV7YaKqckUjv9GXk5o=; b=goH1fOD4+Dz9wwdQZrke17sEv+m0fvxAWzOrSXAJ3hSrEbNSy/PkTCtnqFHEkesCAT X/aM+rHGligMPpVl0qCOCC57EPs4Q6mtnFMUOnWAiDKn+gZUtBQ8SemNqdnvpI0Ejdps xEYcCtzGxh5SYVw3UtUvF1X4iwhVHD5VqvGiaPthShajtjYEYfEOUugED6B2i1iRSxf5 25x4QIOnpQnFullKhyp9FDiwb2BwUQdZS/5l7r35cWJ8Mn7xKoWJswyUo3oB+3rI7fNu 6k7aqm1R4AmjaOs8qpoUbuEw3ebXJsoZ74LEtMtumfMAj8n9R7sccgx+KDPY5/BST8ju KQYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc: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=HvydMIiOOo6Kokv/hdFuz8ueytV7YaKqckUjv9GXk5o=; b=JfOXBBH+zMQkje+59my2xZCoE/JcD5zB9UbJgGZIy/qwW2zMnd2qwNrNcrSG+XoP44 Vp7ixw0PB3guvy8sa5iyLh1U44J9ghb07rc/uAyc/ELUtr4ryvi6eyPIRHChI74YJ7vE OOskM5Pijkm30ZrefXpHVXrz7W/9Yh3bXatAL01v5frGSqDoZte7iQBUhSCSzvDhZsd+ GGGqZLv3zyKle0Px8SSR+oXAD5N8q+FjsQgUFeTrtzfd0Euf9NGnr4UJ0c+cs63R9uqo pSil7gI9C/+qs+F8QlnQY1lGCQR5+EkdLssZychdD29BMwk/on9mulkgsM1h5KbDBaqT kBhg== X-Gm-Message-State: AFqh2kpU08iNRkSdVTM63fcHQfKZ9at29SkAMoec9nhd6WeJqwymphRE k8pI21I/MucDvP9s8B/Ocmv4DQEi8touuEwhB4M= X-Google-Smtp-Source: AMrXdXvJkmAzB+zvYmcK+AsUKpoosHdHrNLw4MWwsBkniHHtVNkoY4v+GbRZJBoIPl4boInGKXemmP4H8J/ZLSkl7OE= X-Received: by 2002:a17:907:7782:b0:7c0:e380:3d44 with SMTP id ky2-20020a170907778200b007c0e3803d44mr3306146ejc.498.1672635234999; Sun, 01 Jan 2023 20:53:54 -0800 (PST) MIME-Version: 1.0 References: <174623371-de649b28ce46dea2e588f2ef794decdb@pmq1v.m5r2.onet> In-Reply-To: <174623371-de649b28ce46dea2e588f2ef794decdb@pmq1v.m5r2.onet> From: Billy Tetrud Date: Sun, 1 Jan 2023 22:53:39 -0600 Message-ID: To: jk_14@op.pl Content-Type: multipart/alternative; boundary="00000000000005646e05f140bd2f" X-Mailman-Approved-At: Mon, 02 Jan 2023 12:46:13 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2023 04:53:59 -0000 --00000000000005646e05f140bd2f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > is surely better than not delaying it. I might agree, but I don't think it really solves the problem well enough to be worth it. Any solution that would solve the problem better would make delaying halvings unnecessary. > there is non-zero risk that people will hoard it more and more, according to old Gresham's law Gresham's law doesn't apply here. Gresham's law is about the interaction between two currencies with a fixed, usually government-enforced exchange rate. You seem to be saying that Bitcoin will be hoarded because Bitcoin inflation reduces every halving. But even with 0 inflation, it certainly won't cause all Bitcoin to be hoarded. Also, "hoarding" is also known as "saving", and there's nothing wrong with saving. The spectre of deflation comes from a misunderstanding of deflation and why it happens during bad economic times. It is an effect, not a cause. On Sun, Jan 1, 2023, 15:23 wrote: > > 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 > activity 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 > better than not delaying it. > > While Bitcoin is better and better money with every halving in comparisio= n > to other types of money - there is non-zero risk that people will hoard i= t > more and more, according to old Gresham's law ("HODL"). And this way > decreasing liquidity / transactions volume. The positive feedback loop - = is > my real concern here. > > Regarding the relationship between difficulty and security - I fully agre= e. > But ASIC technology is already matured. And also any technology > breakthrough 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. > > > W dniu 2022-12-30 19:21:10 u=C5=BCytkownik Billy Tetrud > napisa=C5=82: > > 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 dro= p > in mining difficulty happens, it is very likely that simply delaying the > next halving or even ending halving all together will not be sufficient t= o > correct for whatever is causing hashrate to tank. There is also the dange= r > 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 securit= y > 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 certai= n > 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) an= d > 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 wit= h > 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 fee= s > 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 (an= d >> 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 - accepti= ng >> 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 >> > --00000000000005646e05f140bd2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0is surely better than not delaying it.

I might agree, but I don't think it really solves the = problem well enough to be worth it. Any solution that would solve the probl= em better would make delaying halvings unnecessary.=C2=A0

>=C2=A0there is non-zero r= isk that people will hoard it more and more, according to old Gresham's= law

Gresham's law d= oesn't apply here. Gresham's law is about the interaction between t= wo currencies with a fixed, usually government-enforced exchange rate. You = seem to be saying that Bitcoin will be hoarded because Bitcoin inflation re= duces every halving. But even with 0 inflation, it certainly won't caus= e all Bitcoin to be hoarded. Also, "hoarding" is also known as &q= uot;saving", and there's nothing wrong with saving. The spectre of= deflation comes from a misunderstanding of deflation and why it happens du= ring bad economic times. It is an effect, not a cause.

On Sun,= Jan 1, 2023, 15:23 <j= k_14@op.pl> wrote:
Yes, the idea is:
if mining activity is growing - let's execute con= secutive halvings
but if miner exodus has happened - let's delay nex= t halving until mining activity is recovered to previous levels

If i= t gets to the point where a sudden drop in mining difficulty happens - dela= ying the next halving may be not sufficient to correct, but is surely bette= r than not delaying it.

While Bitcoin is better and better money wit= h 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 decreasing liquidity / transactions = volume. The positive feedback loop - is my real concern here.

Regard= ing the relationship between difficulty and security - I fully agree.
Bu= t ASIC technology is already matured. And also any technology breakthrough = 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 regre= ssion.

Obviously, not complicated solution would be better than complicat= ed 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, the "difference" you're calculating shou= ld only care about downward differences. Upward differences indicate more m= ining activity and so shouldn't cause a halving skip.
=C2=A0
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 whe= re a sudden drop in mining difficulty happens, it is very likely that simpl= y 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 a= lso the danger of simple difficulty stagnation, which this mechanism wouldn= 't detect.=C2=A0
=C2=A0
The relationship between difficulty and security becomes less and less= predictable the longer you want to look ahead. There's no long term re= lation between difficulty and any reasonable security target. A security ta= rget might be something like "no colluding group with less than $1 tri= llion 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 viola= ted. You would have to program in assumptions about the cost of hashrate pr= ojected into the future.
=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 (soft or hard) periodically (every 10 years? 30 years?).= The basic relations needed is really the cost in Bitcoin of the security t= arget (ie the minimum number of Bitcoin it should take to 51% attack the sy= stem) and the cost in Bitcoin of acquiring a unit of hashrate. This could b= e simply input into the code, or could use some complicated oracle system. = But with that relation, the system could be programmed to calculate the dif= ficulty necessary to keep the system secure.
=C2=A0
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.=C2=A0=

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

It seems like the more elegant= solution could be by using a chainwork parameter instead.
i.e. comparis= on just before halving - if the last 210,000 block interval has a higher ch= ainwork 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 bet= ter than one in which only some (i.e. active) of them participate (and pass= ive stakeholders are de facto free riders)
In my opinion this concept ab= ove is only the complement of currently missing mechanism: achieving equili= brium regarding costs of security between two parties with opposing interes= ts.
It's easy to understand and - most important - it has no hardcod= ed value of tail emission - what is the clear proof it is based on a free m= arket.
And last but not least, if someone is 100% sure 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 mea= sure will never be triggered, then (no risk of fork)


Best Regard= s
Jaroslaw



W dniu 2022-12-23 20:29:20 u=C5=BCytkownik Jar= oslaw via bitcoin-dev <bitcoin-de= v@lists.linuxfoundation.org> napisa=C5=82:
>
Necessary or = not - it doesn't hurt to plan the robust model, just in case. The propo= sal 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 c= ompare with the maximum of all such values calculated before, every 210,000= blocks:


if average_diff_of_last_100_retargets > maximum_of_a= ll_previous_average_diffs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 do halving
else=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 do nothing


This way:

1. s= ystem cannot be played
2. only in case of destructive halving: system wa= its for the recovery of network security


Best Regards
Jarosla= w
_______________________________________________
bitcoin-dev mailing= list
bitcoin-dev@lists.linuxfoun= dation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>



_______________________________________________
bitco= in-dev mailing list
bitcoin-dev@l= ists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo= /bitcoin-dev
--00000000000005646e05f140bd2f--