1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
Return-Path: <jk_14@op.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id B7D88C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Dec 2022 15:34:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 8CF2060A46
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Dec 2022 15:34:21 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8CF2060A46
Authentication-Results: smtp3.osuosl.org;
dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256
header.s=2011 header.b=CAap3c+G
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 smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id FfP69fsO77ml
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Dec 2022 15:34:20 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org DD431600C5
Received: from smtpo95.poczta.onet.pl (smtpo95.poczta.onet.pl
[213.180.149.148])
by smtp3.osuosl.org (Postfix) with ESMTPS id DD431600C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 27 Dec 2022 15:34:19 +0000 (UTC)
Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4NhJbl0jDqzljMBK;
Tue, 27 Dec 2022 16:34:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011;
t=1672155251; bh=R/TddTrNgzZP+GoWwAsFLlm8cQ/C+qGrS5+VAA6RQ74=;
h=From:To:Date:Subject:From;
b=CAap3c+GxjhMJt3WWeBSXkikIoX2LXyMxhXZD9TDD5RW+2stu/bPryPMvZNZaPXX6
9wPe1cn/7iPxsizb8vJU7/RaylQgKVv1UjeZkp+LIOrPcih+IC2H57kfp1u+fo7y8o
2vBhd+278ux3+BGbg4yhtUfItN1hgLZ6XiSYHVbo=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [89.64.65.221] by pmq5v.m5r2.onet via HTTP id ;
Tue, 27 Dec 2022 16:34:10 +0100
From: jk_14@op.pl
X-Priority: 3
To: bitcoin-dev@lists.linuxfoundation.org
Date: Tue, 27 Dec 2022 16:34:07 +0100
Message-Id: <173647633-76b3b19c83c720cc30cb8fcb603b5251@pmq5v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <jk_144@onet.pl>;89.64.65.221;PL;2
X-ONET_PL-MDA-SEGREGATION: 0
X-Mailman-Approved-At: Tue, 27 Dec 2022 15:41:42 +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: Tue, 27 Dec 2022 15:34:21 -0000
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
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 ne=
twork security
Best Regards
Jaroslaw
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
