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
|
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1E9FF5A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Apr 2017 15:34:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com
[209.85.161.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 79C22136
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Apr 2017 15:34:26 +0000 (UTC)
Received: by mail-yw0-f172.google.com with SMTP id d191so49264103ywe.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 01 Apr 2017 08:34:26 -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; bh=PoZ8HdNOOoj3okjbPdgYe4VqiPjktXiccC0t76+ACOA=;
b=JGktNnwdJG/IIHnCjfUL6qJ8hMuOrxmmvDWKpyQgBVWS8vN5dOfC3izbGsHwYKaslH
D8aWT+4WUhNBOklPZqhYRarY5fgwwajSpcilrcz6dM+GA7QDzxvy3BCMdKg6DL2C3oLi
L4V/GdFgbRXH66oneQH9WevtnwHerITe1AOc356SiajipFffColwW8HOffaIBOqz94P1
dhq8q4b/D6aSzKjLqpep5ERuURxXRdHrdVoDJJxXbchvD4gt4/4813dm/8Hd/6i8Cg9t
myGKJ8m6hqILcbbO/nYgAJR27WpMZwjUOV6ehdcPMFcaOvzt4GvNvRgIelkrw5WwrgvQ
PvwA==
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=PoZ8HdNOOoj3okjbPdgYe4VqiPjktXiccC0t76+ACOA=;
b=eA+/BOy9vGv5/4YQn4Ah9Z6bH4zt9KZraT+PbnSpmsccCZ2BB1XQWoRshxOfLytEY7
smcYJvcGf7koEIxRLeO8999NfhR4lylYJSLXv9dkQPRvqev+3zK1dYmPg6qRgYRSQtNs
XBLZbKhP55nTc1LOCE62VcRi0CXN16C6uCB80/zG3M1U8INhbIYOzX2ZvOjhwrKIAXv3
xQA7FwirnF4M0Ev+QgZqKbOC1rw4c4KsbXa07aP3U8ZV3TkYtB5FgG+E9cAA/wmHJbDq
Y1VwlanVHnNEhNrJ+xseMS2W9H+a9aycaLhZ5WbXAQ17gGcXEJirOyrIYTmzTzebZWta
3x7w==
X-Gm-Message-State: AFeK/H1kGmUJvF3LyAUK0cME5bVnJxW3Vm9qXnYinLZnuc6W4tMYS3nWwJrUP7uDvDbUYcLsKbbEnfrLmSyoow==
X-Received: by 10.129.55.129 with SMTP id e123mr6265033ywa.251.1491060865602;
Sat, 01 Apr 2017 08:34:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.123.135 with HTTP; Sat, 1 Apr 2017 08:34:24 -0700 (PDT)
Received: by 10.37.123.135 with HTTP; Sat, 1 Apr 2017 08:34:24 -0700 (PDT)
In-Reply-To: <CAAt2M18=Tjw+05QCv6G7Abv=idB6ONgU9xvtrR=fn731452_mg@mail.gmail.com>
References: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com>
<1CF1FD5D-8D29-4783-823F-B3F588D5C5CE@mattcorallo.com>
<CAD1TkXse5O6nEw9-EPsNp4c56YJ+OnM=F1uf8w+tyB=_+hFzFQ@mail.gmail.com>
<CAKzdR-rFJNOZ856rA_q8C=zEUj_X561OSOwW+KZr4nRJ51w3HA@mail.gmail.com>
<CABm2gDrAHo2P7t6SjituURqMUqs_=Lbp7X=g_j8nGoNKMKCRKQ@mail.gmail.com>
<CAAt2M19PvHLY0PA6iy+wiPg10vqONDApTLDuxzEcte=KUZLoaQ@mail.gmail.com>
<CABm2gDqw2TayGvaH_nz3jrF8Cz2V=SbB4begD6+K=Ye=Msw4mg@mail.gmail.com>
<CAAt2M1_gDzEuDLSvVsJARvdCAtUyM3Yuu7TT25sbm3L-Zi6+0Q@mail.gmail.com>
<CAAt2M18=Tjw+05QCv6G7Abv=idB6ONgU9xvtrR=fn731452_mg@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
Date: Sat, 1 Apr 2017 17:34:24 +0200
Message-ID: <CAAt2M1835S3YYJ_p0_zvDR9U6EfYAt7SWTAEPNHnNfgstKpgMg@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a1149d3d83bb8cc054c1ca928
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For
Comments
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: Sat, 01 Apr 2017 15:34:27 -0000
--001a1149d3d83bb8cc054c1ca928
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Den 1 apr. 2017 16:07 skrev "Jorge Tim=C3=B3n" <jtimon@jtimon.cc>:
On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanael.l@gmail.com> wrote:
>
>
> Den 1 apr. 2017 14:33 skrev "Jorge Tim=C3=B3n via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org>:
>
> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>
>
> That would make it a hardfork, not a softfork, if done exactly as you say=
.
>
> Segwit only separates out signature data. The 1 MB limit remains, but
would
> now only cover the contents of the transaction scripts. With segwit that
> means we have two (2) size limits, not one. This is important to remember=
.
> Even with segwit + MAST for large complex scripts, there's still going to
be
> a very low limit to the total number of possible transactions per block.
And
> not all transactions will get the same space savings.
No, because of the way the weight is calculated, it is impossible to
create a block that old nodes would perceive as bigger than 1 mb
without also violating the weight limit.
After segwit activation, nodes supporting segwit don't need to
validate the 1 mb size limit anymore as long as they validate the
weight limit.
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Block_size
Huh, that's odd. It really does still count raw blockchain data blocksize.
It just uses a ratio between how many units each byte is worth for block
data vs signature data, plus a cap to define the maximum. So the current
max is 4 MB, with 1 MB of non-witness blockchain data being weighted to 4x
=3D 4 MB. That just means you replaced the two limits with one limit and a
ratio.
A hardfork increasing the size would likely have the ratio modified too.
With exactly the same effect as if it was two limits...
Either way, there's still going to be non-segwit nodes for ages.
--001a1149d3d83bb8cc054c1ca928
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div data-smartmail=3D"gmail_signature" dir=3D"auto">Den =
1 apr. 2017 16:07 skrev "Jorge Tim=C3=B3n" <jtimon@jtimon.cc&g=
t;:<br></div><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_qu=
ote"><blockquote class=3D"m_-6271071585811980159quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"m_-627107=
1585811980159elided-text">On Sat, Apr 1, 2017 at 3:15 PM, Natanael <<a h=
ref=3D"mailto:natanael.l@gmail.com" target=3D"_blank">natanael.l@gmail.com<=
/a>> wrote:<br>
><br>
><br>
> Den 1 apr. 2017 14:33 skrev "Jorge Tim=C3=B3n via bitcoin-dev&quo=
t;<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>>:<br>
><br>
> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.<br>
><br>
><br>
> That would make it a hardfork, not a softfork, if done exactly as you =
say.<br>
><br>
> Segwit only separates out signature data. The 1 MB limit remains, but =
would<br>
> now only cover the contents of the transaction scripts. With segwit th=
at<br>
> means we have two (2) size limits, not one. This is important to remem=
ber.<br>
> Even with segwit + MAST for large complex scripts, there's still g=
oing to be<br>
> a very low limit to the total number of possible transactions per bloc=
k. And<br>
> not all transactions will get the same space savings.<br>
<br>
</div>No, because of the way the weight is calculated, it is impossible to<=
br>
create a block that old nodes would perceive as bigger than 1 mb<br>
without also violating the weight limit.<br>
After segwit activation, nodes supporting segwit don't need to<br>
validate the 1 mb size limit anymore as long as they validate the<br>
weight limit. </blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0141.m=
ediawiki#Block_size" target=3D"_blank">https://github.com/bitcoin/<wbr>bips=
/blob/master/bip-0141.<wbr>mediawiki#Block_size</a><br></div><div dir=3D"au=
to"><br></div><div dir=3D"auto">Huh, that's odd. It really does still c=
ount raw blockchain data blocksize.=C2=A0</div><div class=3D"gmail_extra" d=
ir=3D"auto"><br></div><div class=3D"gmail_extra" dir=3D"auto">It just uses =
a ratio between how many units each byte is worth for block data vs signatu=
re data, plus a cap to define the maximum. So the current max is 4 MB, with=
1 MB of non-witness blockchain data being weighted to 4x =3D 4 MB. That ju=
st means you replaced the two limits with one limit and a ratio.=C2=A0</div=
><div class=3D"gmail_extra" dir=3D"auto"><br></div><div class=3D"gmail_extr=
a" dir=3D"auto">A hardfork increasing the size would likely have the ratio =
modified too. With exactly the same effect as if it was two limits...=C2=A0=
</div><div class=3D"gmail_extra" dir=3D"auto"><br></div><div class=3D"gmail=
_extra" dir=3D"auto">Either way, there's still going to be non-segwit n=
odes for ages.=C2=A0</div></div>
--001a1149d3d83bb8cc054c1ca928--
|
