summaryrefslogtreecommitdiff
path: root/90/0c930fe78ed90df5b0ab2894605711b2e19813
blob: c2eb49c94042237bde913f0450580c6ed6a4a27b (plain)
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
Return-Path: <jlrubin@mit.edu>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id ED482C0881
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jan 2020 00:54:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id E964E86C59
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jan 2020 00:54:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id MBxu6ZcY1hdP
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jan 2020 00:54:20 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 9A4DB86C56
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 11 Jan 2020 00:54:20 +0000 (UTC)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com
 [209.85.166.54]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00B0sIKs005752
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 10 Jan 2020 19:54:19 -0500
Received: by mail-io1-f54.google.com with SMTP id k24so4008702ioc.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 10 Jan 2020 16:54:19 -0800 (PST)
X-Gm-Message-State: APjAAAVmLdk3G3d5Pu73kBgoFIH33R8EryNUswRW6uruoh2kJI44HdiK
 AbDe1nY1607vFkkjnszSFXm2znfXl5YD+2FP4W0=
X-Google-Smtp-Source: APXvYqy2b1KCaXwMRIJvwNFqtNLhkaPmI7rCZiTdwfUZjynS3bih+Rdu8X2zrYZFPfoO/2j2I9E/p8MyWxMb41H2aqg=
X-Received: by 2002:a02:c906:: with SMTP id t6mr5500047jao.75.1578704058008;
 Fri, 10 Jan 2020 16:54:18 -0800 (PST)
MIME-Version: 1.0
References: <4a132f8a-22e3-8e31-e338-bed9ef46d2ef@mattcorallo.com>
 <202001102337.53397.luke@dashjr.org>
In-Reply-To: <202001102337.53397.luke@dashjr.org>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 10 Jan 2020 16:54:06 -0800
X-Gmail-Original-Message-ID: <CAD5xwhjMNtzsEgC515Q3ddy1=K=iMNt-r3CXpg_ctXzWjtNb8g@mail.gmail.com>
Message-ID: <CAD5xwhjMNtzsEgC515Q3ddy1=K=iMNt-r3CXpg_ctXzWjtNb8g@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000955473059bd2aeab"
Subject: Re: [bitcoin-dev] Modern Soft Fork Activation
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, 11 Jan 2020 00:54:22 -0000

--000000000000955473059bd2aeab
Content-Type: text/plain; charset="UTF-8"

It's not at a "directly implementable policy state", but I think you might
be interested in checking out the spork protocol upgrade model I proposed a
while back. https://www.youtube.com/watch?v=J1CP7qbnpqA&feature=youtu.be

It has some interesting properties around the 5 properties you've mentioned.

1) Avoid activating in the face of significant, reasonable, and directed
objection. Period.

Up to miners to orphan spork-activating blocks.

2) Avoid activating within a timeframe which does not make high
node-level-adoption likely.

Mandatory minimum flag day for Spork initiation, statistically
improbable/impossible for even earlier adoption.

3) Don't (needlessly) lose hashpower to un-upgraded miners.

Difficulty adjustments make the missing spork'd block "go away" over time,
the additional difficulty of *not activating* a rejected spork fills in as
an additional PoW.


4) Use hashpower enforcement to de-risk the upgrade process, wherever
possible.

Miners choose to activate or build on activating blocks.

5) Follow the will of the community, irrespective of individuals or
unreasoned objection, but without ever overruling any reasonable
objection.

Honest signalling makes people be forced to "put their money where there
mouth is" on what the community wants.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

--000000000000955473059bd2aeab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">It&#39;s=
 not at a &quot;directly implementable policy state&quot;, but I think you =
might be interested in checking out the spork protocol upgrade model I prop=
osed a while back. <a href=3D"https://www.youtube.com/watch?v=3DJ1CP7qbnpqA=
&amp;feature=3Dyoutu.be">https://www.youtube.com/watch?v=3DJ1CP7qbnpqA&amp;=
feature=3Dyoutu.be</a></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:#000000">It has some interesting properties around the =
5 properties you&#39;ve mentioned.</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000">1) Avoid activating in the face o=
f significant, reasonable, and directed<br>
objection. Period.</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">Up to miners to orphan spork-activating blocks.<br=
></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:#000000"><br>
2) Avoid activating within a timeframe which does not make high<br>
node-level-adoption likely.</div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000">Mandatory minimum flag day for Spork init=
iation, statistically improbable/impossible for even earlier adoption.<br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000"><br>
3) Don&#39;t (needlessly) lose hashpower to un-upgraded miners.</div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Diffi=
culty adjustments make the missing spork&#39;d block &quot;go away&quot; ov=
er time, the additional difficulty of *not activating* a rejected spork fil=
ls in as an additional PoW.<br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000">
4) Use hashpower enforcement to de-risk the upgrade process, wherever<br>
possible.=C2=A0</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">Miners choose to activate or build on activating blo=
cks.<br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">
<br>
5) Follow the will of the community, irrespective of individuals or<br>
unreasoned objection, but without ever overruling any reasonable<br>
objection.</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:#000000">Honest signalling makes people be forced to &quot;put thei=
r money where there mouth is&quot; on what the community wants.<br></div><d=
iv><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signa=
ture"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" ta=
rget=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin"=
 target=3D"_blank"></a></div></div></div><br></div></div>

--000000000000955473059bd2aeab--