{"type":"rich","version":"1.0","author_name":"npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","author_url":"https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-16\n📝 Original message:1. Summary\n\nSegregated Witness (SegWitness, SW) is being presented in the context of\nScaling Bitcoin.  It has useful attributes, notably addressing a major\nmalleability vector, but is not a short term scaling solution.\n\n\n2. Definitions\n\nImport Fee Event, ECE, TFM, FFM from previous email.\n\nOlder clients - Any software not upgraded to SW\n\nNewer clients - Upgraded, SW aware software\n\n\nBlock size - refers to the core block economic resource limited by\nMAX_BLOCK_SIZE.  Witness data (or extension block data) is excluded.\nRequires a hard fork to change.\n\nCore block - Current bitcoin block, with upper bound MAX_BLOCK_SIZE.  Not\nchanged by SW.\n\n\nExtended transaction - Newer, upgraded version of transaction data format.\n\nExtended block - Newer, upgraded version of block data format.\n\n\nEBS - Extended block size.  Block size seen by newer clients.\n\n\n3. Context of analysis\n\nOne proposal presents SW *in lieu of* a hard fork block size increase.\nThis email focuses directly on that.\n\nUseful features outside block size context, such as anti-malleability or\nfraud proof features, are not covered in depth.\n\n\n4.1.  Observations on data structure formats and views\n\nSW creates two *views* of each transaction and block.  SW has blocks and\nextended blocks.  Similarly, there exists transactions and extended\ntransactions.\n\nThis view is rendered to clients depending on compatibility level.  Newer\nclients see extended blocks and extended transactions.  Older clients see\nblocks (limit 1M), and do not see extended blocks.  Older clients see\nupgraded transactions as unsigned, anyone-can-pay transactions.\n\nEach extended transaction exists in two states, one unsigned and one\nsigned, each of which passes validation as a valid bitcoin transaction.\n\n\n4.2.  Observations on behavior of older transaction creation\n\nTransactions created by older clients will not use the extended transaction\nformat.  All data is stored the standard 1M block as today.\n\n\n4.3.  Observations on new block economic model\n\nSW complicates block economics by creating two separate, supply limited\nresources.\n\nThe core block economic resource is heavily contended.  Older clients use\ncore blocks exclusively.  Newer clients use core blocks more\nconservatively, storing as much data as possible in extended blocks.\n\nThe extended block economic resource is less heavily contended, though that\nof course grows over time as clients upgrade.\n\nBecause core blocks are more heavily contended, it is presumed that older\nclients will pay a higher fee than newer clients (subject to elasticity\netc.).\n\n\n5.1.  Problem:  Pace of roll-out will be slow - Whole Ecosystem must be\nconsidered.\n\nThe current apparent proposal is to roll out Segregated Witness as a soft\nfork, and keep block size at 1M.\n\nThe roll-out pace cannot simply be judged by soft fork speed - which is\nmonths at best.  Analysis must the layers above:  Updating bitcoin-core\n(JS) and bitcoinj (Java), and then the timelines to roll out those updates\nto apps, and then the timeline to update those apps to create extended\ntransactions.\n\nOverall, wallet software and programmer libraries must be upgraded to make\nuse of this new format, adding many more months (12+ in some stacks) to the\nroll out timeline.  In the meantime, clients continue to contend entirely\nfor core block space.\n\n\n5.2.  Problem:   Hard fork to bigger block size Just Works(tm) with most\nsoftware, unlike SW.\n\nA simple hard fork such as BIP 102 is automatically compatible with the\nvast range of today's ecosystem software.\n\nSW requires merchants to upgrade almost immediately, requires wallet and\nother peripheral software upgrades to make use of.  Other updates are\nopt-in and occur more slowly.  BIP 70 processors need some updates.\n\nThe number of LOC that must change for BIP 102 is very small, and the\nproblem domain well known, versus SW.\n\n\n5.3.  Problem:   Due to pace, Fee Event not forestalled.\n\nEven presuming SW is merged into Bitcoin Core tomorrow, this does not\naddress the risk of a Fee Event and associated Economic Change in the\ncoming months.\n\n\n5.4.  Problem:   More complex economic policy, new game theory, new bidding\nstructure risks.\n\nSplitting blocks into two pieces, each with separate and distinct behaviors\nand resource values, creates *two fee markets.*\n\nHaving two pricing strata within each block has certainly feasible - that\nis the current mining policy of (1) fee/KB followed by (2) priority/age.\n\nValuable or not - e.g. incentivizing older clients to upgrade - the fact\nremains that SW creates a more-complex bidding structure by creating a\nsecond economic resource.\n\n*This is clearly a change to a new economic policy* with standard risks\nassociated with that.  Will that induce an Economic Change Event (see def\nlast email)?  *Unlikely*, due to slow rollout pace.\n\n\n5.5.  Problem:  Current SW mining algorithm needs improvement\n\nCurrent SW block template maker does a reasonable job, but makes some naive\nassumptions about the fee market across an entire extended block.  This is\na mismatch with the economic reality (just described).\n\n5.6.   Problem:  New, under-analyzed attack surfaces\n\nLess significant and fundamental but still worth noting.\n\nThis is not a fundamental SW problem, but simply standard complexity risk\nfactors:  splitting the signatures away from transactions, and creating a\nnew apparently-unsigned version of the transaction opens the possibility of\nsome network attacks which cause some clients to degrade down from extended\nblock to core block mode temporarily.\n\nThere is a chance of a failure mode that fools older clients into thinking\nfraudulent data is valid (judgement: unlikely vis hashpower but not\nimpossible)\n\n6. Conclusions and recommendations\n\nIt seems unlikely that SW provides scaling in the short term, and SW\nintroduces new economics complexities.\n\nA \"short term bump\" hard fork block size increase addresses economic and\necosystem risks that SW does not.\n\nBump + SW should proceed in parallel, independent tracks, as orthogonal\nissues.\n\n\n7. Appendix - Other SW comments\n\nHard forks provide much stronger validation, and ensure the network\noperates at a fully trustless level.\n\nSW hard fork is preferred, versus soft fork.  Soft forking SW places a huge\namount of trust on miners to validate transaction signatures, versus the\nrest of the network, as the network slowly upgrades to newer clients.\n\nAn SW hard fork could also add several zero-filled placeholders in a merkle\ntree for future use.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/1c334c8f/attachment-0001.html\u003e"}