summaryrefslogtreecommitdiff
path: root/fd/15df55e24d0ae80c3ad36f391e595265812fa9
blob: ceb63494e9a899de1372176764e75c63e9b8ff2e (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
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
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
Return-Path: <james.hilliard1@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F0B0F3EE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 May 2017 10:19:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com
	[209.85.218.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 10101F3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 May 2017 10:19:19 +0000 (UTC)
Received: by mail-oi0-f45.google.com with SMTP id b204so73993201oii.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 29 May 2017 03:19:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-transfer-encoding;
	bh=xYKvZs09GU2VML1pR/jO7BfZOmeWZJ6pPLJa2Pl5F58=;
	b=CDtkVabHgocLD2YMjVoNV2Yx/QaIRfDASxxwCZgo1Lnpsy/aJyoRfuJknvEFD6G9TR
	h4uLrkmF0zED3unYYkAkOmcqq7RD5DqKPKI+r/VMMlk6pukCfYUnFnpNC1StxrRylBqd
	oSnPYfrXLVZwy8czlOs1OiS2LUrlczfN+rJD0z4BTqSBDAvq62qOP1XM9ZxR/bf1gfK5
	6IdvKZi0802L2oG2LLvB29oEPq70yLI/LoT+3D2/ogK1mQaVyvKHrzFBxxtFxI9xuHnR
	SO/swqPSvKe+GZ/L9QNNOHQeMQ2l4KaaROM/Qn/8c3+f66uX6iPlS13hv7gTF3bwvrq6
	ud1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-transfer-encoding;
	bh=xYKvZs09GU2VML1pR/jO7BfZOmeWZJ6pPLJa2Pl5F58=;
	b=hO+/91na3r1mSXxN/2hMl+Flvro8L3DthoTregMgT0LaH/I5Wce/i1FbPaWF8AAB8T
	O9WF5RoDd4JOusbygBzmCmkBDrQHMex60MpNi6uSotcAutJ4GHbdQ625PVULin5QhOZ3
	GCts1qoHrURU/Jb7e4O1MesPl9PfDL0b3zRYzE2qjftK9N05hCAmeg+NbqDxAq9A90DV
	tdITjXr0BA7kOkFLBv7ebiAUAfsixzOMtIPLXxG3qEo69lcy8fgKOW98+8sI8Zj4bG+v
	B8ovLRMXTrBTWNMfaPdv6/lwkOZ6JfscL63go9sAugOYdGIuv2SNnKajBQIn3iKbtahb
	MZ1A==
X-Gm-Message-State: AODbwcBvOGpt8Ne5bihXV52Uh9oVM3dyj4Hs+tdNZzH3vVbR3Uw8Vl73
	ejxbth3+WPndkW3x4jIvU9KvVYjKzQ==
X-Received: by 10.157.14.230 with SMTP id 93mr7912479otj.97.1496053159157;
	Mon, 29 May 2017 03:19:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.115.198 with HTTP; Mon, 29 May 2017 03:19:18 -0700 (PDT)
In-Reply-To: <aC4avUiJPnHXxIxPlh4w2XA-SLB6ueTUlVTW7TreFwGV12L7L9CAGoB2E9msVYhV0M6xPTERpatAIeZO3kK-ikCRkwYQcJeEMHS7WWZKDAM=@protonmail.com>
References: <aC4avUiJPnHXxIxPlh4w2XA-SLB6ueTUlVTW7TreFwGV12L7L9CAGoB2E9msVYhV0M6xPTERpatAIeZO3kK-ikCRkwYQcJeEMHS7WWZKDAM=@protonmail.com>
From: James Hilliard <james.hilliard1@gmail.com>
Date: Mon, 29 May 2017 05:19:18 -0500
Message-ID: <CADvTj4q2r7sxXfgkdXjgSD5KaEW010aLq8c3YBvqs50FM_ExGg@mail.gmail.com>
To: CalvinRechner <calvinrechner@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Mon, 29 May 2017 10:19:21 -0000

For the reasons listed
here(https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki#Motivat=
ion)
you should have it so that the HF can not lock in unless the existing
BIP141 segwit deployment is activated.

The biggest issue is that a safe HF is very unlikely to be able to be
coded and tested within 6 months.

On Sun, May 28, 2017 at 8:18 PM, CalvinRechner via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> This proposal is written under the assumption that the signatories to the
> Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms =
of
> the agreement, and intend to enact the updates described therein. As such=
,
> criticisms pertaining to the chosen deployment timeline or hard fork upgr=
ade
> path should be treated as out-of-scope during the initial discussion of t=
his
> proposal.
>
> Because it includes the activation of a hard fork for which community
> consensus does not yet exist, this proposal is not likely to be merged in=
to
> Bitcoin Core in the immediate future, and must instead be maintained and
> reviewed in a separate downstream repository. However, it is written with
> the intent to remain cleanly compatible with future network updates and
> changes, to allow for the option of a straightforward upstream merge if
> community consensus for the proposal is successfully achieved in the
> following months.
>
>
> <pre>
> BIP: ?
> Layer: Consensus
> Title: Compatibility-oriented omnibus proposal
> Author: Calvin Rechner <calvinrechner@protonmail.com>
> Comments-Summary: No comments yet.
> Comments-URI: ?
> Status: Draft
> Type: Standards Track
> Created: 2017-05-28
> License: PD
> </pre>
>
>
> =3D=3D=3DAbstract=3D=3D=3D
>
> This document describes a virtuous combination of James Hilliard=E2=80=99=
s =E2=80=9CReduced
> signalling threshold activation of existing segwit deployment=E2=80=9D[2]=
, Shaolin
> Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployment=E2=80=9D=
[3], Sergio Demian Lerner=E2=80=99s
> =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal, Luke Dashjr=E2=80=99s =E2=80=9CP=
ost-segwit 2 MB block size
> hardfork=E2=80=9D[5], and hard fork safety mechanisms from Johnson Lau=E2=
=80=99s
> =E2=80=9CSpoonnet=E2=80=9D[6][7] into a single omnibus proposal and patch=
set.
>
>
> =3D=3D=3DMotivation=3D=3D=3D
>
> The Consensus 2017 Scaling Agreement[1] stipulated the following
> commitments:
>
> =E2=80=A2 Activate Segregated Witness at an 80% threshold, signaling at b=
it 4
> =E2=80=A2 Activate a 2 MB hard fork within six months
>
> This proposal seeks to fulfill these criteria while retaining maximum
> compatibility with existing deployment approaches, thereby minimizing the
> risks of a destructive chain split. Additionally, subsequent indications =
of
> implied criteria and expectations of the Agreement[8][9] are satisfied.
>
> The proposed hard fork incorporates a legacy witness discount and 2MB
> blocksize limit along with the enactment of Spoonnet-derived protectionar=
y
> measures, to ensure the safest possible fork activation within the
> constraints of the requirements outlined in the Scaling Agreement.
>
>
> =3D=3D=3DRationale=3D=3D=3D
>
> To the extent possible, this represents an effort at a best-of-all-worlds
> proposal, intended to provide a common foundation from which all
> mutually-inclusive goals can be achieved while risks are minimized.
>
> The individual constituent proposals include the following respective
> rationales:
>
> James Hilliard=E2=80=99s =E2=80=9CReduced signalling threshold activation=
 of existing segwit
> deployment=E2=80=9D[2] explains:
>
>> The goal here is to minimize chain split risk and network disruption whi=
le
>> maximizing backwards compatibility and still providing for rapid activat=
ion
>> of segwit at the 80% threshold using bit 4.
>
> Shaolin Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployment=
=E2=80=9D[3] is included to:
>
>> cause the existing "segwit" deployment to activate without needing to
>> release a new deployment.
>
> Both of the aforementioned activation options (=E2=80=9Cfast-activation=
=E2=80=9D and
> =E2=80=9Cflag-day activation=E2=80=9D) serve to prevent unnecessary delay=
s in the network
> upgrade process, addressing a common criticism of the Scaling Agreement a=
nd
> providing an opportunity for cooperation and unity instead.
>
> Sergio Demian Lerner=E2=80=99s =E2=80=9CSegwit2Mb=E2=80=9D[4] proposal ex=
plains the reasoning behind
> linking SegWit=E2=80=99s activation with that of a later hard fork block =
size
> increase:
>
>> Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB blo=
ck
>> size hard-fork activated ONLY if segwit activates (95% of miners signali=
ng
>> ... to re-unite the Bitcoin community and avoid a cryptocurrency split.
>
> Luke Dashjr=E2=80=99s =E2=80=9CPost-segwit 2 MB block size hardfork=E2=80=
=9D[5] suggestions are
> included to reduce the marginal risks that such an increase in the block
> size might introduce:
>
>> if the community wishes to adopt (by unanimous consensus) a 2 MB block
>> size hardfork, this is probably the best way to do it right now... Legac=
y
>> Bitcoin transactions are given the witness discount, and a block size li=
mit
>> of 2 MB is imposed.
>
> Johnson Lau=E2=80=99s anti-replay and network version updates[6][7] are i=
ncluded as
> general hard fork safety measures:
>
>> In a blockchain split, however, since both forks share the same historic=
al
>> ledger, replay attack would be possible, unless some precautions are tak=
en.
>
>
> =3D=3D=3DCopyright=3D=3D=3D
>
> This document is placed in the public domain.
>
>
> =3D=3D=3DSpecification=3D=3D=3D
>
> ###Proposal Signaling###
>
> The string =E2=80=9CCOOP=E2=80=9D is included anywhere in the txn-input (=
scriptSig) of the
> coinbase-txn to signal compatibility and support.
>
> ###Soft Fork###
>
> Fast-activation (segsignal):  deployed by a "version bits" with an 80%
> activation threshold BIP9 with the name "segsignal" and using bit 4... [w=
ith
> a] start time of midnight June 1st, 2017 (epoch time 1496275200) and time=
out
> on midnight November 15th 2017 (epoch time 1510704000). This BIP will cea=
se
> to be active when segwit is locked-in.[2]
>
> Flag-day activation (BIP148): While this BIP is active, all blocks must s=
et
> the nVersion header top 3 bits to 001 together with bit field (1<<1)
> (according to the existing segwit deployment). Blocks that do not signal =
as
> required will be rejected... This BIP will be active between midnight Aug=
ust
> 1st 2017 (epoch time 1501545600) and midnight November 15th 2017 (epoch t=
ime
> 1510704000) if the existing segwit deployment is not locked-in or activat=
ed
> before epoch time 1501545600. This BIP will cease to be active when segwi=
t
> is locked-in. While this BIP is active, all blocks must set the nVersion
> header top 3 bits to 001 together with bit field (1<<1) (according to the
> existing segwit deployment). Blocks that do not signal as required will b=
e
> rejected.[3]
>
> ###Hard Fork###
>
> The hard fork deployment is scheduled to occur 6 months after SegWit
> activates:
>
> (HardForkHeight =3D SEGWIT_ACTIVE_BLOCK_HEIGHT + 26280)
>
> For blocks equal to or higher than HardForkHeight, Luke-Jr=E2=80=99s lega=
cy witness
> discount and 2MB limit are enacted, along with the following Spoonnet-bas=
ed
> improvements[6][7]:
>
> * A "hardfork signalling block" is a block with the sign bit of header
> nVersion is set [Clearly invalid for old nodes; easy opt-out for light
> wallets]
>
> * If the median-time-past of the past 11 blocks is smaller than the
> HardForkHeight... a hardfork signalling block is invalid.
>
> * Child of a hardfork signalling block MUST also be a hardfork signalling
> block
>
> * Hardfork network version bit is 0x02000000. A tx is invalid if the high=
est
> nVersion byte is not zero, and the network version bit is not set.
>
>
> =3D=3D=3DDeployment=3D=3D=3D
>
> Deployment of the =E2=80=9Cfast-activation=E2=80=9D soft fork is exactly =
identical to
> Hilliard=E2=80=99s segsignal proposal[2]. Deployment of the =E2=80=9Cflag=
-day=E2=80=9D soft fork is
> exactly identical to Fry=E2=80=99s BIP148 proposal[3]. HardForkHeight is =
defined as
> 26280 blocks after SegWit is set to ACTIVE. All blocks with height greate=
r
> than or equal to this value must adhere to the consensus rules of the 2MB
> hard fork.
>
>
> =3D=3D=3DBackwards compatibility=3D=3D=3D
>
> This deployment is compatible with the existing "segwit" bit 1 deployment
> scheduled between midnight November 15th, 2016 and midnight November 15th=
,
> 2017.
>
> To prevent the risk of building on top of invalid blocks, miners should
> upgrade their nodes to support segsignal as well as BIP148.
>
> The intent of this proposal is to maintain full legacy consensus
> compatibility for users up until the HardForkHeight block height, after
> which backwards compatibility is waived as enforcement of the hard fork
> consensus ruleset begins.
>
>
> =3D=3D=3DReferences=3D=3D=3D
>
> [1]
> https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133=
521fe9a77
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014380.h=
tml
> [3] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013921=
.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014399.h=
tml
> [6]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013=
542.html
> [7]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/0134=
73.html
> [8] https://twitter.com/sysmannet/status/867124645279006720
> [9] https://twitter.com/JihanWu/status/867139046786465792
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>