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
|
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 DEA04720
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Mar 2017 09:37:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f48.google.com (mail-vk0-f48.google.com
[209.85.213.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 62E4FD0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Mar 2017 09:37:10 +0000 (UTC)
Received: by mail-vk0-f48.google.com with SMTP id r69so10936672vke.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Mar 2017 02:37:10 -0700 (PDT)
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:from:date:message-id:subject:to
:cc; bh=rLmHH8FtRJmLnEfdqrVxYs+FMATHNGJKEMQlkeOobPU=;
b=PQqrA50wym/CkK+OheZJzrBSUwWu2dhE5px5yyAmKbupSYcSXIpx9+iZ0jwDga95Nf
780zwnGw4TMmLxip6sKc27sinv1xmc32zAXjOdvp+949YroXhXoB3C5nt3b0Uu5ivjV5
XaVHx+K7icVngON32zqiT/OuqSyf48tI33Xhv24/FnI2H7WTj6CgjSN3rA3MGcyEs3Ht
+s+46PwuxfGNowXy2LOnIxLxE3bO0byQZfnftEhGC/p7mqP+fIyCV+4SNnHqTes3CP7B
KBNZW6/BpMLgF8dO8CmbvKqdPTCgkbd9U8bxMdfCyc49raWZDruSHuMgaYRrwB+I1ZYq
EZhA==
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;
bh=rLmHH8FtRJmLnEfdqrVxYs+FMATHNGJKEMQlkeOobPU=;
b=YeY2wKjScDu4dqPS2HRTAoqnMV2Gz4Uzs37yKHrKLTU8aKoVwfr6KF75pEY01+x674
aobQwBSlQ4Les8DIw9F5KyjqD/GpvjGDYxaNBpf7fkc04fO1JVy60n+tybliknGxN41I
wYwO8qT3aN1ctCxDvYPeUfFoEBN/+teW+u//CYOmt5gy83xpmv4ytmc19iKVI9L9RPp7
OBDGa7lQT4PorWYOUt6DuU27uUprCudZQVBOwSzTWIuUYE/wzW8xVhEUZcM+KY+Sq2nw
o8L4Ikx2cHKMTJFjTZD0A3BiptMFXYS3lsWSWBCIv8uU4OLAocfmlpPUZIS5YheLcfOH
Kmpw==
X-Gm-Message-State: AFeK/H2nuhZs+0n+nk2mQlw2UcxMyPZ0zg/192JDryVX1Cy9cQZY1pwDVk4ibTaxBDGhNJEyQg0copmPslDDMg==
X-Received: by 10.31.85.5 with SMTP id j5mr14360635vkb.167.1490780229255; Wed,
29 Mar 2017 02:37:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.151.136 with HTTP; Wed, 29 Mar 2017 02:37:08 -0700 (PDT)
Received: by 10.31.151.136 with HTTP; Wed, 29 Mar 2017 02:37:08 -0700 (PDT)
In-Reply-To: <CA+KqGkpFW8qDPVgY+11o_CC+6FMWUNUZ7REHJKYM9-3wbrUwYw@mail.gmail.com>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
<CA+KqGkpFW8qDPVgY+11o_CC+6FMWUNUZ7REHJKYM9-3wbrUwYw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Wed, 29 Mar 2017 11:37:08 +0200
Message-ID: <CABm2gDrN5Wt9+2sVAjRiDG_axHmxF+iFujvApBMqrs-GjBG4pg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Bram Cohen <bram@bittorrent.com>
Content-Type: multipart/alternative; boundary=001a114e605200d5d5054bdb529d
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, 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
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
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: Wed, 29 Mar 2017 09:37:11 -0000
--001a114e605200d5d5054bdb529d
Content-Type: text/plain; charset=UTF-8
While Segwit's change from 1 mb size limit to 4 mb weight limit seems to be
controversial among some users (I find that very often it is because they
have been confused about what segwit does or even outright lied about it) I
don't think it's very interesting to discuss further size increases.
I find more interesting to talk to the users and see how they think Segwit
harms them, maybe we missed something in segwit that needs to be removed
for segwit to become uncontroversial, or maybe it is just disinformation.
On the other hand, we may want to have our first uncontroversial hardfork
asap, independently of block size. For example, we could do something as
simple as fixing the timewarp attack as bip99 proposes. I cannot think of a
hf that is easier to implement or has less potential for controversy than
that.
On 29 Mar 2017 8:32 am, "Bram Cohen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> The basic idea is, as many of us agree, hard fork is risky and should
> be well prepared. We need a long time to deploy it.
>
Much as it may be appealing to repeal the block size limit now with a grace
period until a replacement is needed in a repeal and replace strategy, it's
dubious to assume that an idea can be agreed upon later when it can't be
agreed upon now. Trying to put a time limit on it runs into the possibility
that you'll find that whatever reasons there were for not having general
agreement on a new setup before still apply, and running into the
embarrassing situation of winding up sticking with the status quo after
much sturm and drang.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--001a114e605200d5d5054bdb529d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>While Segwit's change from 1 mb size limit to 4 =
mb weight limit seems to be controversial among some users (I find that ver=
y often it is because they have been confused about what segwit does or eve=
n outright lied about it) I don't think it's very interesting to di=
scuss further size increases.</div><div dir=3D"auto">I find more interestin=
g to talk to the users and see how they think Segwit harms them, maybe we m=
issed something in segwit that needs to be removed for segwit to become unc=
ontroversial, or maybe it is just disinformation.=C2=A0</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">On the other hand, we may want to have our =
first uncontroversial hardfork asap, independently of block size. For examp=
le, we could do something as simple as fixing the timewarp attack as bip99 =
proposes. I cannot think of a hf that is easier to implement or has less po=
tential for controversy than that.<br><div class=3D"gmail_extra" dir=3D"aut=
o"><br><div class=3D"gmail_quote">On 29 Mar 2017 8:32 am, "Bram Cohen =
via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"att=
ribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div class=3D"quoted-text">On Tue, Mar 28, 2=
017 at 9:59 AM, Wang Chun via bitcoin-dev <span dir=3D"ltr"><<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.<wbr>linuxfoundation.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><br>
The basic idea is, as many of us agree, hard fork is risky and should<br>
be well prepared. We need a long time to deploy it.<br></blockquote><div><b=
r></div></div><div>Much as it may be appealing to repeal the block size lim=
it now with a grace period until a replacement is needed in a repeal and re=
place strategy, it's dubious to assume that an idea can be agreed upon =
later when it can't be agreed upon now. Trying to put a time limit on i=
t runs into the possibility that you'll find that whatever reasons ther=
e were for not having general agreement on a new setup before still apply, =
and running into the embarrassing situation of winding up sticking with the=
status quo after much sturm and drang.</div><div><br></div></div></div></d=
iv>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div></div></div>
--001a114e605200d5d5054bdb529d--
|
