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
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 252A3E31
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Dec 2015 07:51:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com
[209.85.213.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 43C87FC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Dec 2015 07:51:01 +0000 (UTC)
Received: by mail-ig0-f175.google.com with SMTP id jw2so6940607igc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 23:51:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=3GeNL0WVmr/NF9H3rLDAEIcxTyAVXglqKwG2C3DjiHw=;
b=XVk6yRb/ykCqUHdAX3Xwdtwdr2STYqDg0o3rkHC4N2Aq1lEGQMRjhCBorppGaUaUb3
4qbDD/kiUWUlagTN6Aas6UEZCxnSBwJOw8Qe+thN3Go8bq78CYfq1a9BMdaUy1Dfiu3t
dMozVIO1QsXYYh7WayDLN7id2SF9ysnAcAEpGpTIB3+eaj8AW4+LpJM801YkIlPbeQiy
ZaQDdnW13ldcbUZL4gicIOjcuXOSNfAY5Yfi9XfLMYxqZ+V+Wn6Fb2hHQoAJWCvne10h
i7VK6mAcLao92cBqHFA5twgSn8inMCWpES8HP3oxovc0MBXidhlKY3qjmhy3XlmRgDC+
/OuQ==
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:from:date
:message-id:subject:to:cc:content-type;
bh=3GeNL0WVmr/NF9H3rLDAEIcxTyAVXglqKwG2C3DjiHw=;
b=ea/3zGomYFLT2zTAMy//6AwtIKV1DvCOImkId8YWhr7E7YYAgyiQpfBE1wEogNkwE0
PdH3oNvroAHfvKpItYqe1pP4a/rdXXib8gFB0GFQCCdBU9r0pN/OXIJOhD3D84rOB2Gg
t5S7YsZCK1X317QFHv3sId5Wsg9k1Ul7zOO9soxUVPzvNzNjRT8rCw+lKDysrvBd78qx
GwEaKQSllmPeBWSCZX3rMbcvU3ZDdG5kNqw2dEJEluy0nr1ZDSj2iN9k6rBxWSsM7Qi4
iyQK/qmjcVuFWrT8yTtS0MBsrvLDpXNAlLFDGMG6ooyo1km339LfJNntsvTyIYJCPyz5
VvQg==
X-Gm-Message-State: ALoCoQnIzKLRduPxmnJPoA7+2BT1o2O920/iD7PkTj1aI4oa4V59o5dVporhpf1TZKh8iTsTWx7pj3JY61GKoufD6i4rq5aEGg==
X-Received: by 10.50.2.105 with SMTP id 9mr7662362igt.40.1450511460706; Fri,
18 Dec 2015 23:51:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.132.193 with HTTP; Fri, 18 Dec 2015 23:50:41 -0800 (PST)
X-Originating-IP: [49.218.55.28]
In-Reply-To: <CA+c4Zoxp91rpcKFqs_FJD_o1e6QzUH0Hk+jm1r9ZVsL4so_VHA@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>
<CABm2gDp+UFua=ZqzDFhZ7F6MeLbc_fBv13WYcpttSP1Lyy1ngg@mail.gmail.com>
<CA+c4Zow4qnhQZFgaY-hOJA4LUtuM_rb1xRbMAOD7gW3i2KzB9A@mail.gmail.com>
<20151217175541.GA10809@sapphire.erisian.com.au>
<CA+c4Zoxp91rpcKFqs_FJD_o1e6QzUH0Hk+jm1r9ZVsL4so_VHA@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Sat, 19 Dec 2015 15:50:41 +0800
Message-ID: <CAOG=w-tO+QCtobd=pJe_0DTNi53svKkqMY2DMO7a8x53tT0+9w@mail.gmail.com>
To: "sickpig@gmail.com" <sickpig@gmail.com>
Content-Type: multipart/alternative; boundary=089e0115fca05bc59005273b8498
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>,
Anthony Towns <aj@erisian.com.au>
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: Sat, 19 Dec 2015 07:51:03 -0000
--089e0115fca05bc59005273b8498
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Not entirely correct, no. Edge cases also matter. Segwit is described as
4MB because that is the largest possible combined block size that can be
constructed. BIP 102 + segwit would allow a maximum relay of 8MB. So you
have to be confident that an 8MB relay size would be acceptable, even if a
block full of actual transactions would be closer to 3.5MB.
On Fri, Dec 18, 2015 at 6:01 PM, sickpig--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Anthony,
>
>
> On Thu, Dec 17, 2015 at 6:55 PM, Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-dev
>> wrote:
>> > On Thu, Dec 17, 2015 at 2:09 PM, Jorge Tim=C3=B3n wrote:
>> > > Unless I'm missing something, 2 mb x4 =3D 8mb, so bip102 + SW is alr=
eady
>> > > equivalent to the 2-4-8 "compromise" proposal [...]
>> > isn't SegWit gain ~75%? hence 2mb x 1.75 =3D 3.5.
>>
>> Segwit as proposed gives a 75% *discount* to witness data with the
>> same limit, so at a 1MB limit, that might give you (eg) 2.05MB made up
>> of 650kB of base block data plus 1.4MB of witness data; where 650kB +
>> 1.4MB/4 =3D 1MB at the 1MB limit; or 4.1MB made up of 1.3MB of base plus
>> 2.8MB of witness, for 1.3MB+2.8MB/4 =3D 2MB at a 2MB limit.
>>
>> > 4x is theoric gain you get in case of 2-2 multisig txs.
>>
>> With segregated witness, 2-2 multisig transactions are made up of 94B
>> of base data, plus about 214B of witness data; discounting the witness
>> data by 75% gives 94+214/4=3D148 bytes. That compares to about 301B for
>> a 2-2 multisig transaction with P2SH rather than segwit, and 301/148
>> gives about a 2.03x gain, not a 4x gain. A 2.05x gain is what I assumed
>> to get the numbers above.
>>
>> You get further improvements with, eg, 3-of-3 multisig, but to get
>> the full, theoretical 4x gain you'd need a fairly degenerate looking
>> transaction.
>>
>> Pay to public key hash with segwit lets you move about half the
>> transaction data into the witness, giving about a 1.6x improvement by
>> my count (eg 1.6MB =3D 800kB of base data plus 800kB of witness data,
>> where 800kB+800kB/4=3D1MB), so I think a gain of between 1.6 and 2.0 is
>> a reasonable expectation to have for the proposed segwit scheme overall.
>>
>>
> many thanks for the explanation.
>
> so it should be fair to say that BIP 102 + SW would bring a gain between
> 2*1.6 and 2*2.
>
> Just for the sake of simplicity if we take the middle of the interval we
> could say
> that BIP102 + SW will bring us a max block (virtual) size equal to 1MB * =
2
> * 1.8 =3D 3.6
>
> Is it right?
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--089e0115fca05bc59005273b8498
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Not entirely correct, no. Edge cases also matter. Segwit i=
s described as 4MB because that is the largest possible combined block size=
that can be constructed. BIP 102 + segwit would allow a maximum relay of 8=
MB. So you have to be confident that an 8MB relay size would be acceptable,=
even if a block full of actual transactions would be closer to 3.5MB.<br><=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Dec =
18, 2015 at 6:01 PM, sickpig--- via bitcoin-dev <span dir=3D"ltr"><<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.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"><div dir=3D"ltr">Anthony, <br><br><div class=3D"gmail_extra">=
<div><div class=3D"h5"><br><div class=3D"gmail_quote">On Thu, Dec 17, 2015 =
at 6:55 PM, Anthony Towns via bitcoin-dev <span dir=3D"ltr"><<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">On Thu, Dec 17, 2015 at 04:51:19PM +0100, sickpig--- via bitcoin-de=
v wrote:<br>
<span>> On Thu, Dec 17, 2015 at 2:09 PM, Jorge Tim=C3=B3n wrote:<br>
> > Unless I'm missing something, 2 mb x4 =3D 8mb, so bip102 + SW=
is already<br>
</span>> > equivalent to the 2-4-8 "compromise" proposal [.=
..]<br>
<span>> isn't SegWit gain ~75%? hence 2mb x 1.75 =3D 3.5.<br>
<br>
</span>Segwit as proposed gives a 75% *discount* to witness data with the<b=
r>
same limit, so at a 1MB limit, that might give you (eg) 2.05MB made up<br>
of 650kB of base block data plus 1.4MB of witness data; where 650kB +<br>
1.4MB/4 =3D 1MB at the 1MB limit; or 4.1MB made up of 1.3MB of base plus<br=
>
2.8MB of witness, for 1.3MB+2.8MB/4 =3D 2MB at a 2MB limit.<br>
<span><br>
> 4x is theoric gain you get in case of 2-2 multisig txs.<br>
<br>
</span>With segregated witness, 2-2 multisig transactions are made up of 94=
B<br>
of base data, plus about 214B of witness data; discounting the witness<br>
data by 75% gives 94+214/4=3D148 bytes. That compares to about 301B for<br>
a 2-2 multisig transaction with P2SH rather than segwit, and 301/148<br>
gives about a 2.03x gain, not a 4x gain. A 2.05x gain is what I assumed<br>
to get the numbers above.<br>
<br>
You get further improvements with, eg, 3-of-3 multisig, but to get<br>
the full, theoretical 4x gain you'd need a fairly degenerate looking<br=
>
transaction.<br>
<br>
Pay to public key hash with segwit lets you move about half the<br>
transaction data into the witness, giving about a 1.6x improvement by<br>
my count (eg 1.6MB =3D 800kB of base data plus 800kB of witness data,<br>
where 800kB+800kB/4=3D1MB), so I think a gain of between 1.6 and 2.0 is<br>
a reasonable expectation to have for the proposed segwit scheme overall.<br=
>
<br></blockquote><br></div></div></div>many thanks for the explanation. <br=
><br></div><div class=3D"gmail_extra">so it should be fair to say that BIP =
102 + SW would bring a gain between 2*1.6 and 2*2. <br></div><div class=3D"=
gmail_extra"><br>Just for the sake of simplicity if we take the middle of t=
he interval we could say <br></div><div class=3D"gmail_extra">that BIP102 +=
SW will bring us a max block (virtual) size equal to 1MB * 2 * 1.8 =3D 3.6=
<br><br></div><div class=3D"gmail_extra">Is it right? <br></div><div class=
=3D"gmail_extra"><br><br></div><div class=3D"gmail_extra"><br></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--089e0115fca05bc59005273b8498--
|
