path: root/3d/5ad792419f9ac434962aed687f8c230c565207

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 744ABC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  2 Jan 2023 23:03:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 4C55741635
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  2 Jan 2023 23:03:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4C55741635
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=tUsQFBFw
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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, 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 LLl5NYXNX4ml
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  2 Jan 2023 23:02:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 40DEB41634
Received: from smtpa34.poczta.onet.pl (smtpa34.poczta.onet.pl [213.180.142.34])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 40DEB41634
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  2 Jan 2023 23:02:58 +0000 (UTC)
Received: from pmq1v.m5r2.onet (pmq1v.m5r2.onet [10.174.32.67])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4NmBGf0sTqzlfc7t;
 Tue,  3 Jan 2023 00:02:50 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011;
 t=1672700570; bh=T2oQxEz9RRjLx2+pk0eHXlcniLRNVWQi1xrUwez3jHQ=;
 h=From:Cc:To:Date:Subject:From;
 b=tUsQFBFwFRG46Red30FsRYRtzCi+PoYc9N7FIsqxTBpS9sPt5kSYXmdqxNAa9J7S2
 bfATqfwiGJsy8RPCsjZSShDe0aurUfp7dPeANuSAsCQFtYAKc0L5g2LXZJsc99sw6v
 9P9xCvY3+qXiy/OWUhaaec2qk+qQQ43cvEx5kbck=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [89.64.64.238] by pmq1v.m5r2.onet via HTTP id ;
 Tue, 03 Jan 2023 00:02:50 +0100
From: jk_14@op.pl
X-Priority: 3
To: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 03 Jan 2023 00:02:48 +0100
Message-Id: <174713476-5bd35a73599a0a65335d70e99a1bb44e@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: Mon, 02 Jan 2023 23:09:06 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Mon, 02 Jan 2023 23:03:00 -0000



Right now security comes from almost fully from ~1.8% inflation.
In November mempool was inflated to ~150MB and people were rather waiting f=
or cheap transactions back.
Instead of being happy that system is closer for a while to default working=
 area.

Deflation in Bitcoin is not 1:1 matter like in gold, for example.
If all plain gold available to mine would be finished - gold mines as unpro=
fitable enterprices are immediately closed.
And it doesn't affect security of gold already in circulation.
In Bitcoin "the show must go on" and someone must pay for it.
Active and passive users together (balanced by market play) or: only active=
 users (in current scenario, long-term).

Deflation (or more precisely: tiny inflation) in Bitcoin is more complex is=
sue with more repercussions than in gold.
In case of drop of network security - the tax will be paid anyway, in Bitco=
in price.
So, there is an self-regulating mechanism here. The harsh one, but still.



W dniu 2023-01-02 05:53:57 u=C5=BCytkownik Billy Tetrud <billy.tetrud@gmail=
.com> napisa=C5=82:
>=C2=A0is surely better than not delaying it.
=C2=A0
I might agree, but I don't think it really solves the problem well enough t=
o be worth it. Any solution that would solve the problem better would make =
delaying halvings unnecessary.=C2=A0
=C2=A0
>=C2=A0there is non-zero risk that people will hoard it more and more, acco=
rding to old Gresham's law


Gresham's law doesn't apply here. Gresham's law is about the interaction be=
tween two currencies with a fixed, usually government-enforced exchange rat=
e. You seem to be saying that Bitcoin will be hoarded because Bitcoin infla=
tion reduces every halving. But even with 0 inflation, it certainly won't c=
ause 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 tim=
es. It is an effect, not a cause.


On Sun, Jan 1, 2023, 15:23 <jk_14@op.pl> 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 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.




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.


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


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.


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.


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