Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 54DF9C002D for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion Date: Sun, 01 Jan 2023 22:23:37 +0100 Message-Id: <174623371-de649b28ce46dea2e588f2ef794decdb@pmq1v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 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

Yes, the idea is:
if mining activity is growing - let's exe= cute consecutive halvings
but if miner exodus has happened - let's del= ay next halving until mining activity is recovered to previous levels
=
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.

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.

Re= garding the relationship between difficulty and security - I fully agree.But ASIC technology is already matured. And also any technology breakth= rough is a short event within 4 years period.
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.

Obviously, not complicated solution would be better than complic= ated one.
 
 
W dniu 2022-12-30 19:21:10 u=C5=BCytkownik Billy Tetrud <billy.tetr= ud@gmail.com> 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 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. 
 
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.
 
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.
 
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. =

On Tue, Dec 27, 2022, 09:41 Jaroslaw = via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org<= /a>> 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 intervalthan any other such inter-halving interval before.

LIttle di= gression 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 par= ticipate (and passive stakeholders are de facto free riders)
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.
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% 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)

Best Regards
Jaroslaw



W dniu 202= 2-12-23 20:29:20 u=C5=BCytkownik Jaroslaw via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> napisa=C5=82:<= br />>
Necessary or not - it doesn't hurt to plan the robust model= , just in case. The proposal is:

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)
and compare with the maximum of all such values c= alculated 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 listbitcoin-dev@lists.linuxfoundation.orghttps://lists.l= inuxfoundation.org/mailman/listinfo/bitcoin-dev



= _______________________________________________
bitcoin-dev mailing li= st
bitcoin-dev@lists.linuxfoundation.org
https://li= sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--===============3965289198520836362==--