Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ECB46F24 for ; 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 ; Thu, 17 Dec 2015 06:14:14 +0000 (UTC) Received: by mail-yk0-f169.google.com with SMTP id p130so7729468yka.1 for ; 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: <49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com> Date: Thu, 17 Dec 2015 07:14:13 +0100 Message-ID: From: Marcel Jamin To: Matt Corallo 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 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: 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
Maybe we should first gather concrete estimates about and = roughly agree on

- how long SW (SF) development will pro= bably take

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

Opinions differ wildly from what it looks like, but m= aybe we can get to estimates that the majority here can accept.
<= br>
---

Personally, I think that the dis= claimer "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 ris= k of losing money by getting scammed, then that's a little bit your fau= lt. I'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.

A planned hard-fork is an experimen= t 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 <bitc= oin-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 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'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.

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.

On De= cember 16, 2015 12:38:30 PM PST, Jeff Garzik via bitcoin-dev <bitcoin-de= v@lists.linuxfoundation.org> wrote:

1. Summary

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.

2. Definitions

Import Fee Event, ECE, TFM, FFM from previou= s email.

Older clients - Any software not upgrad= ed to SW

Newer clients - Upgraded, SW aware soft= ware

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.

Core bloc= k - Current bitcoin block, with upper bound MAX_BLOCK_SIZE.=C2=A0 Not chang= ed by SW.

Extended transaction - Newer, upgrad= ed version of transaction data format.

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

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

3. Context of analysis

On= e proposal presents SW in lieu of=C2=A0a hard fork block size increa= se.=C2=A0 This email focuses directly on that.

U= seful features outside block size context, such as anti-malleability or fra= ud proof features, are not covered in depth.

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

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.

=
4.3.=C2=A0 Observations on new block economic model
SW complicates block economics by creating two separate, supply limited r= esources.

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>
The extended block economic resource is less heavily c= ontended, though that of course grows over time as clients upgrade.

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

5.1.=C2=A0 Problem: =C2=A0= 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 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.

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.

5.2.=C2=A0 = Problem: =C2=A0 Hard fork to bigger block size Just Works(tm) with most sof= tware, unlike SW.

A simple hard fork such as BIP 102 is autom= atically compatible with the vast range of today's ecosystem software.<= /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.

The number of LOC that = must change for BIP 102 is very small, and the problem domain well known, v= ersus SW.

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

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.

=
5.4.=C2=A0 Problem: =C2=A0 More complex economic policy, new game theo= ry, new bidding structure risks.

Splitting blocks = into two pieces, each with separate and distinct behaviors and resource val= ues, 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 client= s to upgrade - the fact remains that SW creates a more-complex bidding stru= cture by creating a second economic resource.

=
This is clearly a change to a new economic policy=C2=A0with sta= ndard risks associated 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 algorit= hm needs improvement

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

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

Less significant and fundamenta= l but still worth noting.

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.

<= /blockquote>
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)

6. Conclusions and recommendati= ons

It seems unlikely that SW provides scaling in the short term, a= nd SW introduces new economics complexities.

A &= quot;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 stro= nger 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 slowly upgrades to newer c= lients.

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







=




bitcoin-dev@lists.linuxfound= ation.org
https://lists.linuxfoundation.org/mailma= n/listinfo/bitcoin-dev


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


--001a1147e4468655cf052711ee26--