summaryrefslogtreecommitdiff
path: root/d0/d954f80c735ce009788f0b6d18fdf599e053b7
blob: c57087e11192089c99546dc0697e25fdc7951af9 (plain)
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
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
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 7F5F5C27
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 22:29:46 +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 133C5129
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 22:29:44 +0000 (UTC)
Received: from [IPv6:2607:fb90:425:b960:629c:55cd:a49a:a9a9] (unknown
	[172.56.38.58])
	by mail.bluematt.me (Postfix) with ESMTPSA id 1CB5D5B3D4;
	Wed, 16 Dec 2015 22:29:42 +0000 (UTC)
In-Reply-To: <CADL_X_dm-Sn2Mo7r746FyH9655cKBajtj-TJnhS47o2Oa-M7yQ@mail.gmail.com>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
	<49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
	<CADL_X_dm-Sn2Mo7r746FyH9655cKBajtj-TJnhS47o2Oa-M7yQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----9R2UNZY4AM4D9I6Q15AUKHAPJQFK5L"
Content-Transfer-Encoding: 8bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Date: Wed, 16 Dec 2015 22:29:39 +0000
To: Jameson Lopp <jameson.lopp@gmail.com>
Message-ID: <C8923572-D307-423B-8D35-8F1AEA8627E0@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin development mailing list <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: Wed, 16 Dec 2015 22:29:46 -0000

------9R2UNZY4AM4D9I6Q15AUKHAPJQFK5L
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8

We should probably start by defining "economically important". To me, it's pretty clear that every, or at least around 99% of, " economically important" node have upgraded by the time the fork kicks in, with way more than sufficient time given to everyone to upgrade (minding that this is not an emergency situation and that people have lives and many Bitcoin services are hobby projects and upgrading isn't always as easy as just restarting your node). I'd define "economically important" as any node that is used for anything more than simply "being a node" (ie people who started a node to provide resources to the network, and only using their node for that). Note, of course, that we should avoid breaking all such "non-economically important" nodes, but breaking many of them is not a big deal. Note that my proposal includes nodes such as the one doing transaction selection for the relay network. Though it is not used for payments, if it is not upgraded, things will break.

With this definition in mind, I think a year is an aggressive timeline.

On December 16, 2015 1:51:47 PM PST, Jameson Lopp <jameson.lopp@gmail.com> wrote:
>On Wed, Dec 16, 2015 at 12:50 PM, Matt Corallo via bitcoin-dev <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> A large part of your argument is that SW will take longer to deploy
>than a
>> hard fork, but I completely disagree. Though I do not agree with some
>> people claiming we can deploy SW significantly faster than a hard
>fork,
>> once the code is ready (probably a six month affair) we can get it
>deployed
>> very quickly. It's true the ecosystem may take some time to upgrade,
>but I
>> see that as a feature, not a bug - we can build up some fee pressure
>with
>> an immediate release valve available for people to use if they want
>to pay
>> fewer fees.
>>
>> On the other hand, a hard fork, while simpler for the ecosystem to
>upgrade
>> to, is a 1-2 year affair (after the code is shipped, so at least
>1.5-2.5
>> from today if we all put off heads down and work). One thing that has
>> concerned me greatly through this whole debate is how quickly people
>seem
>> to think we can roll out a hard fork. Go look at the distribution of
>node
>> versions on the network today and work backwards to get nearly every
>node
>> upgraded... Even with a year between fork-version-release and
>> fork-activation, we'd still kill a bunch of nodes and instead of
>reducing
>> their security model, lead them to be outright robbed.
>>
>>
>Over a year seems to be an extraordinarily long time frame is for
>deploying
>a hard fork. It looks like <https://bitnodes.21.co/dashboard/?days=365>
>75%
>of reachable nodes have upgraded in the past 6 months while as much as
>25%
>may not have been upgraded in over a year. However, viewing historical
>stats of version upgrades doesn't seem to be an appropriate comparison
>because node operators have never been faced with the same incentive to
>upgrade. We can point to unintentional forks in the past that have been
>resolved fairly quickly by reaching out to miners, but it's also a poor
>comparison. Unfortunately, we have no way of knowing what percentage of
>nodes are economically important - a great deal of them may be running
>and
>not even be used by the operators.
>
>Perhaps it would be better if we were to formalize the expectations for
>full node operators, but it seems to me that node operators have a
>responsibility to keep themselves informed and decide when it is
>appropriate to update their software. I'm not so sure that it's the
>rest of
>the ecosystem's responsibility to wait around for laggards.
>
>- Jameson
>
>On December 16, 2015 12:38:30 PM PST, Jeff Garzik via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>
>>> 1. Summary
>>>
>>> Segregated Witness (SegWitness, SW) is being presented in the
>context of
>>> Scaling Bitcoin.  It has useful attributes, notably addressing a
>major
>>> malleability vector, but is not a short term scaling solution.
>>>
>>>
>>> 2. Definitions
>>>
>>> Import Fee Event, ECE, TFM, FFM from previous email.
>>>
>>> Older clients - Any software not upgraded to SW
>>>
>>> Newer clients - Upgraded, SW aware software
>>>
>>>
>>> Block size - refers to the core block economic resource limit ed by
>>> MAX_BLOCK_SIZE.  Witness data (or extension block data) is excluded.
>>> Requires a hard fork to change.
>>>
>>> Core block - Current bitcoin block, with upper bound MAX_BLOCK_SIZE.
> Not
>>> changed by SW.
>>>
>>>
>>> Extended transaction - Newer, upgraded version of transaction data
>format.
>>>
>>> Extended block - Newer, upgraded version of block data format.
>>>
>>>
>>> EBS - Extended block size.  Block size seen by newer clients.
>>>
>>>
>>> 3. Context of analysis
>>>
>>> One proposal presents SW *in lieu of* a hard fork block size
>increase.
>>> This email focuses directly on that.
>>>
>>> Useful features outside block size context, such as
>anti-malleability or
>>> fraud proof features, are not covered in depth.
>>>
>>>
>>> 4.1.  Observations on data structure formats and views
>>>
>>> SW creates two *views* of each transaction and block.  SW has blocks
>and
>>> extended blocks.  Similarly, there exists transactions and extended
>>> transactions.
>>>
>>> This view is rendered to clients depending on compatibility level. 
>Newer
>>> clients see extended blocks and extended transactions.  Older
>clients see
>>> blocks (limit 1M), and do not see extended blocks.  Older clients
>see
>>> upgraded transactions as unsigned, anyone-can-pay transactions.
>>>
>>> Each extended transaction exists in two states, one unsigned and one
>>> signed, each of which passes validation as a valid bitcoin
>transaction.
>>>
>>>
>>> 4.2.  Observations on behavior of older transaction creation
>>>
>>> Transactions created by older clients will not use the extended
>>> transaction format.  All data is stored the standard 1M block as
>today.
>>>
>>>
>>> 4.3.  Observations on new block economic model
>>>
>>> SW complicates block economics by creating two separate, supply
>limited
>>> resources.
>>>
>>> The core block economic resource is heavily contended.  Older
>clients use
>>> core blocks exclusively.  Newer clients use core block s more
>>> conservatively, storing as much data as possible in extended blocks.
>>>
>>> The extended block economic resource is less heavily contended,
>though
>>> that of course grows over time as clients upgrade.
>>>
>>> Because core blocks are more heavily contended, it is presumed that
>older
>>> clients will pay a higher fee than newer clients (subject to
>elasticity
>>> etc.).
>>>
>>>
>>> 5.1.  Problem:  Pace of roll-out will be slow - Whole Ecosystem must
>be
>>> considered.
>>>
>>> The current apparent proposal is to roll out Segregated Witness as a
>soft
>>> fork, and keep block size at 1M.
>>>
>>> The roll-out pace cannot simply be judged by soft fork speed - which
>is
>>> months at best.  Analysis must the layers above:  Updating
>bitcoin-core
>>> (JS) and bitcoinj (Java), and then the timelines to roll out those
>updates
>>> to apps, and then the timeline to update those apps to create
>extended
>>> transactions.
>>>
>>> Overall, wallet software and programmer libraries must be upgraded
>to
>>> make use of this new format, adding many more months (12+ in some
>stacks)
>>> to the roll out timeline.  In the meantime, clients continue to
>contend
>>> entirely for core block space.
>>>
>>>
>>> 5.2.  Problem:   Hard fork to bigger block size Just Works(tm) with
>most
>>> software, unlike SW.
>>>
>>> A simple hard fork such as BIP 102 is automatically compatible with
>the
>>> vast range of today's ecosystem software.
>>>
>>> SW requires merchants to upgrade almost immediately, requires wallet
>and
>>> other peripheral software upgrades to make use of.  Other updates
>are
>>> opt-in and occur more slowly.  BIP 70 processors need some updates.
>>>
>>> The number of LOC that must change for BIP 102 is very small, and
>the
>>> problem domain well known, versus SW.
>>>
>>>
>>> 5.3.  Problem:   Due to pace, Fee Event not forestalled.
>>>
>>> Even presuming SW is merged into Bitcoin Core tomorrow, this does
>not
>>> address the risk of a Fee Event and associated Economic Change in
>the
>>> coming months.
>>>
>>>
>>> 5.4.  Problem:   More complex economic policy, new game theory, new
>>> bidding structure risks.
>>>
>>> Splitting blocks into two pieces, each with separate and distinct
>>> behaviors and resource values, creates *two fee markets.*
>>>
>>> Having two pricing strata within each block has certainly feasible -
>that
>>> is the current mining policy of (1) fee/KB followed by (2)
>priority/age.
>>>
>>> Valuable or not - e.g. incentivizing older clients to upgrade - the
>fact
>>> remains that SW creates a more-complex bidding structure by creating
>a
>>> second economic resource.
>>>
>>> *This is clearly a change to a new economic policy* with standard
>risks
>>> associated with that.  Will that induce an Economic C hange Event
>(see def
>>> last email)?  *Unlikely*, due to slow rollout pace.
>>>
>>>
>>> 5.5.  Problem:  Current SW mining algorithm needs improvement
>>>
>>> Current SW block template maker does a reasonable job, but makes
>some
>>> naive assumptions about the fee market across an entire extended
>block.
>>> This is a mismatch with the economic reality (just described).
>>>
>>> 5.6.   Problem:  New, under-analyzed attack surfaces
>>>
>>> Less significant and fundamental but still worth noting.
>>>
>>> This is not a fundamental SW problem, but simply standard complexity
>risk
>>> factors:  splitting the signatures away from transactions, and
>creating a
>>> new apparently-unsigned version of the transaction opens t he
>possibility
>>> of some network attacks which cause some clients to degrade down
>from
>>> extended block to core block mode temporarily.
>>>
>>> There is a chance of a failure mode that fools older clients into
>>> thinking fraudulent data is valid (judgement: unlikely vis hashpower
>but
>>> not impossible)
>>>
>>> 6. Conclusions and recommendations
>>>
>>> It seems unlikely that SW provides scaling in the short term, and SW
>>> introduces new economics complexities.
>>>
>>> A "short term bump" hard fork block size increase addresses economic
>and
>>> ecosystem risks that SW does not.
>>>
>>> Bump + SW should proce ed in parallel, independent tracks, as
>orthogonal
>>> issues.
>>>
>>>
>>> 7. Appendix - Other SW comments
>>>
>>> Hard forks provide much stronger validation, and ensure the network
>>> operates at a fully trustless level.
>>>
>>> SW hard fork is preferred, versus soft fork.  Soft forking SW places
>a
>>> huge amount of trust on miners to validate transaction signatures,
>versus
>>> the rest of the network, as the network slowly upgrades to newer
>clients.
>>>
>>> An SW hard fork could also add several zero-filled placeholders in a
>>> merkle tree for future use.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> 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
>>
>>

------9R2UNZY4AM4D9I6Q15AUKHAPJQFK5L
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

<html><head></head><body>We should probably start by defining &quot;economically important&quot;. To me, it&#39;s pretty clear that every, or at least around 99% of, &quot; economically important&quot; node have upgraded by the time the fork kicks in, with way more than sufficient time given to everyone to upgrade (minding that this is not an emergency situation and that people have lives and many Bitcoin services are hobby projects and upgrading isn&#39;t always as easy as just restarting your node). I&#39;d define &quot;economically important&quot; as any node that is used for anything more than simply &quot;being a node&quot; (ie people who started a node to provide resources to the network, and only using their node for that). Note, of course, that we should avoid breaking all such &quot;non-economically important&quot; nodes, but breaking many of them is not a big deal. Note that my proposal includes nodes such as the one doing transaction selection for the relay network
 .
Though it is not used for payments, if it is not upgraded, things will break.<br>
<br>
With this definition in mind, I think a year is an aggressive timeline.<br><br><div class="gmail_quote">On December 16, 2015 1:51:47 PM PST, Jameson Lopp &lt;jameson.lopp@gmail.com&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><div class="gmail_extra"><br /><div class="gmail_quote">On Wed, Dec 16, 2015 at 12:50 PM, Matt Corallo via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br /><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>A large part of your argument is that SW will take longer to deploy than a hard fork, but I completely disagree. Though I do not agree with some people claiming we can deploy SW significantly faster than a hard fork, once the code is ready (probably a six month affair) we can get it deployed very quickly. It&#39;s true the ecosystem may take some time to upgrade, but I see that as a feature, not a bug - we can build up some fee pressure with an immediate release valve available for people to use if they want to pay fewer fees.
 <br />
<br />
On the other hand, a hard fork, while simpler for the ecosystem to upgrade to, is a  1-2 year affair (after the code is shipped, so at least 1.5-2.5 from today if we all put off heads down and work). One thing that has concerned me greatly through this whole debate is how quickly people seem to think we can roll out a hard fork. Go look at the distribution of node versions on the network today and work backwards to get nearly every node upgraded... Even with a year between fork-version-release and fork-activation, we&#39;d still kill a bunch of nodes and instead of reducing their security model, lead them to be outright robbed.<br /><br /></div></blockquote><div class="gmail_quote"><br /></div>Over a year seems to be an extraordinarily long time frame is for deploying a hard fork. <a href="https://bitnodes.21.co/dashboard/?days=365">It looks like</a> 75% of reachable nodes have upgraded in the past 6 months while as much as 25% may not have been upgraded in over a year. Howev
 er,
viewing historical stats of version upgrades doesn&#39;t seem to be an appropriate comparison because node operators have never been faced with the same incentive to upgrade. We can point to unintentional forks in the past that have been resolved fairly quickly by reaching out to miners, but it&#39;s also a poor comparison. Unfortunately, we have no way of knowing what percentage of nodes are economically important - a great deal of them may be running and not even be used by the operators.</div><div class="gmail_quote"><div><br /></div><div>Perhaps it would be better if we were to formalize the expectations for full node operators, but it seems to me that node operators have a responsibility to keep themselves informed and decide when it is appropriate to update their software. I&#39;m not so sure that it&#39;s the rest of the ecosystem&#39;s responsibility to wait around for laggards.</div><div><br /></div><div>- Jameson</div><div><br /></div><blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="gmail_quote"><span class="">On December 16, 2015 12:38:30 PM PST, Jeff Garzik via bitcoin-dev &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><span class=""><br /><div>1. Summary</div><div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Segregated Witness (SegWitness, SW) is being presented in the context of Scaling Bitcoin.  It has useful attributes, notably addressing a major malleability vector, but is not a short term scaling solution.</div></blockquote><div><br /></div><div>2. Definitions</div><div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Import Fee Event, ECE, TFM, FFM from previous email.</div><div><br /></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Older clients - Any software not upgraded to SW</div><div><br /></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Newer clients - Upgraded, SW aware software</div></blockquote></span><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br /></div><div>Block siz
 e -
refers to the core block economic resource limit
 ed by
MAX_BLOCK_SIZE.  Witness data (or extension block data) is excluded.  Requires a hard fork to change.</div><div><br /></div></blockquote><span class=""><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Core block - Current bitcoin block, with upper bound MAX_BLOCK_SIZE.  Not changed by SW.</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br /></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Extended transaction - Newer, upgraded version of transaction data format.</div><div><br /></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Extended block - Newer, upgraded version of block data format.</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br /></div><div>EBS - Extended block size.  Block size seen by newer clients.</div></blockquote><div><br /></div><div>3. Context of
analysis</div><div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>One proposal presents SW <i>in lieu of</i> a hard fork block size increase.  This email focuses directly on that.</div><div><br /></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Useful features outside block size context, such as anti-malleability or fraud proof features, are not covered in depth.</div></blockquote><div><br /></div><div>4.1.  Observations on data structure formats and views</div><div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">SW creates two <i>views</i> of each transaction and block.  SW has blocks and extended blocks.  Similarly, there exists transactions and extended transactions.<br /><br />This view is rendered to clients depending on compatibility level.  Newer clients see extended blocks and extended transactions.  Older clients see blocks (limit 1M), and do not s
 ee
extended blocks.  Older clients see upgraded transactions as unsigned,
anyone-can-pay transactions.<br /><br />Each extended transaction exists in two states, one unsigned and one signed, each of which passes validation as a valid bitcoin transaction.<br /></blockquote><div><br /></div>4.2.  Observations on behavior of older transaction creation<div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Transactions created by older clients will not use the extended transaction format.  All data is stored the standard 1M block as today.</div></blockquote><div><br /></div><div>4.3.  Observations on new block economic model</div><div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>SW complicates block economics by creating two separate, supply limited resources.</div><div><br /></div></blockquote></span><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>The core block economic resource is heavily contended.  Older clients use core blocks exclusively.  New
 er
clients use core block
 s more
conservatively, storing as much data as possible in extended blocks.</div><div><br /></div></blockquote><span class=""><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>The extended block economic resource is less heavily contended, though that of course grows over time as clients upgrade.</div><div><br /></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">Because core blocks are more heavily contended, it is presumed that older clients will pay a higher fee than newer clients (subject to elasticity etc.).<br /></blockquote><div><br /></div>5.1.  Problem:  Pace of roll-out will be slow - Whole Ecosystem must be considered.<div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>The current apparent proposal is to roll out Segregated Witness as a soft fork, and keep block size at 1M.</div><div><br /></div></blockquote><blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px"><div>The roll-out pace cannot simply be
  judged
by soft fork speed - which is months at best.  Analysis must the layers above:  Updating bitcoin-core (JS) and bitcoinj (Java), and then the timelines to roll out those updates to apps, and then the timeline to update those apps to create extended transactions.</div><div><br /></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Overall, wallet software and programmer libraries must be upgraded to make use of this new format, adding many more months (12+ in some stacks) to the roll out timeline.  In the meantime, clients continue to contend entirely for core block space.</div></blockquote><div><br /></div><div>5.2.  Problem:   Hard fork to bigger block size Just Works(tm) with most software, unlike SW.</div><div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>A simple hard fork such as BIP 102 is automatically compatible with the vast range of today&#39;s ecosystem software.</div><div><br
/></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>SW requires merchants to upgrade almost immediately, requires wallet and other peripheral software upgrades to make use of.  Other updates are opt-in and occur more slowly.  BIP 70 processors need some updates.</div><div><br /></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>The number of LOC that must change for BIP 102 is very small, and the problem domain well known, versus SW.</div></blockquote><div><br /></div>5.3.  Problem:   Due to pace, Fee Event not forestalled.<div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">Even presuming SW is merged into Bitcoin Core tomorrow, this does not address the risk of a Fee Event and associated Economic Change in the coming months.</blockquote><div><div><br /></div><div>5.4.  Problem:   More complex economic policy, new game theory, new bidding structure
risks.</div><div><br /></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>Splitting blocks into two pieces, each with separate and distinct behaviors and resource values, creates <i>two fee markets.</i></div></div><div><i><br /></i></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Having two pricing strata within each block has certainly feasible - that is the current mining policy of (1) fee/KB followed by (2) priority/age.</div><div><br /></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Valuable or not - e.g. incentivizing older clients to upgrade - the fact remains that SW creates a more-complex bidding structure by creating a second economic resource.</div><div><b><br /></b></div></blockquote></span><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><b>This is clearly a change to a new economic policy</b> with standard risks
associated with that.  Will that induce an Economic C
 hange
Event (see def last email)?  <b>Unlikely</b>, due to slow rollout pace.</div></blockquote><span class=""><br />5.5.  Problem:  Current SW mining algorithm needs improvement<div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Current SW block template maker does a reasonable job, but makes some naive assumptions about the fee market across an entire extended block.  This is a mismatch with the economic reality (just described).</div><div><br /></div></blockquote>5.6.   Problem:  New, under-analyzed attack surfaces<div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>Less significant and fundamental but still worth noting.</div><div><br /></div></blockquote></span><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>This is not a fundamental SW problem, but simply standard complexity risk factors:  splitting the signatures away from transactions, and creating a new apparently-uns
 igned
version of the transaction opens t
 he
possibility of some network attacks which cause some clients to degrade down from extended block to core block mode temporarily.</div><div><br /></div></blockquote><span class=""><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>There is a chance of a failure mode that fools older clients into thinking fraudulent data is valid (judgement: unlikely vis hashpower but not impossible)</div><div><br /></div></blockquote>6. Conclusions and recommendations<div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>It seems unlikely that SW provides scaling in the short term, and SW introduces new economics complexities.</div><div><br /></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>A &quot;short term bump&quot; hard fork block size increase addresses economic and ecosystem risks that SW does not.</div><div><br /></div></blockquote></span><blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px"><div>Bump + SW should proce
 ed in
parallel, independent tracks, as orthogonal issues.</div></blockquote><span class=""><div><br /></div>7. Appendix - Other SW comments<div><br /></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">Hard forks provide much stronger validation, and ensure the network operates at a fully trustless level.<br /><br />SW hard fork is preferred, versus soft fork.  Soft forking SW places a huge amount of trust on miners to validate transaction signatures, versus the rest of the network, as the network slowly upgrades to newer clients.<br /><br /></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">An SW hard fork could also add several zero-filled placeholders in a merkle tree for future use.</blockquote><br /><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"></blockquote><br /><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><br /></blockquote><div><div><div><blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px"><div><br /></div><div><br /></div></blockquote><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br /></div><div><br /></div></blockquote><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br /></div></blockquote><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br /></div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><br /></div><div><br /></div></blockquote><div><div><br /></div></div></div></div></div></div></div></div></span></div>
<p style="margin-top:2.5em;margin-bottom:1em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(0,0,0)"></p><pre><hr /><br />bitcoin-dev mailing list<br /><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br /><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br /></pre></blockquote></div></div><br />_______________________________________________<br />
bitcoin-dev mailing list<br />
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br />
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br />
<br /></blockquote></div><br /></div></div>
</blockquote></div></body></html>
------9R2UNZY4AM4D9I6Q15AUKHAPJQFK5L--