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
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
|
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F0FE2978
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 May 2017 13:49:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com
[209.85.216.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BE7F919C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 May 2017 13:49:46 +0000 (UTC)
Received: by mail-qt0-f181.google.com with SMTP id j29so1034471qtj.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 09 May 2017 06:49:46 -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=MLjZFgEUN4hVdvKC5Mj1y6JPAWEYrKVzXlNVWcSJI5Q=;
b=Z5Csqh3ZQf+2rWNxENKdN28FjKBS8yQRCXM655F46MOVqvB01hOLyywGymZI/o7HV9
88qcIl7xgMxqSbxI+H4HEAYb7TvfpkiyBJxoOTmQcPx4HZqhGhwPvOCQB1lKQOTI5BLK
Zy5g05cnPrYYKoVw8y+nbLXZ2/uohYLump3PmA0yEma8I8IjrNcx0ijOc3vKF57r8aLN
iKeqNgA4BZCwKlRYMk3YiNbmT7/ir2dTzju0xHvxisZdcfJhLCIrEfPXt0rcFLlM4G+l
STxnkxN+UtmVEPT7Mt6yIP6Wqf2jmQf3zlEL9fC7tkRBaYZ6y0JD1BKkZOF1wxtJFQz6
otpw==
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=MLjZFgEUN4hVdvKC5Mj1y6JPAWEYrKVzXlNVWcSJI5Q=;
b=Q73+24rY0iUBSsUgKQsTZbv1PYbbl0xXqr0FhBphEf4ywBORlRfo7njScsux0MVEkN
NK0Dct/NOh7fasfZ4Uggn+ZIjuBcMXLiAU2E0wdKNXlxaIkb43c4WlVzStY6j4nZL9Y9
CIxAVqJe39OoKDLMursd334jUp7GoKFU4D2VltAnNRfwLnrKNi5Mu9vEzee2PQLE+iZ1
2XGT0Y8pFLNHtRlgttGUSB/U7zQIRgZ1LIxjw72v5e6lXfZ5HbXBQOH7j2RhuWy9WAxd
XSomX32MbWuJKfUzChkWJymEhGPt7zC5Kmf8L+XDwY6fACzP6cIjtVwlyOu26pvurp1a
vVNw==
X-Gm-Message-State: AODbwcBIdi025Ft5rX3KjiJjiVnzHlxTeu2drNB9RrKDmDwbjzXLSNEH
dEs6sIWeI/ufiIAV0LGm7l9iQOcytQ==
X-Received: by 10.200.37.227 with SMTP id f32mr135633qtf.221.1494337785808;
Tue, 09 May 2017 06:49:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.165.132 with HTTP; Tue, 9 May 2017 06:49:05 -0700 (PDT)
In-Reply-To: <CAMBsKS_j7Lso6fHoMPkrQ7UFwKfxOERAAqL=aUF83O4CqL+iFg@mail.gmail.com>
References: <CAKzdR-qojNn8OtUTPbxa0JauK9nmo2ZGm4ihKuyzsz_FAgokDw@mail.gmail.com>
<CAMBsKS_j7Lso6fHoMPkrQ7UFwKfxOERAAqL=aUF83O4CqL+iFg@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Tue, 9 May 2017 10:49:05 -0300
Message-ID: <CAKzdR-on-w9EF+2hLjchdyHB1gj7fi4QnybA=J4Cz7yyN3KKNA@mail.gmail.com>
To: Alphonse Pace <alp.bitcoin@gmail.com>
Content-Type: multipart/alternative; boundary=001a11403598e5cd76054f17a069
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM 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>
Subject: Re: [bitcoin-dev] Some real-world results about the current Segwit
Discount
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, 09 May 2017 13:49:48 -0000
--001a11403598e5cd76054f17a069
Content-Type: text/plain; charset=UTF-8
This [1] article says the current discount prevents witness spam. Witness
spam is free space in the witness part of the block that can be filled by
miners to create bigger blocks with almost no cost for the benefit a
cluster of miners with low latency, increasing centralization.
The 75% discount does not prevent it, but on the contrary leaves a lot of
extra witness space for spam.
If the maximum block weight is set to 2.7M, each byte of non-witness block
costs 1.7, and each byte of witness costs 1, then a normal filled block
would be 2.7M bytes (1.7+1), and there will be no need to create ever a 4
Mbyte block. The worst case would be the average case, and the transaction
rate would be the maximum possible.
The current 75% discount can only achieve more transactions per second if
the type of transactions change. Therefore the current 75% discount only
makes the block size worst case worse (4 Mbytes when it should be 2.7
Mbytes).
80% of all inputs/outputs are P2PKH. The only way to make use of the extra
witness
space If most P2PKH transactions are replaced by multisigs (typically for
LN).
So it seems the 75% discount has been chosen with the idea that in the
future the current transaction pattern will shift towards multisigs. This
is not a bad idea, as it's the only direction Bitcoin can scale without a
HF.
But it's a bad idea if we end up doing, for example, a 2X blocksize
increase HF in the future. In that case it's much better to use a 50%
witness discount, and do not make scaling risky by making the worse case
block size 8 Mbytes, when it could have been 2*2.7=5.4 Mbytes.
I've uploaded the code here:
https://github.com/SergioDemianLerner/SegwitStats
[1] https://segwit.org/why-a-discount-factor-of-4-why-not-
2-or-8-bbcebe91721e.
On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Sergio,
>
> I'm not sure what the data you present has to do with the discount. A 75%
> discount prevents witness spam precisely because it is 75%, nothing more.
> The current usage simply gives a guideline on how much capacity is gained
> through a particular discount. With the data you show, it would imply that
> those blocks, with SegWit used where possible, would result in blocks of
> ~1.8MB.
>
>
>
> On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I have processed 1000 blocks starting from Block #461653.
>>
>> I computed several metrics, including the supposed size of witness data
>> and non-witness data (onchain), assuming all P2SH inputs/outputs are
>> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
>>
>> This takes into account that other types of transactions will not be
>> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
>> take into account that LN transactions may affect the current state,
>> increasing the segwit/nosegwit ratio.
>>
>> Among a lot of information, I've got the following real world results...
>>
>> acMainChainSpace =352608924
>> acSegwitSpace =599400403
>> Ratio segwit/nosegwit=1.6999
>>
>> This implies that the 75% that discount is not the best option to prevent
>> witness spam in a block of 4 MB, as stated in
>> https://segwit.org/why-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e
>> .
>>
>> The non-witness data weight factor should not be 4 but 2.35. The closest
>> integer value is 2, which leads to a 50% witness discount.
>>
>> The Bitcoinj source code is available for anyone to review. I encourage
>> anyone to re-compute this with another utility to cross-check. Maybe
>> Antoine Le Calvez (p2sh.info) would like to double-check.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a11403598e5cd76054f17a069
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This [1] article says the current discount prevents witnes=
s spam. Witness spam is free space in the witness part of the block that ca=
n be filled by miners to create bigger blocks with almost no cost for the b=
enefit a cluster of miners with low latency, increasing centralization.<div=
><br><div>The 75% discount does not prevent it, but on the contrary leaves =
a lot of extra witness space for spam.</div><div><br></div><div>If the maxi=
mum block weight is set to 2.7M, each byte of non-witness block costs 1.7, =
and each byte of witness costs 1, then a normal filled block would be 2.7M =
bytes (1.7+1), and there will be no need to create ever a 4 Mbyte block. Th=
e worst case would be the average case, and the transaction rate would be t=
he maximum possible.</div><div><br></div><div>The current 75% discount can =
only achieve more transactions per second if the type of transactions chang=
e. Therefore the current 75% discount only makes the block size worst case =
worse (4 Mbytes when it should be 2.7 Mbytes).</div><div><br></div><div>80%=
of all inputs/outputs are P2PKH. The only way to make use of the extra wit=
ness=C2=A0</div><div>space If most P2PKH transactions are replaced by multi=
sigs (typically for LN).</div><div><br></div><div>So it seems the 75% disco=
unt has been chosen with the idea that in the future the current transactio=
n pattern will shift towards multisigs. This is not a bad idea, as it's=
the only direction Bitcoin can scale without a HF.=C2=A0</div><div>But it&=
#39;s a bad idea if we end up doing, for example, a 2X blocksize increase H=
F in the future. In that case it's much better to use a 50% witness dis=
count, and do not make scaling risky by making the worse case block size 8 =
Mbytes, when it could have been 2*2.7=3D5.4 Mbytes.</div><div><br></div><di=
v>I've uploaded the code here:<br></div><div><a href=3D"https://github.=
com/SergioDemianLerner/SegwitStats">https://github.com/SergioDemianLerner/S=
egwitStats</a><br></div><div><br></div><div><div><div><div><div><span style=
=3D"font-size:12.8px">=C2=A0[1]=C2=A0</span><a href=3D"https://segwit.org/w=
hy-a-discount-factor-of-4-why-not-2-or-8-bbcebe91721e" target=3D"_blank" st=
yle=3D"font-size:12.8px">https://segwit.org/why-a-<wbr>discount-factor-of-4=
-why-not-<wbr>2-or-8-bbcebe91721e</a><span style=3D"font-size:12.8px">.</sp=
an><br></div></div></div></div></div></div><div><span style=3D"font-size:12=
.8px"><br></span></div></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Mon, May 8, 2017 at 8:47 PM, Alphonse Pace via bitcoin-dev <=
span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Sergio,<div><br></=
div><div>I'm not sure what the data you present has to do with the disc=
ount.=C2=A0 A 75% discount prevents witness spam precisely because it is 75=
%, nothing more.=C2=A0 The current usage simply gives a guideline on how mu=
ch capacity is gained through a particular discount.=C2=A0 With the data yo=
u show, it would imply that those blocks, with SegWit used where possible, =
would result in blocks of ~1.8MB.</div><div><br></div><div><br></div></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div><div class=
=3D"h5">On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-de=
v <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></div></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=
=3D"h5"><div dir=3D"ltr">I have processed 1000 blocks starting from=C2=A0Bl=
ock #461653.<div><br></div><div>I computed several metrics, including the s=
upposed size of witness data and non-witness data (onchain), assuming all P=
2SH inputs/outputs are converted to P2PWSH and all P2PKH inputs/outputs=C2=
=A0are converted to P2WPKH.</div><div><br></div><div>This takes into accoun=
t that other types of transactions will not be modified by Segwit (e.g. OP_=
RETURN outputs, or P2PK). This analysis doesn't take into account that =
LN transactions may affect the current state, =C2=A0increasing the segwit/n=
osegwit ratio.</div><div><br></div><div>Among a lot of information, I'v=
e got the following real world results...</div><div><br></div><div><div>acM=
ainChainSpace =3D352608924</div><div>acSegwitSpace =3D599400403</div><div>R=
atio segwit/nosegwit=3D1.6999</div></div><div><br></div><div>This implies t=
hat the 75% that discount is not the best option to prevent witness spam in=
a block of 4 MB, as stated in <a href=3D"https://segwit.org/why-a-discount=
-factor-of-4-why-not-2-or-8-bbcebe91721e" target=3D"_blank">https://segwit.=
org/why-a-disco<wbr>unt-factor-of-4-why-not-2-or-<wbr>8-bbcebe91721e</a>.</=
div><div><br></div><div>The non-witness data weight factor should not be 4 =
but 2.35. The closest integer value is 2, which leads to a 50% witness disc=
ount.<br></div><div><br></div><div>The Bitcoinj source code is available fo=
r anyone to review. I encourage anyone to re-compute this with another util=
ity to cross-check. Maybe Antoine Le Calvez (<a href=3D"http://p2sh.info" t=
arget=3D"_blank">p2sh.info</a>) would like to double-check.</div><div><div>=
<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div=
></div>
<br></div></div>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
<br></blockquote></div><br></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>
--001a11403598e5cd76054f17a069--
|