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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6425CE5A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 10:57:23 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8F4C0194
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 10:57:22 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian))
id 1a9WFL-0000PQ-Fp for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 20:57:20 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 17 Dec 2015 20:57:13 +1000
Date: Thu, 17 Dec 2015 20:57:13 +1000
From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20151217105713.GA16561@sapphire.erisian.com.au>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
<49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
<9869fe48a4fc53fc355a35cead73fca2@xbt.hk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9869fe48a4fc53fc355a35cead73fca2@xbt.hk>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.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: Thu, 17 Dec 2015 10:57:23 -0000
On Thu, Dec 17, 2015 at 12:32:11AM -0500, jl2012 via bitcoin-dev wrote:
> There are at least 2 proposals on the table:
> 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately
> equals to 2MB actual limit
> 2. BIP102: 2MB actual limit
I think there's a few variants of (2) -- there's "just 2MB", "2MB now,
4MB in a while, 8MB after that", "1MB for a while longer, then 2MB,
then 4MB" (halved from 2/4/8 since segwit gives 1.6x-2x benefit), and
variations of those with different dates, whether or not to smooth out
the increases to avoid economic shocks, and how to determine activation
(flag day? miner consensus? combination?).
> Since the actual limits for both proposals are approximately the same, it is
> not a determining factor in this discussion
That's true on the benefit side (both give about double the number of
ordinary transactions per block; though segregated witness has other
benefits). On the cost side, the limits are different:
* worst case block data size is 2x for BIP102, 4x for segwit (affecting
bandwidth, latency and storage costs for nodes)
* worst case sigops is 2x for BIP102, but the same as today for segwit
(affecting block validation time)
* worst case bytes to hash a block is 4x for BIP102 (doubling block
size and sigops), but the same as today for segwit (again affecting
block validation time)
* worst case UTXO bloat is 2x for BIP102, but the same as today for
segwit (affecting memory usage, and validation time)
In the "expected" case (where people aren't attacking the blockchain)
I think they're the same on all these metrics. But increasing the
limits could easily make attacks more common, especially if it makes
them more effective.
I think the main attack vector of these is that increasing block
validation time via too many (active) sigops or too many bytes hashed
allows a selfish mining attack, but I'm not clear enough on how that
would work exactly to estimate where the boundary between acceptable and
unacceptable risk is (and how feasible non-consensus-level countermeasures
might be).
But at 1x sigops, you can already (accidently!) construct blocks that
take minutes to verify; and at 4x you can probably already construct a
block that takes 10 minutes to verify, which would probably be pretty
bad... But I'm not sure this isn't already exploitable, so maybe we're
already assuming a certain level of altruism and making things worse
doesn't actually make them worse?
I think it would be good for BIP102 or similar to include an evaluation
of that risk before being deployed [0].
> The major criticism for a hardfork is requiring everyone to upgrade. Is that
> really a big problem?
Yes. That doesn't mean it's not worth it, though.
(The 2-month timeline for the BIP50 accidental hardfork to be accepted
on the network seems persuasive to me that it's possible to roll out a
deliberate, SPV-compatible, hardfork on today's network in 3-6 months)
> My primary proposal:
> 1 Jun 2016: the first day a 2MB block may be allowed
>
> My secondary proposal:
> 1 Jun 2016: release SWSF
I think it makes sense to just do both of these independently; ie:
* release segwit via softfork ASAP (perhaps targetting March or April
to get it included in bitcoin, activation a month or three
afterwards?), with virtual block size calculated as proposed and
capped by MAX_BLOCK_SIZE [1]
* increase MAX_BLOCK_SIZE via hardfork to 2MB after block 420,000
(phased in gradually? with future scheduled increases to 4MB or 8MB?)
If segwit gets delayed because it's complicated, that's okay; if
it comes out earlier, that's okay too. If the hardfork gets delayed
because miners aren't ready or because it's better to introduce it in a
staggered fashion, or because there's no clear evaluation of the risks,
that's okay too.
But more importantly, it allows evaluate the pros and cons of each
implementation separately and on its own merits, rather than arguing
against working on one just because you're in favour of doing the
other ASAP.
They have benefits if you combine them too; for instance, if the
MAX_BLOCK_SIZE increase is phased in rather than done as a step increase
(ie block x's limit is 1MB, block x+1's limit is 1.005MB or similar,
and block x+2's limit is 1.01MB, etc) having segwit available in parallel
could provide a helpful escape valve: if an individual bitcoin user has
been dying for more capacity, they can spend the time/effort to update
their software for segwit and get it immediately without having to wait
as the consensus limits rise.
Conversely, having both segwit and a phased increase to MAX_BLOCK_SIZE
means that miners generally won't be immediately mining 2MB (or 4MB)
blocks halfway through the year, which should avoid both technological
shocks (bandwidth just doubled!) or economic shocks (supply has increased
so fees have plummeted), which could be good.
FWIW, the worst case scenarios are:
* block data size:
BIP102: 2x (worst/avg)
segwit: 4x (worst, ~2x avg)
both: 8x (worst, ~4x avg)
BIP101: 8x (worst/avg)
* sigops per block:
BIP102: 2x
segwit: 1x
both: 2x
BIP101: 8x
* bytes hashed per block:
BIP102: 4x
segwit: 1x
both: 4x
BIP101: 64x
* UTXO rate of increase:
BIP102: 2x
segwit: 1x
both: 2x
BIP101: 8x
Compared to the (expected, eventual, near-term) benefits:
* transactions per block:
BIP102: 2x
segwit: 1.6x-2x
both: 3.2x-4x
BIP101: 8x
* misc:
BIP101/2: planned hardforks are possible, bitcoin community governance
is demonstrably working, etc
segwit: malleability fixes, script improvements, lightning
enablement, etc
The block data is the only case where the average case is already just
about the worst case; for the others, as long as the worst case doesn't
inspire new attacks, the future average case should just increase in
proportion to the additional transactions.
Cheers,
aj
[0] (and segwit should actually account for sigops in witness data before
being deployed...)
[1] If segwit warrants a hardfork to clean up data structures, I think
that should be deferred until well after the MAX_BLOCK_SIZE hardfork,
rather than trying to do it at the same time. As such, doing segwit by
soft fork in the short term seems to make sense, since it also helps
with transaction malleability and further improvements to script.
|
