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
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
Return-Path: <jk_14@op.pl>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3DFCFC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Jan 2023 22:37:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 209B8402F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Jan 2023 22:37:37 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 209B8402F5
Authentication-Results: smtp2.osuosl.org;
dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256
header.s=2011 header.b=rxTdGfbE
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 smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id rbzEjiXNDBqn
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Jan 2023 22:37:36 +0000 (UTC)
X-Greylist: delayed 00:09:48 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 233AE40260
Received: from smtpa34.poczta.onet.pl (smtpa34.poczta.onet.pl [213.180.142.34])
by smtp2.osuosl.org (Postfix) with ESMTPS id 233AE40260
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 1 Jan 2023 22:37:36 +0000 (UTC)
Received: from pmq8v.m5r2.onet (pmq8v.m5r2.onet [10.174.35.145])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4NlYXY16Xhzlfc97;
Sun, 1 Jan 2023 23:27:40 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011;
t=1672612061; bh=5msheMPmVzF/gaQi7ivdYvqDZabMC3qA04tyAOW/hv8=;
h=From:Cc:To:Date:Subject:From;
b=rxTdGfbEXMI5hu1rvl9rSDwjjDhZVUhZ4GrdSzsy/X/nSk6C+j9YcK4gDxYnQlBZ6
dWOby54rZuAv2n9MMwyv3fCiaRvmhNvT6DwvgDrbJ+TRDCeIMUhXOM+9cXTcdd4jP5
TQ5c8KcHvovMky0Lrej4w4AiXKu1lMW3CmOxzzi0=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [89.64.64.238] by pmq8v.m5r2.onet via HTTP id ;
Sun, 01 Jan 2023 23:27:40 +0100
From: jk_14@op.pl
X-Priority: 3
To: Peter Todd <pete@petertodd.org>
Date: Sun, 01 Jan 2023 23:27:38 +0100
Message-Id: <149371042-9e9acf88755b97f4a249777ce88d0078@pmq8v.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: Sun, 01 Jan 2023 23:33:11 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<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: Sun, 01 Jan 2023 22:37:37 -0000
Is a storage fee averaged out over many future blocks - but not hardcoded v=
alue and regulated by a free market?
The problem with demurrage I see is that the fee is taken when you spend. T=
here is no additional income for miners if people are still hoarding.
In tail emission even if people are still hoarding - the fee is taken immed=
iately and is distributed to miners.
We have a hope there is still the global adoption ahead (most of countries =
are like El Salvador). It may increase price and marketcap of Bitcoin by or=
der of magnitude.
And that's why hoarding in demurrage may still exist: due to extremely appe=
aling long-term risk/reward (i.e. relatively small, delayed tax versus huge=
possible profit)
W dniu 2022-12-31 00:29:08 u=C5=BCytkownik Peter Todd <pete@petertodd.org> =
napisa=C5=82:
> On Fri, Dec 23, 2022 at 07:43:36PM +0100, jk_14@op.pl wrote:
> =
> 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 r=
etargets (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_d=
iffs
> 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
First of all - while I suspct you already understand this issue - I should
point out the following:
The immediate danger we have with halvings is that in a competitive market,
profit margins tend towards marginal costs - the cost to produce an additio=
nal
unit of production - rather than total costs - the cost necessary to recover
prior and future expenses. Since the halving is a sudden shock to the syste=
m,
under the right conditions we could have a significant amount of hashing po=
wer
just barely able to afford to hash prior to the halving, resulting in all t=
hat
hashing power immediately having to shut down and fees increasing dramatica=
lly,
and likely, chaotically. Your proposal does not address that problem as it=
can
only measure difficulty prior to the halving point.
Other than that problem, I agree that this proposal would, at least in theo=
ry,
be a positive improvement on the status quo. But it is a hard fork and I do=
n't
think there is much hope for such hard forks to be implemented. I believe t=
hat
a demmurrage soft-fork, implemented via a storage fee averaged out over many
future blocks, has a much more plausible route towards implementation.
-- =
https://petertodd.org 'peter'[:-1]@petertodd.org
|
