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
|
Return-Path: <miron@hyper.to>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9D136C0019
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 11:20:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 8BAF584C0F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 11:20:05 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.052
X-Spam-Level: *
X-Spam-Status: No, score=1.052 tagged_above=-999 required=5
tests=[BAYES_50=0.8, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id zqoScTK2AYBg
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 11:20:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com
[209.85.218.49])
by smtp1.osuosl.org (Postfix) with ESMTPS id 463358355F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 11:20:00 +0000 (UTC)
Received: by mail-ej1-f49.google.com with SMTP id g5so39113787ejx.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 04:20:00 -0700 (PDT)
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;
bh=fRGPvS58NQaASK9CTvFKCOlEFxq45Tb70sG2ZhrIRmI=;
b=sGqE8OkFexuCY8Abyh/O9RZRF8zQDLUYyu2tF3ne6SwRvT2czMHZugRsra/mCneLGV
hSJsg8kAX8/Pe/PqT3h/tS0W1IZlB5cwpb7bjla93/oPCeHnxFUBZLX+bj2Z6Ezaratf
LShRA6poFueaKoqSEjEeRMu1syOYXj1cj9+ICtWt+ecxcxnUUddVerEEQzpS21lcvsnV
lTMKtav5I5oSX539Mu4gsoIZ7MjlrjISi7TCFTzh2HQuLXhgH9P/1t3c9URSUtIZ3+8x
wcU9ERzMNuKY6QWXnigKDZZmbOxUBDk4sgd3lz9sTfGB21EmJr1hsFtPGJ912JBkhYAk
ddiA==
X-Gm-Message-State: AOAM5322JvpnbjFXV/OA0r+mgpq7ptdpEI6cYWnjhTlvjqY9/aqgIe+v
3mwfPTACLy+5s0aLE3rQ9hZ+2ngrOmsqEDO1dazdTSXzn7w1nHI9dq8=
X-Google-Smtp-Source: ABdhPJwg5HMUTmIkAJOJqwugDKIUgAaudyFcisA27tuqhsS8m/QQ9kaaXHxh36ieTtu57Du5hYFZ68APTZ6Z5NGwZWI=
X-Received: by 2002:a17:906:278e:: with SMTP id
j14mr12655519ejc.224.1618658399262;
Sat, 17 Apr 2021 04:19:59 -0700 (PDT)
MIME-Version: 1.0
References: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com>
In-Reply-To: <CAJowKgJNefXZTCJk_EK4JC7uPKsTrGv=yUROpjL_7GGbfNrrvA@mail.gmail.com>
From: Devrandom <c1.bitcoin@niftybox.net>
Date: Sat, 17 Apr 2021 13:19:46 +0200
Message-ID: <CAB0O3SXT7k42Q=DH_PxVzV4W3HCEajfFqHuNW-YyEfP6W=zhfg@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e6b3d905c0294600"
X-Mailman-Approved-At: Sat, 17 Apr 2021 11:43:40 +0000
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: Sat, 17 Apr 2021 11:20:05 -0000
--000000000000e6b3d905c0294600
Content-Type: text/plain; charset="UTF-8"
Hi Erik,
Here's a scheme I posted here a few years ago, which smoothly transitions
using geometric mean chain weight / difficulty:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015236.html
On Fri, Apr 16, 2021 at 11:08 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Not sure of the best place to workshop ideas, so please take this with
> a grain of salt.
>
> Starting with 3 assumptions:
>
> - assume that there exists a proof-of-burn that, for Bitcoin's
> purposes, accurately-enough models the investment in and development
> of ASICs to maintain miner incentive.
> - assume the resulting timing problem "how much burn is enough to keep
> blocks 10 minutes apart and what does that even mean" is also...
> perfectly solvable
> - assume "everyone unanimously loves this idea"
>
> 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?
>
> IE: We could transition to another "required proof" - such as a
> quantum POW or a POB (above) or something else .... in a back-compat
> way (existing nodes not aware of the rules would continue to
> validate).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000e6b3d905c0294600
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Erik,</div><div><br></div><div>Here's a scheme=
I posted here a few years ago, which smoothly transitions using geometric =
mean chain weight / difficulty:</div><div><br></div><div><a href=3D"https:/=
/lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015236.html"=
>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/0152=
36.html</a></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Fri, Apr 16, 2021 at 11:08 PM Erik Aronesty via bitcoin=
-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">Not sure of the best place to workshop ideas, s=
o please take this with<br>
a grain of salt.<br>
<br>
Starting with 3 assumptions:<br>
<br>
- assume that there exists a proof-of-burn that, for Bitcoin's<br>
purposes, accurately-enough models the investment in and development<br>
of ASICs to maintain miner incentive.<br>
- assume the resulting timing problem "how much burn is enough to keep=
<br>
blocks 10 minutes apart and what does that even mean"=C2=A0 is also...=
<br>
perfectly solvable<br>
- assume "everyone unanimously loves this idea"<br>
<br>
The transition *could* look like this:<br>
<br>
=C2=A0- validating nodes begin to require proof-of-burn, in addition to<br>
proof-of-work (soft fork)<br>
=C2=A0- the extra expense makes it more expensive for miners, so POW slowly=
drops<br>
=C2=A0- on a predefined schedule, POB required is increased to 100% of the<=
br>
"required work" to mine<br>
<br>
Given all of that, am I correct in thinking that a hard fork would not<br>
be necessary?<br>
<br>
IE: We could transition to another "required proof" - such as a<b=
r>
quantum POW or a POB (above) or something else ....=C2=A0 in a back-compat<=
br>
way (existing nodes not aware of the rules would continue to<br>
validate).<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000e6b3d905c0294600--
|
