path: root/45/934edd7fbd3736fb5b8df5f51c7be991d25848

Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C516F22
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 20:38:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
	[209.85.213.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1C78214D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 20:38:31 +0000 (UTC)
Received: by mail-ig0-f169.google.com with SMTP id to4so82972925igc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Dec 2015 12:38:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:date:message-id:subject:from:to:content-type;
	bh=AUYhr72AflF7eZuhigKgewhdZdIlWHtBz6V+E9ld0bs=;
	b=OjdpiMQ0pg0I9Nu+OkGHzWxlz9pkPb1Z3o8GqZ5cap5OAmWm4mLGCMG9ck3eY/VIY6
	Gj0d2l92DHSwKZupQRvS+9KP4KuKrGmKvXV2r7HeTXIrKuxiUOPpOmRxHWnhP8cJvG1H
	j7DJB36DZGqG7XHsFVcevZ2t+kXjhy1CwhEKkBhsbJNTwKkTd4iS2+mQ4DuE2h0H+ZgD
	kSnIoMi77L7WgaBKYXL42e6lwuLfoc6LBdlY4+Dq89uSk4vOxmGOy+/aXTVS1yPFcrHw
	rI9Ag2dNwWopGX0QZS1I439tZZ3GUu2iETUoSuyNcrsMdT6D/cEclvES72bGnib90acS
	4PCw==
MIME-Version: 1.0
X-Received: by 10.107.46.137 with SMTP id u9mr42611970iou.136.1450298310374;
	Wed, 16 Dec 2015 12:38:30 -0800 (PST)
Received: by 10.79.8.198 with HTTP; Wed, 16 Dec 2015 12:38:30 -0800 (PST)
Date: Wed, 16 Dec 2015 15:38:30 -0500
Message-ID: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113abfae9bbd88052709e34d
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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
Subject: [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 20:38:32 -0000

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

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 limited 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 blocks 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 Change 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 the 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 proceed 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.

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

<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 limited by MAX_BLOCK_SIZE.=C2=A0 Witness data (or extension bl=
ock data) is excluded.=C2=A0 Requires a hard fork to change.</div><div><br>=
</div></blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;paddi=
ng:0px"><div>Core block - Current bitcoin block, with upper bound MAX_BLOCK=
_SIZE.=C2=A0 Not changed by SW.</div></blockquote><blockquote style=3D"marg=
in:0 0 0 40px;border:none;padding:0px"><div><br></div></blockquote><blockqu=
ote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>Extended trans=
action - Newer, upgraded version of transaction data format.</div><div><br>=
</div></blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;paddi=
ng:0px"><div>Extended block - Newer, upgraded version of block data format.=
</div></blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;paddi=
ng:0px"><div><br></div><div>EBS - Extended block size.=C2=A0 Block size see=
n by newer clients.</div></blockquote><div><br></div><div>3. Context of ana=
lysis</div><div><br></div><blockquote style=3D"margin:0 0 0 40px;border:non=
e;padding:0px"><div>One proposal presents SW <i>in lieu of</i>=C2=A0a hard =
fork block size increase.=C2=A0 This email focuses directly on that.</div><=
div><br></div></blockquote><blockquote style=3D"margin:0 0 0 40px;border:no=
ne;padding:0px"><div>Useful features outside block size context, such as an=
ti-malleability or fraud proof features, are not covered in depth.</div></b=
lockquote><div><br></div><div>4.1.=C2=A0 Observations on data structure for=
mats and views</div><div><br></div><blockquote style=3D"margin:0 0 0 40px;b=
order:none;padding:0px">SW creates two <i>views</i>=C2=A0of each transactio=
n and block.=C2=A0 SW has blocks and extended blocks.=C2=A0 Similarly, ther=
e exists transactions and extended transactions.<br><br>This view is render=
ed to clients depending on compatibility level.=C2=A0 Newer clients see ext=
ended blocks and extended transactions.=C2=A0 Older clients see blocks (lim=
it 1M), and do not see extended blocks.=C2=A0 Older clients see upgraded tr=
ansactions as unsigned, anyone-can-pay transactions.<br><br>Each extended t=
ransaction 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 Observations on behavior of older transaction creation<di=
v><br></div><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"=
><div>Transactions created by older clients will not use the extended trans=
action format.=C2=A0 All data is stored the standard 1M block as today.</di=
v></blockquote><div><br></div><div>4.3.=C2=A0 Observations on new block eco=
nomic model</div><div><br></div><blockquote style=3D"margin:0 0 0 40px;bord=
er:none;padding:0px"><div>SW complicates block economics by creating two se=
parate, supply limited resources.</div><div><br></div></blockquote><blockqu=
ote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>The core block=
 economic resource is heavily contended.=C2=A0 Older clients use core block=
s exclusively.=C2=A0 Newer clients use core blocks more conservatively, sto=
ring as much data as possible in extended blocks.</div><div><br></div></blo=
ckquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><di=
v>The extended block economic resource is less heavily contended, though th=
at of course grows over time as clients upgrade.</div><div><br></div></bloc=
kquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px">Beca=
use core blocks are more heavily contended, it is presumed that older clien=
ts will pay a higher fee than newer clients (subject to elasticity etc.).<b=
r></blockquote><div><br></div>5.1.=C2=A0 Problem: =C2=A0Pace of roll-out wi=
ll 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 appare=
nt proposal is to roll out Segregated Witness as a soft fork, and keep bloc=
k size at 1M.</div><div><br></div></blockquote><blockquote style=3D"margin:=
0 0 0 40px;border:none;padding:0px"><div>The roll-out pace cannot simply be=
 judged by soft fork speed - which is months at best.=C2=A0 Analysis must t=
he layers 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 update those apps to create extended transactions.</div><div><br></div>=
</blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px=
"><div>Overall, wallet software and programmer libraries must be upgraded t=
o make use 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 conte=
nd entirely 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 software, unlike SW.</div><div><br></div><blockquote style=3D"margin:0=
 0 0 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 so=
ftware.</div><div><br></div></blockquote><blockquote style=3D"margin:0 0 0 =
40px;border:none;padding:0px"><div>SW requires merchants to upgrade almost =
immediately, 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=
 processors 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 kn=
own, versus SW.</div></blockquote><div><br></div>5.3.=C2=A0 Problem: =C2=A0=
 Due to pace, Fee Event not forestalled.<div><br></div><blockquote style=3D=
"margin:0 0 0 40px;border:none;padding:0px">Even presuming SW is merged int=
o 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.=C2=A0 Problem: =C2=A0 More complex economic policy, new gam=
e theory, new bidding structure risks.</div><div><br></div></div><blockquot=
e style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><div>Splitting b=
locks into two pieces, each with separate and distinct behaviors and resour=
ce values, creates <i>two fee markets.</i></div></div><div><i><br></i></div=
></blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;padding:0p=
x"><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=3D"margin:0 0 0 40p=
x;border:none;padding:0px"><div>Valuable or not - e.g. incentivizing older =
clients to upgrade - the fact remains that SW creates a more-complex biddin=
g structure 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=A0wi=
th standard risks associated with that.=C2=A0 Will that induce an Economic =
Change Event (see def last email)? =C2=A0<b>Unlikely</b>, due to slow rollo=
ut pace.</div></blockquote><br>5.5.=C2=A0 Problem: =C2=A0Current SW mining =
algorithm needs improvement<div><br></div><blockquote style=3D"margin:0 0 0=
 40px;border:none;padding:0px"><div>Current SW block template maker does a =
reasonable job, but makes some naive assumptions about the fee market acros=
s an entire extended block.=C2=A0 This is a mismatch with the economic real=
ity (just described).</div><div><br></div></blockquote>5.6. =C2=A0 Problem:=
 =C2=A0New, under-analyzed attack surfaces<div><br></div><blockquote style=
=3D"margin:0 0 0 40px;border:none;padding:0px"><div>Less significant and fu=
ndamental but still worth noting.</div><div><br></div></blockquote><blockqu=
ote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>This is not a =
fundamental SW problem, but simply standard complexity risk factors: =C2=A0=
splitting the signatures away from transactions, and creating a new apparen=
tly-unsigned version of the transaction opens the possibility of some netwo=
rk attacks which cause some clients to degrade down from extended block to =
core block mode temporarily.</div><div><br></div></blockquote><blockquote s=
tyle=3D"margin:0 0 0 40px;border:none;padding:0px"><div>There is a chance o=
f 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><blockq=
uote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>It seems unli=
kely that SW provides scaling in the short term, and SW introduces new econ=
omics complexities.</div><div><br></div></blockquote><blockquote style=3D"m=
argin: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><blockquote style=3D"margin:=
0 0 0 40px;border:none;padding:0px"><div>Bump + SW should proceed in parall=
el, independent tracks, as orthogonal issues.</div></blockquote><div><br></=
div>7. Appendix - Other SW comments<div><br></div><blockquote style=3D"marg=
in:0 0 0 40px;border:none;padding:0px">Hard forks provide much stronger val=
idation, 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 clients.<=
br><br></blockquote><blockquote style=3D"margin:0 0 0 40px;border:none;padd=
ing:0px">An SW hard fork could also add several zero-filled placeholders in=
 a merkle tree for future use.</blockquote><br><blockquote style=3D"margin:=
0 0 0 40px;border:none;padding:0px"></blockquote><br><blockquote style=3D"m=
argin:0 0 0 40px;border:none;padding:0px"><br></blockquote><div><div><div><=
blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><br></d=
iv><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><b=
lockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><br></di=
v></blockquote><div><blockquote style=3D"margin:0 0 0 40px;border:none;padd=
ing:0px"><div><br></div></blockquote><blockquote style=3D"margin:0 0 0 40px=
;border:none;padding:0px"><div><br></div><div><br></div></blockquote><div><=
div><br></div></div></div></div></div></div></div></div></div>

--001a113abfae9bbd88052709e34d--