{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-16\n📝 Original message: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.\n\nOn 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.\n\nOn December 16, 2015 12:38:30 PM PST, Jeff Garzik via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e1. Summary\n\u003e\n\u003eSegregated Witness (SegWitness, SW) is being presented in the context\n\u003eof\n\u003eScaling Bitcoin.  It has useful attributes, notably addressing a major\n\u003emalleability vector, but is not a short term scaling solution.\n\u003e\n\u003e\n\u003e2. Definitions\n\u003e\n\u003eImport Fee Event, ECE, TFM, FFM from previous email.\n\u003e\n\u003eOlder clients - Any software not upgraded to SW\n\u003e\n\u003eNewer clients - Upgraded, SW aware software\n\u003e\n\u003e\n\u003eBlock size - refers to the core block economic resource limited by\n\u003eMAX_BLOCK_SIZE.  Witness data (or extension block data) is excluded.\n\u003eRequires a hard fork to change.\n\u003e\n\u003eCore block - Current bitcoin block, with upper bound MAX_BLOCK_SIZE. \n\u003eNot\n\u003echanged by SW.\n\u003e\n\u003e\n\u003eExtended transaction - Newer, upgraded version of transaction data\n\u003eformat.\n\u003e\n\u003eExtended block - Newer, upgraded version of block data format.\n\u003e\n\u003e\n\u003eEBS - Extended block size.  Block size seen by newer clients.\n\u003e\n\u003e\n\u003e3. Context of analysis\n\u003e\n\u003eOne proposal presents SW *in lieu of* a hard fork block size increase.\n\u003eThis email focuses directly on that.\n\u003e\n\u003eUseful features outside block size context, such as anti-malleability\n\u003eor\n\u003efraud proof features, are not covered in depth.\n\u003e\n\u003e\n\u003e4.1.  Observations on data structure formats and views\n\u003e\n\u003eSW creates two *views* of each transaction and block.  SW has blocks\n\u003eand\n\u003eextended blocks.  Similarly, there exists transactions and extended\n\u003etransactions.\n\u003e\n\u003eThis view is rendered to clients depending on compatibility level. \n\u003eNewer\n\u003eclients see extended blocks and extended transactions.  Older clients\n\u003esee\n\u003eblocks (limit 1M), and do not see extended blocks.  Older clients see\n\u003eupgraded transactions as unsigned, anyone-can-pay transactions.\n\u003e\n\u003eEach extended transaction exists in two states, one unsigned and one\n\u003esigned, each of which passes validation as a valid bitcoin transaction.\n\u003e\n\u003e\n\u003e4.2.  Observations on behavior of older transaction creation\n\u003e\n\u003eTransactions created by older clients will not use the extended\n\u003etransaction\n\u003eformat.  All data is stored the standard 1M block as today.\n\u003e\n\u003e\n\u003e4.3.  Observations on new block economic model\n\u003e\n\u003eSW complicates block economics by creating two separate, supply limited\n\u003eresources.\n\u003e\n\u003eThe core block economic resource is heavily contended.  Older clients\n\u003euse\n\u003ecore blocks exclusively.  Newer clients use core blocks more\n\u003econservatively, storing as much data as possible in extended blocks.\n\u003e\n\u003eThe extended block economic resource is less heavily contended, though\n\u003ethat\n\u003eof course grows over time as clients upgrade.\n\u003e\n\u003eBecause core blocks are more heavily contended, it is presumed that\n\u003eolder\n\u003eclients will pay a higher fee than newer clients (subject to elasticity\n\u003eetc.).\n\u003e\n\u003e\n\u003e5.1.  Problem:  Pace of roll-out will be slow - Whole Ecosystem must be\n\u003econsidered.\n\u003e\n\u003eThe current apparent proposal is to roll out Segregated Witness as a\n\u003esoft\n\u003efork, and keep block size at 1M.\n\u003e\n\u003eThe roll-out pace cannot simply be judged by soft fork speed - which is\n\u003emonths at best.  Analysis must the layers above:  Updating bitcoin-core\n\u003e(JS) and bitcoinj (Java), and then the timelines to roll out those\n\u003eupdates\n\u003eto apps, and then the timeline to update those apps to create extended\n\u003etransactions.\n\u003e\n\u003eOverall, wallet software and programmer libraries must be upgraded to\n\u003emake\n\u003euse of this new format, adding many more months (12+ in some stacks) to\n\u003ethe\n\u003eroll out timeline.  In the meantime, clients continue to contend\n\u003eentirely\n\u003efor core block space.\n\u003e\n\u003e\n\u003e5.2.  Problem:   Hard fork to bigger block size Just Works(tm) with\n\u003emost\n\u003esoftware, unlike SW.\n\u003e\n\u003eA simple hard fork such as BIP 102 is automatically compatible with the\n\u003evast range of today's ecosystem software.\n\u003e\n\u003eSW requires merchants to upgrade almost immediately, requires wallet\n\u003eand\n\u003eother peripheral software upgrades to make use of.  Other updates are\n\u003eopt-in and occur more slowly.  BIP 70 processors need some updates.\n\u003e\n\u003eThe number of LOC that must change for BIP 102 is very small, and the\n\u003eproblem domain well known, versus SW.\n\u003e\n\u003e\n\u003e5.3.  Problem:   Due to pace, Fee Event not forestalled.\n\u003e\n\u003eEven presuming SW is merged into Bitcoin Core tomorrow, this does not\n\u003eaddress the risk of a Fee Event and associated Economic Change in the\n\u003ecoming months.\n\u003e\n\u003e\n\u003e5.4.  Problem:   More complex economic policy, new game theory, new\n\u003ebidding\n\u003estructure risks.\n\u003e\n\u003eSplitting blocks into two pieces, each with separate and distinct\n\u003ebehaviors\n\u003eand resource values, creates *two fee markets.*\n\u003e\n\u003eHaving two pricing strata within each block has certainly feasible -\n\u003ethat\n\u003eis the current mining policy of (1) fee/KB followed by (2)\n\u003epriority/age.\n\u003e\n\u003eValuable or not - e.g. incentivizing older clients to upgrade - the\n\u003efact\n\u003eremains that SW creates a more-complex bidding structure by creating a\n\u003esecond economic resource.\n\u003e\n\u003e*This is clearly a change to a new economic policy* with standard risks\n\u003eassociated with that.  Will that induce an Economic Change Event (see\n\u003edef\n\u003elast email)?  *Unlikely*, due to slow rollout pace.\n\u003e\n\u003e\n\u003e5.5.  Problem:  Current SW mining algorithm needs improvement\n\u003e\n\u003eCurrent SW block template maker does a reasonable job, but makes some\n\u003enaive\n\u003eassumptions about the fee market across an entire extended block.  This\n\u003eis\n\u003ea mismatch with the economic reality (just described).\n\u003e\n\u003e5.6.   Problem:  New, under-analyzed attack surfaces\n\u003e\n\u003eLess significant and fundamental but still worth noting.\n\u003e\n\u003eThis is not a fundamental SW problem, but simply standard complexity\n\u003erisk\n\u003efactors:  splitting the signatures away from transactions, and creating\n\u003ea\n\u003enew apparently-unsigned version of the transaction opens the\n\u003epossibility of\n\u003esome network attacks which cause some clients to degrade down from\n\u003eextended\n\u003eblock to core block mode temporarily.\n\u003e\n\u003eThere is a chance of a failure mode that fools older clients into\n\u003ethinking\n\u003efraudulent data is valid (judgement: unlikely vis hashpower but not\n\u003eimpossible)\n\u003e\n\u003e6. Conclusions and recommendations\n\u003e\n\u003eIt seems unlikely that SW provides scaling in the short term, and SW\n\u003eintroduces new economics complexities.\n\u003e\n\u003eA \"short term bump\" hard fork block size increase addresses economic\n\u003eand\n\u003eecosystem risks that SW does not.\n\u003e\n\u003eBump + SW should proceed in parallel, independent tracks, as orthogonal\n\u003eissues.\n\u003e\n\u003e\n\u003e7. Appendix - Other SW comments\n\u003e\n\u003eHard forks provide much stronger validation, and ensure the network\n\u003eoperates at a fully trustless level.\n\u003e\n\u003eSW hard fork is preferred, versus soft fork.  Soft forking SW places a\n\u003ehuge\n\u003eamount of trust on miners to validate transaction signatures, versus\n\u003ethe\n\u003erest of the network, as the network slowly upgrades to newer clients.\n\u003e\n\u003eAn SW hard fork could also add several zero-filled placeholders in a\n\u003emerkle\n\u003etree for future use.\n\u003e\n\u003e\n\u003e------------------------------------------------------------------------\n\u003e\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/4c7fc0c2/attachment.html\u003e"}