From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A332AD21 for ; Wed, 16 Dec 2015 21:51:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com [209.85.215.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD442ED for ; Wed, 16 Dec 2015 21:51:49 +0000 (UTC) Received: by mail-lf0-f51.google.com with SMTP id y184so39141994lfc.1 for ; Wed, 16 Dec 2015 13:51:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=So2nntFyg0IywDjA6P3/8Lnb/B05/iOD5xlGy4zd19Y=; b=Xe8xKvgD1CkHUc+4MsXLwXFSFOHchRqLX3W8EPuFK/MAzWmaZWtK4Q/4qiXupAAiqJ sRlV4224xD3NO+QFkKEuzU7YM/XqH3Y0bRHzWH2v4Fh1kUhSAPAgFoAXbY97J0Jjo4S9 BO8vVnJ4UsUWvcd46ccsT+GfhxwGJZZEaw4ZYSjdXEVl3tK5tl/Y2jbWWeMtNwBbbkCK FpDH8tx3YjCu2Fm/bND3JtMESxmgZEtGOR08y6SMBYmAGwF2ZTdwbANp1zlu5YfqF5Uw 9EpBvFJT0PB3noDYMTQZ2UX1EU3IJea+mUtohC0yvqxHELzN64QhuD0DdPJT3YixPaDP W6/w== MIME-Version: 1.0 X-Received: by 10.25.16.30 with SMTP id f30mr7400696lfi.21.1450302707975; Wed, 16 Dec 2015 13:51:47 -0800 (PST) Received: by 10.25.21.228 with HTTP; Wed, 16 Dec 2015 13:51:47 -0800 (PST) In-Reply-To: <49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com> References: <49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com> Date: Wed, 16 Dec 2015 13:51:47 -0800 Message-ID: From: Jameson Lopp To: Matt Corallo Content-Type: multipart/alternative; boundary=001a11403d14b9d37c05270ae933 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 X-Mailman-Approved-At: Thu, 17 Dec 2015 12:34:21 +0000 Cc: Bitcoin development mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 21:51:51 -0000 --001a11403d14b9d37c05270ae933 Content-Type: text/plain; charset=UTF-8 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 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 > > --001a11403d14b9d37c05270ae933 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 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 lo= nger 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 g= et 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 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= 9;d still kill a bunch of nodes and instead of reducing their security mode= l, lead them to be outright robbed.


Over a year seems to be an extraordinarily long tim= e frame is for deploying a hard fork. It looks like 75% of reachable nodes have upgraded = in the past 6 months while as much as 25% may not have been upgraded in ove= r a year. However, viewing historical stats of version upgrades doesn't= seem to be an appropriate comparison because node operators have never bee= n faced with the same incentive to upgrade. We can point to unintentional f= orks 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 de= al 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 a= nd decide when it is appropriate to update their software. I'm not so s= ure that it's the rest of the ecosystem's responsibility to wait ar= ound for laggards.

- Jameson

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
On Decembe= r 16, 2015 12:38:30 PM PST, Jeff Garzik via bitcoin-dev <bitcoin-dev@lis= ts.linuxfoundation.org> wrote:

1. Summary

<= blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">
S= egregated Witness (SegWitness, SW) is being presented in the context of Sca= ling Bitcoin.=C2=A0 It has useful attributes, notably addressing a major ma= lleability 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

<= /div>
Block size - refers to the core block economic 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.

Core block - Current bitcoin block, with upper bound MAX_BLOC= K_SIZE.=C2=A0 Not changed by SW.

<= blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">
E= xtended transaction - Newer, upgraded version of transaction data format.

Extended block - Newer, upgraded version of= block data format.

EBS - Extended block s= ize.=C2=A0 Block size seen by newer clients.

3. Context of analysis

One proposal presents SW= in lieu of=C2=A0a hard fork block size increase.=C2=A0 This email f= ocuses directly on that.

Useful features o= utside block size context, such as anti-malleability or fraud proof feature= s, are not covered in depth.

4.1.=C2= =A0 Observations on data structure formats and views

SW crea= tes two views=C2=A0of each transaction and block.=C2=A0 SW has block= s and extended blocks.=C2=A0 Similarly, there exists transactions and exten= ded transactions.

This view is rendered to clients depending on comp= atibility level.=C2=A0 Newer clients see extended blocks and extended trans= actions.=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.

Each extended transaction exists in two= states, one unsigned and one signed, each of which passes validation as a = valid bitcoin transaction.

4.2.=C2=A0 Observ= ations on behavior of older transaction creation

Transactions= created by older clients will not use the extended transaction format.=C2= =A0 All data is stored the standard 1M block as today.

4.3.=C2=A0 Observations on new block economic model
=

SW complicates block economics by creating two separate, sup= ply limited resources.

The core blo= ck economic resource is heavily contended.=C2=A0 Older clients use core blo= cks exclusively.=C2=A0 Newer clients use core block s more conservatively, storing as much data as possible in extended blocks.
<= div>
The extended block economic res= ource is less heavily contended, though that of course grows over time as c= lients upgrade.

Because core blocks are more he= avily contended, it is presumed that older clients will pay a higher fee th= an newer clients (subject to elasticity etc.).

5.1.=C2=A0 Problem: =C2=A0Pace of roll-out will be slow - Whole Ecosyste= m must be considered.

The current apparent proposal is to rol= l 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.=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.

=
Overall, wallet software and programmer libraries must be upgraded to = make use of this new format, adding many more months (12+ in some stacks) t= o the roll out timeline.=C2=A0 In the meantime, clients continue to contend= entirely for core block space.

5.2.= =C2=A0 Problem: =C2=A0 Hard fork to bigger block size Just Works(tm) with m= ost software, unlike SW.

A simple hard fork such as BIP= 102 is automatically compatible with the vast range of today's ecosyst= em software.

SW requires merchants to upgr= ade almost immediately, requires wallet and other peripheral software upgra= des to make use of.=C2=A0 Other updates are opt-in and occur more slowly.= =C2=A0 BIP 70 processors need some updates.

The number of LOC that must change for BIP 102 is very small, and the pro= blem domain well known, versus SW.

5.3.=C2= =A0 Problem: =C2=A0 Due to pace, Fee Event not forestalled.

<= blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">Even p= resuming 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.=C2=A0 Problem: =C2=A0 More complex= economic policy, new game theory, new bidding structure risks.
<= br>
Splitting blocks into two pieces, each with separate an= d distinct behaviors and resource values, creates two fee markets.

Having two pricing strata with= in 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 re= mains that SW creates a more-complex bidding structure by creating a second= economic resource.

This = is clearly a change to a new economic policy=C2=A0with standard risks a= ssociated with that.=C2=A0 Will that induce an Economic C hange Event (see def last email)? =C2=A0Unlikely, due to slow rollout pace= .

5.5.=C2=A0 Problem: =C2=A0Current = SW mining algorithm needs improvement

Current SW block templa= te maker does a reasonable job, but makes some naive assumptions about the = fee market across an entire extended block.=C2=A0 This is a mismatch with t= he economic reality (just described).

5.6.= =C2=A0 Problem: =C2=A0New, under-analyzed attack surfaces

Le= ss significant and fundamental but still worth noting.

=
This is not a fundamental SW problem, but simply standa= rd complexity risk factors: =C2=A0splitting the signatures away from transa= ctions, and creating a new apparently-unsigned version of the transaction o= pens t he possibility of some network attacks which cause some clients to degrade dow= n from extended block to core block mode temporarily.

<= /blockquote>
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. Concl= usions 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 blo= ck 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 fo= rks provide much stronger validation, and ensure the network operates at a = fully trustless level.

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 slow= ly upgrades to newer clients.

An SW hard fork could also add= several zero-filled placeholders in a merkle tree for future use.












bitc=
oin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a>

_________________________________= ______________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a11403d14b9d37c05270ae933--