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
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A2D88B7B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 May 2017 15:51:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com
[209.85.220.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C06B2163
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 May 2017 15:51:18 +0000 (UTC)
Received: by mail-qk0-f177.google.com with SMTP id d14so31844198qkb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 May 2017 08:51:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=8FLH0/3vTNNEoI5mu+eck4qTg+91ctz8pIpmUjuadMU=;
b=jxzaKoNMIwauuQzy2mhTlkteIWm02jycioiYorKnOpwIzkls02IlvH9RMTcxBZKbYp
wVR5IOKKBjihYjzu9fmP/FFz87+Eb3r8FpwO9GGrFL7Rs4WOZROJ5GaFMFg+K3b2eLQL
RiSKIUXErZJ5H+uHegQeJOKGDLBGHdPxRBk085eqzYTMq2d8xx4vtCmTui10+ulIRR0u
rHeGTuMS58HWnayPtEmN1Twc1n6hxxb7boXP7xl3kGMd4edv7we4H0rGpTkD/BcpDPoP
JIW3ci/8hNCM/TSRxe6v9e6qTwPop8X0nGFEG1XYhGyzDcbNNfGR4ugiobY4s5V70Qxl
2fQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=8FLH0/3vTNNEoI5mu+eck4qTg+91ctz8pIpmUjuadMU=;
b=mOUWk8JWoZL1LFtt6zW/cxGOo3iZbuDE3nPeCL6eg7jeouv9EfkhS1OWYWWRXsIZAI
RMeM/EU6+XPBi7dsHVZ13jCC3r368APwKHQvKY7Xv3uwh2e/8TCGNY8iVyk5HEo+mljW
0xOiAVI63UkALWdlytE6+EINXx9+ms+gRt24KkwPPrgZUt5sPSma7/s26qjrWy4F4q7O
srJTL97iSPixoAQDRLDFd3RpBdTLK9tf1Y7+EIIsGi4sskkc8Z1EyaBHKO1L06YKKiiR
L5wIhoJxLaz+joBoAJZWsCQhwYfxifL3RTzL5FLAfAeb7I5/BxvBUFWjz558hNyl0w2F
Auxw==
X-Gm-Message-State: AODbwcDqIIApL9CCYK3E9r5OXZ5swxuGtxTXtRZFvzULTclC6xuJweCK
EcPzV2w+RRAHhCCz+WZmVKefdM+R7Q==
X-Received: by 10.55.141.67 with SMTP id p64mr25317796qkd.164.1496159477958;
Tue, 30 May 2017 08:51:17 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.237.48.102 with HTTP; Tue, 30 May 2017 08:51:17 -0700 (PDT)
In-Reply-To: <CALhpmH3sUxa=MYtCdNMGO3AMGgmT=Tc2kcJzzpoY84syjgtP_A@mail.gmail.com>
References: <aC4avUiJPnHXxIxPlh4w2XA-SLB6ueTUlVTW7TreFwGV12L7L9CAGoB2E9msVYhV0M6xPTERpatAIeZO3kK-ikCRkwYQcJeEMHS7WWZKDAM=@protonmail.com>
<CALhpmH3sUxa=MYtCdNMGO3AMGgmT=Tc2kcJzzpoY84syjgtP_A@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 30 May 2017 11:51:17 -0400
X-Google-Sender-Auth: jZfZOMkGiN0sIkcqf2g5f6f3xdQ
Message-ID: <CAJowKg+o87tT_5vc5cB4t5nPU-LtYYidN1JWKxDBtwNZoYEdoQ@mail.gmail.com>
To: Oliver Petruzel <opetruzel@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c084666360bba0550bfc6be"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, 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
X-Mailman-Approved-At: Tue, 30 May 2017 17:32:47 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
CalvinRechner <calvinrechner@protonmail.com>
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: Tue, 30 May 2017 15:51:19 -0000
--94eb2c084666360bba0550bfc6be
Content-Type: text/plain; charset="UTF-8"
- We now are witnessing this... COOP vs LukeJr COOP, vs BIP148 vs BIP149 vs
BIP91 ... how many are there?:
https://xkcd.com/927
- If some miners and exchanges collude to enact a rapid 2MB+Segwit hard
fork coin... and calling it "bitcoin" on major exchanges this could swiftly
fragment the network.
- If this fork fails to contain an ASICBOOST defense, then this is
essentially an example of core failing to appropriately respond to the CVE
security vulnerability in time.
- A swift BIP148 release in core seems necessary to defend against this.
I am no longer in favor of adding a BIP148 option with default "false"..
I think it should be merged in...enabled, and released ASAP to defend
against these attacks.
On Mon, May 29, 2017 at 7:49 PM, Oliver Petruzel via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>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... Legacy
> Bitcoin transactions are given the witness discount, and a block size limit
> of 2 MB is imposed.<<
>
>
> The above decision may quickly become very controversial. I don't think it's
> what most users had/have in mind when they discuss a "2MB+SegWit" solution.
>
> With the current 1MB+SegWit, testing has shown us that normal usage
> results in ~2 or 2.1MB blocks.
>
> I think most users will expect a linear increase when Base Size is
> increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
> With normal usage, the expected results would then be ~4 or 4.2MB blocks.
>
> Am I missing something here, or does Luke's suggested 2MB cap completely
> nullify that expected linear increase? If so, why? What's the logic behind
> this decision?
>
> I'd love to be armed with a good answer should my colleagues ask me the
> same obvious question, so thank you ahead of time!
>
> Respectfully,
> Oliver Petruzel
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--94eb2c084666360bba0550bfc6be
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>- We now are witnessing this... COOP vs LukeJr COOP, =
vs BIP148 vs BIP149 vs BIP91 ... how many are there?:<br><br></div><div><a =
href=3D"https://xkcd.com/927">https://xkcd.com/927</a><br><br>- If some min=
ers and exchanges collude to enact a rapid 2MB+Segwit hard fork coin... and=
calling it "bitcoin" on major exchanges this could swiftly fragm=
ent the network. =C2=A0 =C2=A0</div><div><br></div><div>- If this fork fail=
s to contain an ASICBOOST defense, then this is essentially an example of c=
ore failing to appropriately respond to the CVE security vulnerability in t=
ime.=C2=A0<br><br><div>- A swift BIP148 release in core seems necessary to =
defend against this. =C2=A0 I am no longer in favor of adding a BIP148 opti=
on with default "false".. =C2=A0 I think it should be merged in..=
.enabled, and released ASAP to defend against these attacks.</div>=C2=A0</d=
iv></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, =
May 29, 2017 at 7:49 PM, Oliver Petruzel via bitcoin-dev <span dir=3D"ltr">=
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"auto"><span class=3D""><div style=3D"fon=
t-family:sans-serif;font-size:18.048px" dir=3D"auto"><span style=3D"font-si=
ze:18.048px">>>if the community wishes to adopt (by unanimous consens=
us) a 2 MB block size hardfork, this is probably the best way to do it righ=
t now... Legacy Bitcoin transactions are given the witness discount, and a =
block size limit of 2 MB is imposed.<<</span><br></div><div style=3D"=
font-family:sans-serif;font-size:18.048px" dir=3D"auto"><span style=3D"font=
-size:18.048px"><br></span></div><div style=3D"font-family:sans-serif;font-=
size:18.048px" dir=3D"auto"><span style=3D"font-size:18.048px"><br></span><=
/div></span><div style=3D"font-family:sans-serif;font-size:18.048px" dir=3D=
"auto">The above decision may quickly become very controversial. I don'=
t think<span style=3D"font-size:18.048px">=C2=A0it's what most users ha=
d/have in mind when they discuss a "2MB+SegWit" solution.=C2=A0</=
span></div><div style=3D"font-family:sans-serif;font-size:18.048px" dir=3D"=
auto"><span style=3D"font-size:18.048px"><br></span></div><div style=3D"fon=
t-family:sans-serif;font-size:18.048px" dir=3D"auto">With the current 1MB+S=
egWit, testing has shown us that normal usage results in ~2 or 2.1MB blocks=
.</div><div style=3D"font-family:sans-serif;font-size:18.048px" dir=3D"auto=
"><br></div><div style=3D"font-family:sans-serif;font-size:18.048px" dir=3D=
"auto">I think most users will expect a linear increase when Base Size is i=
ncreased to 2000000 bytes and Total Weight is increased to 8000000 bytes. W=
ith normal usage, the expected results would then be ~4 or 4.2MB blocks.</d=
iv><div style=3D"font-family:sans-serif;font-size:18.048px" dir=3D"auto"><b=
r></div><div style=3D"font-family:sans-serif;font-size:18.048px" dir=3D"aut=
o">Am I missing something here, or does Luke's suggested 2MB cap comple=
tely nullify that expected linear increase? If so, why? What's the logi=
c behind this decision?</div><div style=3D"font-family:sans-serif;font-size=
:18.048px" dir=3D"auto"><br></div><div style=3D"font-family:sans-serif;font=
-size:18.048px" dir=3D"auto">I'd love to be armed with a good answer sh=
ould my colleagues ask me the same obvious question, so thank you ahead of =
time!</div><div style=3D"font-family:sans-serif;font-size:18.048px" dir=3D"=
auto"><br></div><div style=3D"font-family:sans-serif;font-size:18.048px" di=
r=3D"auto">Respectfully,</div><div style=3D"font-family:sans-serif;font-siz=
e:18.048px" dir=3D"auto">Oliver Petruzel</div><div style=3D"font-family:san=
s-serif;font-size:18.048px" dir=3D"auto"><br></div><div style=3D"font-famil=
y:sans-serif;font-size:18.048px" dir=3D"auto"><br></div></div>
<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>
--94eb2c084666360bba0550bfc6be--
|
