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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6523AB61
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 May 2017 18:15:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 28A7110A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 May 2017 18:15:49 +0000 (UTC)
Received: from [172.17.0.2] (gw.vpn.bluematt.me [144.217.106.88])
by mail.bluematt.me (Postfix) with ESMTPSA id AE9091393BA;
Tue, 9 May 2017 18:15:47 +0000 (UTC)
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>,
Alphonse Pace <alp.bitcoin@gmail.com>
References: <CAKzdR-qojNn8OtUTPbxa0JauK9nmo2ZGm4ihKuyzsz_FAgokDw@mail.gmail.com>
<CAMBsKS_j7Lso6fHoMPkrQ7UFwKfxOERAAqL=aUF83O4CqL+iFg@mail.gmail.com>
<CAKzdR-on-w9EF+2hLjchdyHB1gj7fi4QnybA=J4Cz7yyN3KKNA@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <e86d9b29-f7dd-75da-e6c6-f55648bea104@mattcorallo.com>
Date: Tue, 9 May 2017 18:15:45 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: <CAKzdR-on-w9EF+2hLjchdyHB1gj7fi4QnybA=J4Cz7yyN3KKNA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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 18:15:50 -0000
I'm not sure who wrote segwit.org, but I wouldn't take it as
authoritative reasoning why we must do X over Y.
You seem to be claiming that there is not cost for a miner to fill
"extra witness space", but this is very untrue - in order to do so they
must forgo fees on other transactions. Your analysis on worst-case vs
normal-case blocks also seems flawed - there is a single limit, and not
a separate, secondary, witness limit.
You suggested "If the maximum block weight is set to 2.7M, each byte of
non-witness block costs 1.7", but these numbers dont work out - setting
the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft
fork), not 2.7MB. If you set the max block weight to 2.7 with a 1.7x
discount, you have a hard fork. If you set the discount to 2.7x with a
2.7 weight limit, you dont get 2.7MB average-sized blocks, but smaller,
and still have the potential for padding blocks with pure-witness data
to create larger blocks.
Additionally, note that by padding blocks with larger witness data you
lose some of the CPU cost to validate as you no longer have as many
inputs (which have a maximal validation cost).
Further, I'm not sure why you're arguing for a given witness discount on
the basis of a future hardfork - it seems highly unlikely the community
is in a position to pull something like that off, and even if it were,
why set the witness discount with that assumption? If there were to be a
hardfork, we should probably tweak a bunch of parameters (see, eg, my
post from February of last year at
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012403.html).
Maybe you could clarify your proposal a bit here, because the way I read
it you seem to have misunderstood SegWit's discount system.
On 05/09/17 13:49, Sergio Demian Lerner via bitcoin-dev wrote:
> 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
> <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
> <mailto: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
> <mailto: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
> <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
> <http://p2sh.info>) would like to double-check.
>
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <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
>
|
