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
|
Return-Path: <sickpig@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 32E51C5D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 10:02:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com
[209.85.215.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53BCE106
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 10:02:14 +0000 (UTC)
Received: by mail-lf0-f42.google.com with SMTP id p203so70045993lfa.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 02:02:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=dGocxZPvOYuAsH+N8Jd6W37WuGW8F5/v9O8J7buQP5U=;
b=aTBzoUCI/0iRnQaF+JXs2egQH9IdI/HN1Q9Vd/6muB/IyH6eNpc6IgPHW3KqHG3clv
DkUzcWHFYWgz9byHou8JXFe0aznGV19kIOJt6gnWWHuqftgCQhgT1y3DNzNN2AkImXof
3yA17ouHBzprNLtfBnxakisoAhqzJSIDcES10j/yVZgiXhsEqDrTUHG38WWhnG1c2lw+
EZVuFzV3MLheHTSoRqEGBVL8PkV2CZlhZ59nn2/zrkCZyxZECl2ce4HNiTn7ewVMD3HU
BLmMoCjHHkDY4ZzL3/vO/wnKU2ISVDpNFnYRm71tN8SNzpiCwzSRw8eYo9vQbzXIVLyo
icjw==
X-Received: by 10.25.170.149 with SMTP id t143mr960079lfe.162.1450432932229;
Fri, 18 Dec 2015 02:02:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.89.139 with HTTP; Fri, 18 Dec 2015 02:01:52 -0800 (PST)
In-Reply-To: <20151217175541.GA10809@sapphire.erisian.com.au>
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>
From: "sickpig@gmail.com" <sickpig@gmail.com>
Date: Fri, 18 Dec 2015 11:01:52 +0100
Message-ID: <CA+c4Zoxp91rpcKFqs_FJD_o1e6QzUH0Hk+jm1r9ZVsL4so_VHA@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: multipart/alternative; boundary=001a11410436b2378c0527293b1f
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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
X-Mailman-Approved-At: Fri, 18 Dec 2015 11:24:07 +0000
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: Fri, 18 Dec 2015 10:02:15 -0000
--001a11410436b2378c0527293b1f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 wrot=
e:
> > 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 alre=
ady
> > > 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?
--001a11410436b2378c0527293b1f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Anthony, <br><br><div class=3D"gmail_extra"><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.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">On Thu, Dec 17, 2015 at 04:51=
:19PM +0100, sickpig--- via bitcoin-dev wrote:<br>
<span class=3D"">> On Thu, Dec 17, 2015 at 2:09 PM, Jorge Tim=C3=B3n wro=
te:<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 class=3D"">> 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 class=3D""><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>many thanks for the explanation. <br><br></div><=
div class=3D"gmail_extra">so it should be fair to say that BIP 102 + SW wou=
ld 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 the interval =
we could say <br></div><div class=3D"gmail_extra">that BIP102 + SW will bri=
ng us a max block (virtual) size equal to 1MB * 2 * 1.8 =3D 3.6<br><br></di=
v><div class=3D"gmail_extra">Is it right? <br></div><div class=3D"gmail_ext=
ra"><br><br></div><div class=3D"gmail_extra"><br></div></div>
--001a11410436b2378c0527293b1f--
|
