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
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
|
Return-Path: <earonesty@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 657E2C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 May 2021 20:55:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 4729B615BD
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 May 2021 20:55:11 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.299
X-Spam-Level: *
X-Spam-Status: No, score=1.299 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
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 DpvPszElGChd
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 May 2021 20:55:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com
[IPv6:2607:f8b0:4864:20::52c])
by smtp3.osuosl.org (Postfix) with ESMTPS id 44289606C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 May 2021 20:55:10 +0000 (UTC)
Received: by mail-pg1-x52c.google.com with SMTP id v14so12457696pgi.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 May 2021 13:55:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=q32-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=hrRmkd9fdHnSJ5KShxp9QpKTDkW3v4bo1DF4dzDJu/M=;
b=O9wFWnxio2vtq+YrMVvdzvD/byW8BmZef/+W01TREVlq0mnqh4AXWTInE3z/soc2tZ
x8xqdIVpoJnDobdAA1nmuABAOSaHFHrwgaJC4GJN3/nBNENvG6rRwUYhlTlwmEZC/qYn
DTenuxshXFi+aJs+aH+f9cRza+DIYzO96COlCd9RpQXA5F+Yf4vrw2nSG7NQtdiSW+Ll
0tZcfLZNXE/u8LVjPX/3giR1LKKVjA+J6/6TaJGmQqZ3wRtmJUI1KB8jCbT5yHZHKNSC
pbGaBBtTIOEIKksy7A1oIlyBwYfq2atFrbhWcz9BcTVS/WBUQOiZOsYFp5LvfcZHPlKu
QUlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=hrRmkd9fdHnSJ5KShxp9QpKTDkW3v4bo1DF4dzDJu/M=;
b=Rzpt6dYYvSYVhmg+8AygdHp8U5XoM0ZkO7iK26NaY62sqauBTZszouG9/iqeALQWh5
UH5pbIBzZhi9kzr7Sgz/kA070rxA2bNnch0q1Pg8L09PSv61wzH6vQhoYTBk0tVnO9h0
6b+zTF+N3DM5VJnbMd7fiMY2LPk18q/Nm/oAfFS/kC66gKuvRD4BVVdKikSQQBfrKvOK
DvYXkSkSkz7Ydx2Re+N1rPGf7EkTRTljgHJXqZiV5oLlUl+lV6Brw/h05HnQeEWj51PG
f2aZv7hIXIjNN6JtVVOfva/n/USm/CFqHfv9+31l7CQ+uFT3FJX9Lccwknwvl1onZKYa
0O/w==
X-Gm-Message-State: AOAM530ghyG+unCgezsTmzGc8AeDCLsK1zB4v3Y7pKVA7fak2qFavdxC
fjD0Fxj/b3mFw+lUw0u7OX1SPL9FQzdHHbktyjaekY0=
X-Google-Smtp-Source: ABdhPJzMuddoc9B82SyNFETzK6CVhsK4P58aMwv+yEb1CZa2w0Fsnt7k1EYf4/ryLu34lN8kRP+5Jinvzm7L3OAAt8c=
X-Received: by 2002:a63:416:: with SMTP id 22mr605341pge.363.1621630509542;
Fri, 21 May 2021 13:55:09 -0700 (PDT)
MIME-Version: 1.0
References: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com>
<20210417114717.GA8079@erisian.com.au>
<CAGpPWDbCJKUpd=ufDXrSNwgm7DhQwDiGqfL-+2yqyviFhGDpvA@mail.gmail.com>
In-Reply-To: <CAGpPWDbCJKUpd=ufDXrSNwgm7DhQwDiGqfL-+2yqyviFhGDpvA@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 21 May 2021 16:54:57 -0400
Message-ID: <CAJowKg+xG+7T+CcuCJ6cQpuW+BxhL-710YU-kNZVyU_p1XYjDQ@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 21 May 2021 21:53:42 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] Gradual transition to an alternate proof without
a hard fork.
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: Fri, 21 May 2021 20:55:11 -0000
the original argument was correct: has to be a hard fork.
otherwise there's nothing to prevent a miner with leftover asics from
"tricking" old nodes to following another chain.
a hard fork is a really, really high bar - there would have to be
something very broken to justify it.
quantum-hashing or whatever (proof-of burn of course is as
quantum-safe as the underlying chain is... so it's nice to switch to,
should it be necessary)
On Fri, May 21, 2021 at 4:11 PM Billy Tetrud <billy.tetrud@gmail.com> wrote=
:
>
> The way I would think of doing this kind of thing (switching consensus pr=
otocol), which includes switching to a different hash function for proof of=
work, is to have a transitionary period where both consensus mechanisms ar=
e used to mine. This transitionary period should be long (perhaps years) to=
give miners time to manage the logistics of switching over. However, becau=
se there would be no trustless mechanism to automatically relate the amount=
of work (or burn, or whatever) done between the two consensus mechanisms, =
there would need to be some manually determined estimate of equivalence har=
d coded into the software. Eg, if we're talking about a different hash func=
tion, we could define in software that 100 current hashes is about equal to=
10 hashes using the new algorithm. This could even be set such that its ma=
rginally (but significantly) favorable to use the new hash function, to giv=
e additional incentive to miners to switch. The risk with that is that hard=
ware that processes that new hash function might innovate arbitrarily more =
quickly than the old hash function (which is likely to have somewhat platea=
ued), and this might make the manually estimated equivalence become inaccur=
ate in a way that could significantly reduce the security of the network. a=
change like this could be fraught with perils if the miners using each mec=
hanism don't end up cooperating to ensure that equivalence is set fairly, a=
nd instead make efforts to attempt to unfairly increase their share.
>
> In any case, the idea is that you'd have a smooth switch over from (block=
s the old mechanism creates / blocks the new mechanism creates) 100%/0% -> =
75%/25% -> 50/50 -> eventually 0%/100%. Or at some fraction of total hashpo=
wer, (eg 95%) the old consensus mechanism could simply be shut off - which =
would give additional incentive for miners to switch sooner rather than lat=
er. However, it would probably be best to make this cut off more like 99% t=
han 95%, since screwing over 5% of the hashpower for a few months is probab=
ly not necessary or ideal. It might actually just be better to have a time-=
based cutoff. Or have the final switch over lock in at 95% with a few month=
s to give the other 5% time to switch over (and if they don't then its on t=
hem).
>
> I would think this could work for switch between any consensus mechanism.=
However, how to do this in a soft fork is another story. It sounds like it=
s doable from other people's comments.
>
> On Sat, Apr 17, 2021 at 1:47 AM Anthony Towns via bitcoin-dev <bitcoin-de=
v@lists.linuxfoundation.org> wrote:
>>
>> On Fri, Apr 16, 2021 at 04:48:35PM -0400, Erik Aronesty via bitcoin-dev =
wrote:
>> > The transition *could* look like this:
>> > - validating nodes begin to require proof-of-burn, in addition to
>> > proof-of-work (soft fork)
>> > - the extra expense makes it more expensive for miners, so POW slowly=
drops
>> > - on a predefined schedule, POB required is increased to 100% of the
>> > "required work" to mine
>> > Given all of that, am I correct in thinking that a hard fork would not
>> > be necessary?
>>
>> It depends what you mean by a "hard fork". By the definition that
>> "the old software will consider the chain followed by new versions of
>> the software as valid" it's a soft fork. But it doesn't maintain the
>> property "old software continues to follow the same chain as new softwar=
e,
>> provided the economic majority has adopted the new software" -- because
>> after the PoW part has dropped its difficulty substantitally, people can
>> easily/cheaply make a new chain that doesn't include proof-of-burn, and
>> has weak proof-of-work that's nevertheless higher than the proof-of-burn
>> chain, so old nodes will switch to it, while new nodes will continue to
>> follow the proof-of-burn chain.
>>
>> So I think that means it needs to be treated as a hard fork: everyone
>> needs to be running the new software by some date to ensure they follow
>> the same chain.
>>
>> (The same argument applies to trying to switch to a different PoW
>> algorithm via a soft fork; I forget who explained this to me)
>>
>> Jeremy wrote:
>> > I think you need to hard deprecate the PoW for this to work, otherwise
>> > all old miners are like "toxic waste".
>> >
>> > Imagine one miner turns on a S9 and then ramps up difficulty for
>> > everyone else.
>>
>> If it's a soft-fork, you could only ramp up the PoW difficulty by mining
>> more than one block every ten minutes, but presumably the proof-of-burn
>> scheme would have its own way of preventing burners from mining blocks
>> too fast (it was assumption 2).
>>
>> Cheers,
>> aj
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|