path: root/19/ea13dd41429a1603a3a731d0d0029363cf3647

Return-Path: <marcel@jamin.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id ECB46F24
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Dec 2015 06:14:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com
	[209.85.160.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 26FD4187
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 Dec 2015 06:14:14 +0000 (UTC)
Received: by mail-yk0-f169.google.com with SMTP id p130so7729468yka.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 22:14:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=jamin-net.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=b/ZmxedelryTBgJIxuViVKk3QYVYOesk2eok9xghdl0=;
	b=wkU3PNWLaxBfC5NlzV+AuHNs6WQ0V7/Yiihv8rT61gDj/Aot9TupLd/WpnsJC5OLOQ
	7HVfa6gCArUiy93Yl0IPiKa42+Ybrw/RG873wQ3uxOLquvX78l1fm9Ux6CgJGSkNcZL9
	hd26fBTE7vpaZ7FwgEqKfswiClM6nDYj5tGM7UJxavF1EqHU2wP3RdiaW70fcN/t5KkZ
	KckqwP4panr8At2UbKaB4h/II2vngnBkvxA+Z6VJuR+rKFMX0qvD6M/4gGadkYp8HnWH
	HHYK+pzEoXbWJJc5eiWV1WYHDSktIvhhnC+n/wrNxCWp/i8aWUU9PLfMj8h0ibn30zR3
	t/ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=b/ZmxedelryTBgJIxuViVKk3QYVYOesk2eok9xghdl0=;
	b=VBaVcQ81s9v9OHG3IVh7HekwfazVS1uvDekyTLGKUQWugDslM7YkzhEHmsnV8ECcZi
	lsZk97u2SCcHW/cwYFj2SsGEkvudCYbZxGYZBk5mWj3htNvAOWapRZp49mA0oQAB7jKu
	ZqSWv088vHiOCyYABEYhX9/Qax39wWq9xvxVk4uUI1pQoj7FatJI8K934M926CK7UpDS
	1s8Tnzp8zgZGHWyqARHXb5avdZ4MZ7SvSS8I1DxijL+n7ZHyoMFPIj+P7BNJP5xWYF7X
	iBgc+uqEdnJG+bdIQwtthrgFWOgt5Tap3RIqBoUagmwcpqZyMwKcS9xSLlhGEAPR1IGj
	Pcfw==
X-Gm-Message-State: ALoCoQkRAMTNs10sEwkaGH2FWoCbhxNUUvjFU/zKDFuf63ExTPKOeDx+l4j/dPdPNmVY3R5iGvO235ZPIoGD5iUZ69TNRq49Dw==
MIME-Version: 1.0
X-Received: by 10.129.95.6 with SMTP id t6mr12366258ywb.113.1450332853247;
	Wed, 16 Dec 2015 22:14:13 -0800 (PST)
Received: by 10.129.30.201 with HTTP; Wed, 16 Dec 2015 22:14:13 -0800 (PST)
In-Reply-To: <49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
	<49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
Date: Thu, 17 Dec 2015 07:14:13 +0100
Message-ID: <CAAUq486TDe4eRZMFYx4gkmHDU4sCEeoBZqN-MVsdFbsM9rQ6TQ@mail.gmail.com>
From: Marcel Jamin <marcel@jamin.net>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary=001a1147e4468655cf052711ee26
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,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: Thu, 17 Dec 2015 12:28:07 +0000
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: Thu, 17 Dec 2015 06:14:16 -0000

--001a1147e4468655cf052711ee26
Content-Type: text/plain; charset=UTF-8

Maybe we should first gather concrete estimates about and roughly agree on

- how long SW (SF) development will probably take

- how long the ecosystem needs to prepare for a hardfork (SW (HF) or a
simple can kicking block size increase)

Opinions differ wildly from what it looks like, but maybe we can get to
estimates that the majority here can accept.

---

Personally, I think that the disclaimer "Bitcoin is an experiment" is
pervasive. It's still a pre-release, even with a $6bn vote of confidence.
If you don't follow developments in this phase, don't upgrade and then have
an elevated risk of losing money by getting scammed, then that's a little
bit your fault. I'd absolutely support a change in mentality on that once
1.0.0 arrives, but until then is bitcoin a work-in-progress experiment and
a high risk investment.

A planned hard-fork is an experiment that needs to be run anyway. When do
we want to do that, if not now?


2015-12-16 21:50 GMT+01:00 Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> 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.
>
> 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
>
>

--001a1147e4468655cf052711ee26
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Maybe we should first gather concrete estimates about and =
roughly agree on<div><br></div><div>- how long SW (SF) development will pro=
bably take</div><div><br></div><div>- how long the ecosystem needs to prepa=
re for a hardfork (SW (HF) or a simple can kicking block size increase)</di=
v><div><br></div><div>Opinions differ wildly from what it looks like, but m=
aybe we can get to estimates that the majority here can accept.</div><div><=
br></div><div>---</div><div><br></div><div>Personally, I think that the dis=
claimer &quot;Bitcoin is an experiment&quot; is pervasive. It&#39;s still a=
 pre-release, even with a $6bn vote of confidence. If you don&#39;t follow =
developments in this phase, don&#39;t upgrade and then have an elevated ris=
k of losing money by getting scammed, then that&#39;s a little bit your fau=
lt. I&#39;d absolutely support a change in mentality on that once 1.0.0 arr=
ives, but until then is bitcoin a work-in-progress experiment and a high ri=
sk investment.</div><div><br></div><div>A planned hard-fork is an experimen=
t that needs to be run anyway. When do we want to do that, if not now?</div=
><div><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-12=
-16 21:50 GMT+01:00 Matt Corallo via bitcoin-dev <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt;</span>:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft: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 w=
ith 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 de=
ployed very quickly. It&#39;s true the ecosystem may take some time to upgr=
ade, but I see that as a feature, not a bug - we can build up some fee pres=
sure with an immediate release valve available for people to use if they wa=
nt 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 f=
rom today if we all put off heads down and work). One thing that has concer=
ned me greatly through this whole debate is how quickly people seem to thin=
k 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&#3=
9;d still kill a bunch of nodes and instead of reducing their security mode=
l, lead them to be outright robbed.<br><br><div class=3D"gmail_quote">On De=
cember 16, 2015 12:38:30 PM PST, Jeff Garzik via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a>&gt; wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">
<div dir=3D"ltr"><br><div>1. Summary</div><div><br></div><blockquote style=
=3D"margin:0 0 0 40px;border:none;padding:0px"><div>Segregated Witness (Seg=
Witness, SW) is being presented in the context of Scaling Bitcoin.=C2=A0 It=
 has useful attributes, notably addressing a major malleability vector, but=
 is not a short term scaling solution.</div></blockquote><div><br></div><di=
v>2. Definitions</div><div><br></div><blockquote style=3D"margin:0 0 0 40px=
;border:none;padding:0px"><div>Import Fee Event, ECE, TFM, FFM from previou=
s email.</div><div><br></div></blockquote><blockquote style=3D"margin:0 0 0=
 40px;border:none;padding:0px"><div>Older clients - Any software not upgrad=
ed to SW</div><div><br></div></blockquote><blockquote style=3D"margin:0 0 0=
 40px;border:none;padding:0px"><div>Newer clients - Upgraded, SW aware soft=
ware</div></blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;p=
adding:0px"><div><br></div><div>Block size - refers to the core block econo=
mic resource limit
 ed by
MAX_BLOCK_SIZE.=C2=A0 Witness data (or extension block data) is excluded.=
=C2=A0 Requires a hard fork to change.</div><div><br></div></blockquote><bl=
ockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>Core bloc=
k - Current bitcoin block, with upper bound MAX_BLOCK_SIZE.=C2=A0 Not chang=
ed by SW.</div></blockquote><blockquote style=3D"margin:0 0 0 40px;border:n=
one;padding:0px"><div><br></div></blockquote><blockquote style=3D"margin:0 =
0 0 40px;border:none;padding:0px"><div>Extended transaction - Newer, upgrad=
ed version of transaction data format.</div><div><br></div></blockquote><bl=
ockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>Extended =
block - Newer, upgraded version of block data format.</div></blockquote><bl=
ockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><br></div=
><div>EBS - Extended block size.=C2=A0 Block size seen by newer clients.</d=
iv></blockquote><div><br></div><div>3. Context of analysis</div><div><br></=
div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>On=
e proposal presents SW <i>in lieu of</i>=C2=A0a hard fork block size increa=
se.=C2=A0 This email focuses directly on that.</div><div><br></div></blockq=
uote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>U=
seful features outside block size context, such as anti-malleability or fra=
ud proof features, are not covered in depth.</div></blockquote><div><br></d=
iv><div>4.1.=C2=A0 Observations on data structure formats and views</div><d=
iv><br></div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px=
">SW creates two <i>views</i>=C2=A0of each transaction and block.=C2=A0 SW =
has blocks and extended blocks.=C2=A0 Similarly, there exists transactions =
and extended transactions.<br><br>This view is rendered to clients dependin=
g on compatibility level.=C2=A0 Newer clients see extended blocks and exten=
ded transactions.=C2=A0 Older clients see blocks (limit 1M), and do not see=
 extended blocks.=C2=A0 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.=C2=A0 Observ=
ations on behavior of older transaction creation<div><br></div><blockquote =
style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>Transactions creat=
ed by older clients will not use the extended transaction format.=C2=A0 All=
 data is stored the standard 1M block as today.</div></blockquote><div><br>=
</div><div>4.3.=C2=A0 Observations on new block economic model</div><div><b=
r></div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><di=
v>SW complicates block economics by creating two separate, supply limited r=
esources.</div><div><br></div></blockquote><blockquote style=3D"margin:0 0 =
0 40px;border:none;padding:0px"><div>The core block economic resource is he=
avily contended.=C2=A0 Older clients use core blocks exclusively.=C2=A0 New=
er clients use core block
 s more
conservatively, storing as much data as possible in extended blocks.</div><=
div><br></div></blockquote><blockquote style=3D"margin:0 0 0 40px;border:no=
ne;padding:0px"><div>The extended block economic resource is less heavily c=
ontended, though that of course grows over time as clients upgrade.</div><d=
iv><br></div></blockquote><blockquote style=3D"margin:0 0 0 40px;border:non=
e;padding:0px">Because core blocks are more heavily contended, it is presum=
ed that older clients will pay a higher fee than newer clients (subject to =
elasticity etc.).<br></blockquote><div><br></div>5.1.=C2=A0 Problem: =C2=A0=
Pace of roll-out will be slow - Whole Ecosystem must be considered.<div><br=
></div><blockquote style=3D"margin:0 0 0 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><blockquo=
te style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>The roll-out pa=
ce cannot simply be
  judged
by soft fork speed - which is months at best.=C2=A0 Analysis must the layer=
s above: =C2=A0Updating bitcoin-core (JS) and bitcoinj (Java), and then the=
 timelines to roll out those updates to apps, and then the timeline to upda=
te those apps to create extended transactions.</div><div><br></div></blockq=
uote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>O=
verall, wallet software and programmer libraries must be upgraded to make u=
se of this new format, adding many more months (12+ in some stacks) to the =
roll out timeline.=C2=A0 In the meantime, clients continue to contend entir=
ely for core block space.</div></blockquote><div><br></div><div>5.2.=C2=A0 =
Problem: =C2=A0 Hard fork to bigger block size Just Works(tm) with most sof=
tware, unlike SW.</div><div><br></div><blockquote style=3D"margin:0 0 0 40p=
x;border:none;padding:0px"><div>A simple hard fork such as BIP 102 is autom=
atically compatible with the vast range of today&#39;s ecosystem software.<=
/div><div><br></div></blockquote><blockquote style=3D"margin:0 0 0 40px;bor=
der:none;padding:0px"><div>SW requires merchants to upgrade almost immediat=
ely, requires wallet and other peripheral software upgrades to make use of.=
=C2=A0 Other updates are opt-in and occur more slowly.=C2=A0 BIP 70 process=
ors need some updates.</div><div><br></div></blockquote><blockquote style=
=3D"margin:0 0 0 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, v=
ersus SW.</div></blockquote><div><br></div>5.3.=C2=A0 Problem: =C2=A0 Due t=
o pace, Fee Event not forestalled.<div><br></div><blockquote style=3D"margi=
n:0 0 0 40px;border:none;padding:0px">Even presuming SW is merged into Bitc=
oin Core tomorrow, this does not address the risk of a Fee Event and associ=
ated Economic Change in the coming months.</blockquote><div><div><br></div>=
<div>5.4.=C2=A0 Problem: =C2=A0 More complex economic policy, new game theo=
ry, new bidding structure risks.</div><div><br></div></div><blockquote styl=
e=3D"margin:0 0 0 40px;border:none;padding:0px"><div><div>Splitting blocks =
into two pieces, each with separate and distinct behaviors and resource val=
ues, creates <i>two fee markets.</i></div></div><div><i><br></i></div></blo=
ckquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><di=
v>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=3D"margin:0 0 0 40px;bord=
er:none;padding:0px"><div>Valuable or not - e.g. incentivizing older client=
s to upgrade - the fact remains that SW creates a more-complex bidding stru=
cture by creating a second economic resource.</div><div><b><br></b></div></=
blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">=
<div><b>This is clearly a change to a new economic policy</b>=C2=A0with sta=
ndard risks associated with that.=C2=A0 Will that induce an Economic C
 hange
Event (see def last email)? =C2=A0<b>Unlikely</b>, due to slow rollout pace=
.</div></blockquote><br>5.5.=C2=A0 Problem: =C2=A0Current SW mining algorit=
hm needs improvement<div><br></div><blockquote style=3D"margin:0 0 0 40px;b=
order:none;padding:0px"><div>Current SW block template maker does a reasona=
ble job, but makes some naive assumptions about the fee market across an en=
tire extended block.=C2=A0 This is a mismatch with the economic reality (ju=
st described).</div><div><br></div></blockquote>5.6. =C2=A0 Problem: =C2=A0=
New, under-analyzed attack surfaces<div><br></div><blockquote style=3D"marg=
in:0 0 0 40px;border:none;padding:0px"><div>Less significant and fundamenta=
l but still worth noting.</div><div><br></div></blockquote><blockquote styl=
e=3D"margin:0 0 0 40px;border:none;padding:0px"><div>This is not a fundamen=
tal SW problem, but simply standard complexity risk factors: =C2=A0splittin=
g the signatures away from transactions, and creating a new apparently-unsi=
gned version of the transaction opens t
 he
possibility of some network attacks which cause some clients to degrade dow=
n from extended block to core block mode temporarily.</div><div><br></div><=
/blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"=
><div>There is a chance of a failure mode that fools older clients into thi=
nking fraudulent data is valid (judgement: unlikely vis hashpower but not i=
mpossible)</div><div><br></div></blockquote>6. Conclusions and recommendati=
ons<div><br></div><blockquote style=3D"margin:0 0 0 40px;border:none;paddin=
g:0px"><div>It seems unlikely that SW provides scaling in the short term, a=
nd SW introduces new economics complexities.</div><div><br></div></blockquo=
te><blockquote style=3D"margin:0 0 0 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><bl=
ockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>Bump + SW=
 should proce
 ed in
parallel, independent tracks, as orthogonal issues.</div></blockquote><div>=
<br></div>7. Appendix - Other SW comments<div><br></div><blockquote style=
=3D"margin:0 0 0 40px;border:none;padding:0px">Hard forks provide much stro=
nger validation, and ensure the network operates at a fully trustless level=
.<br><br>SW hard fork is preferred, versus soft fork.=C2=A0 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 c=
lients.<br><br></blockquote><blockquote style=3D"margin:0 0 0 40px;border:n=
one;padding:0px">An SW hard fork could also add several zero-filled placeho=
lders in a merkle tree for future use.</blockquote><br><blockquote style=3D=
"margin:0 0 0 40px;border:none;padding:0px"></blockquote><br><blockquote st=
yle=3D"margin:0 0 0 40px;border:none;padding:0px"><br></blockquote><div><di=
v><div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div=
><br></div><div><br></div></blockquote><div><blockquote style=3D"margin:0 0=
 0 40px;border:none;padding:0px"><div><br></div><div><br></div></blockquote=
><div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>=
<br></div></blockquote><div><blockquote style=3D"margin:0 0 0 40px;border:n=
one;padding:0px"><div><br></div></blockquote><blockquote style=3D"margin:0 =
0 0 40px;border:none;padding:0px"><div><br></div><div><br></div></blockquot=
e><div><div><br></div></div></div></div></div></div></div></div></div>
<p style=3D"margin-top:2.5em;margin-bottom:1em;border-bottom:1px solid #000=
"></p><pre><hr><br>bitcoin-dev mailing list<br><a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound=
ation.org</a><br><a href=3D"https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev</a><br></pre></blockquote></div></div><br>__________=
_____________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div></div></div>

--001a1147e4468655cf052711ee26--