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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E389BEB2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 13:09:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com
[209.85.213.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B636B150
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 13:09:06 +0000 (UTC)
Received: by mail-vk0-f44.google.com with SMTP id a189so45890500vkh.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 05:09:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=ac5wTfy9q8WH3gpNfH/llgBAsEODiV4zCd1Thr3OM1Y=;
b=ArYDoCzrQpF2kTpZNAtHKq5oTjDEPkt658KvpLFALudG/j4BRpitnwmYDikk3OmRn9
oSwOqAU2xZpY2pvybaXx7u1jvnKq2TBDvrmSP0/k3fJN5hYlqQToWAy4lJvbPRfFWIjS
x8FVhTa6v6mr5rmiBB/+J60BMmqo6zhs///2Gu4Zbs+lJSfJr+agaHD0w+tSSz4n8ZZu
Axzf2xMvKOyzUMdJGODSH/ZJFpvXCLgPLk6QTiPAas2mAM6cdZwQU2OJw6eVfjnv8wzJ
2IisNojVF70hrcE5ww+mQjoL1XiVxscBsBH4JoZmbHqoEk3+AVOBU2PgPXecM0041wu6
AOJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=ac5wTfy9q8WH3gpNfH/llgBAsEODiV4zCd1Thr3OM1Y=;
b=XvzC26cSen+8J4mg4CUlj3uRPz3MaNLIPYLWD4+hXu8u1f+eVFQPaje7h21PjZEoR2
ufgNFus/C+HwGRwkTu6RW/ldpfjqC2kam9ulPjSOmR3IelCnQ8ftm7WIRFKbUC557cxh
RYWe9vOGA1xicBulJ+wbOMOw1PYvG0JP6ZnXhY78tjtTu0Vu8AKnSub+4vdAsbXqd/Wj
AgQgqAWOPdHIyPj5CHHm6D2Vlw9x4QVnP3bO02Gr5E5rOiHa5qasgxLC41ADmbltglm+
UOS0nolQ44NoeTy2JREKack21gybiBEi36SEVJZU/ov6Di+kQNxkWsnnw+2iUuplwWwW
m0gQ==
X-Gm-Message-State: ALoCoQmUyzpR0EFQfupAjZ5GTzpJZ6LsD6IHX5RVPvGiT9zYCxOP1F7+sKPKedE27o9BtEVyzy2lgPahzz1Ce5tedtoTuTBSpw==
MIME-Version: 1.0
X-Received: by 10.31.149.10 with SMTP id x10mr11663550vkd.144.1450357745749;
Thu, 17 Dec 2015 05:09:05 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Thu, 17 Dec 2015 05:09:05 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Thu, 17 Dec 2015 05:09:05 -0800 (PST)
In-Reply-To: <CAK_HAC-QmFiQGePpPH7n7qV-A4mkQdsWmgwA__mc1GBkTa6oFA@mail.gmail.com>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
<49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
<9869fe48a4fc53fc355a35cead73fca2@xbt.hk>
<CAK_HAC-QmFiQGePpPH7n7qV-A4mkQdsWmgwA__mc1GBkTa6oFA@mail.gmail.com>
Date: Thu, 17 Dec 2015 14:09:05 +0100
Message-ID: <CABm2gDp+UFua=ZqzDFhZ7F6MeLbc_fBv13WYcpttSP1Lyy1ngg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Corey Haddad <corey3@gmail.com>
Content-Type: multipart/alternative; boundary=001a11408b143bd659052717ba7e
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling
Bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Thu, 17 Dec 2015 13:09:08 -0000
--001a11408b143bd659052717ba7e
Content-Type: text/plain; charset=UTF-8
Although I agree that how safe a pre-hardfork upgrade period is depends on
the complexity of the changes (we should assume everyone may need time to
reimplementat it themselves in their own implementations, not just upgrade
bitcoin core) and bip102 is indeed a very simple hardfork, I think less
than 6 months for a hardfork is starting to push it too much.
For a more complex hardfork (say, a SW hardfork or a collection of many
little fixes) I believe 1 year or more would make more sense.
BIP99 recommends a time threshold (height or median time) + 95% miner
upgrade confirmation with BIP9 (version bits).
So how about the following plan?
1) Deploy BIP102 when its ready + 6 median time months + 95% miner upgrade
confirmation
2) Deploy SW when it's ready + 95% miner upgrade confirmation via bip9.
Note that both "when it's ready" depend on something we are not paying a
lot of attention to: bip9's implementation (just like bip113, bip68-112,
bip99, the coinbase-commitments-cleanup post-SW uncontroversial hardfork,
etc).
Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already
equivalent to the 2-4-8 "compromise" proposal (which by the way I never
liked, because I don't think anybody should be in a position to
"compromise" anything and because I don't see how "let's avoid an
unavoidable economic change for a little bit longer" arguments can
reasoably claim that "we need to kick the can down the road exactly 3 more
times" or whatever is the reasoning behind it).
--001a11408b143bd659052717ba7e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Although I agree that how safe a pre-hardfork upgrade period=
is depends on the complexity of the changes (we should assume everyone may=
need time to reimplementat it themselves in their own implementations, not=
just upgrade bitcoin core) and bip102 is indeed a very simple hardfork, I =
think less than 6 months for a hardfork is starting to push it too much.<br=
>
For a more complex hardfork (say, a SW hardfork or a collection of many lit=
tle fixes) I believe 1 year or more would make more sense.</p>
<p dir=3D"ltr">BIP99 recommends a time threshold (height or median time) + =
95% miner upgrade confirmation with BIP9 (version bits).<br>
So how about the following plan?</p>
<p dir=3D"ltr">1) Deploy BIP102 when its ready + 6 median time months + 95%=
miner upgrade confirmation</p>
<p dir=3D"ltr">2) Deploy SW when it's ready + 95% miner upgrade confirm=
ation via bip9.</p>
<p dir=3D"ltr">Note that both "when it's ready" depend on som=
ething we are not paying a lot of attention to: bip9's implementation (=
just like bip113, bip68-112, bip99, the coinbase-commitments-cleanup post-S=
W uncontroversial hardfork, etc).</p>
<p dir=3D"ltr">Unless I'm missing something, 2 mb x4 =3D 8mb, so bip102=
+ SW is already equivalent to the 2-4-8 "compromise" proposal (w=
hich by the way I never liked, because I don't think anybody should be =
in a position to "compromise" anything and because I don't se=
e how "let's avoid an unavoidable economic change for a little bit=
longer" arguments can reasoably claim that "we need to kick the =
can down the road exactly 3 more times" or whatever is the reasoning b=
ehind it).</p>
--001a11408b143bd659052717ba7e--
|
