{"type":"rich","version":"1.0","author_name":"Jameson Lopp [ARCHIVE] (npub1gh…akqmn)","author_url":"https://nostr.ae/npub1ghgfr3aumwuxwnwghywxpaejxpf6k9pjcnyg9lfdnztlu5pwa0ksyakqmn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-12-16\n📝 Original message:On Wed, Dec 16, 2015 at 12:50 PM, Matt Corallo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e A large part of your argument is that SW will take longer to deploy than a\n\u003e hard fork, but I completely disagree. Though I do not agree with some\n\u003e people claiming we can deploy SW significantly faster than a hard fork,\n\u003e once the code is ready (probably a six month affair) we can get it deployed\n\u003e very quickly. It's true the ecosystem may take some time to upgrade, but I\n\u003e see that as a feature, not a bug - we can build up some fee pressure with\n\u003e an immediate release valve available for people to use if they want to pay\n\u003e fewer fees.\n\u003e\n\u003e On the other hand, a hard fork, while simpler for the ecosystem to upgrade\n\u003e to, is a 1-2 year affair (after the code is shipped, so at least 1.5-2.5\n\u003e from today if we all put off heads down and work). One thing that has\n\u003e concerned me greatly through this whole debate is how quickly people seem\n\u003e to think we can roll out a hard fork. Go look at the distribution of node\n\u003e versions on the network today and work backwards to get nearly every node\n\u003e upgraded... Even with a year between fork-version-release and\n\u003e fork-activation, we'd still kill a bunch of nodes and instead of reducing\n\u003e their security model, lead them to be outright robbed.\n\u003e\n\u003e\nOver a year seems to be an extraordinarily long time frame is for deploying\na hard fork. It looks like \u003chttps://bitnodes.21.co/dashboard/?days=365\u003e 75%\nof reachable nodes have upgraded in the past 6 months while as much as 25%\nmay not have been upgraded in over a year. However, viewing historical\nstats of version upgrades doesn't seem to be an appropriate comparison\nbecause node operators have never been faced with the same incentive to\nupgrade. We can point to unintentional forks in the past that have been\nresolved fairly quickly by reaching out to miners, but it's also a poor\ncomparison. Unfortunately, we have no way of knowing what percentage of\nnodes are economically important - a great deal of them may be running and\nnot even be used by the operators.\n\nPerhaps it would be better if we were to formalize the expectations for\nfull node operators, but it seems to me that node operators have a\nresponsibility to keep themselves informed and decide when it is\nappropriate to update their software. I'm not so sure that it's the rest of\nthe ecosystem's responsibility to wait around for laggards.\n\n- Jameson\n\nOn December 16, 2015 12:38:30 PM PST, Jeff Garzik via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 1. Summary\n\u003e\u003e\n\u003e\u003e Segregated Witness (SegWitness, SW) is being presented in the context of\n\u003e\u003e Scaling Bitcoin.  It has useful attributes, notably addressing a major\n\u003e\u003e malleability vector, but is not a short term scaling solution.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 2. Definitions\n\u003e\u003e\n\u003e\u003e Import Fee Event, ECE, TFM, FFM from previous email.\n\u003e\u003e\n\u003e\u003e Older clients - Any software not upgraded to SW\n\u003e\u003e\n\u003e\u003e Newer clients - Upgraded, SW aware software\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Block size - refers to the core block economic resource limit ed by\n\u003e\u003e MAX_BLOCK_SIZE.  Witness data (or extension block data) is excluded.\n\u003e\u003e Requires a hard fork to change.\n\u003e\u003e\n\u003e\u003e Core block - Current bitcoin block, with upper bound MAX_BLOCK_SIZE.  Not\n\u003e\u003e changed by SW.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Extended transaction - Newer, upgraded version of transaction data format.\n\u003e\u003e\n\u003e\u003e Extended block - Newer, upgraded version of block data format.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e EBS - Extended block size.  Block size seen by newer clients.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 3. Context of analysis\n\u003e\u003e\n\u003e\u003e One proposal presents SW *in lieu of* a hard fork block size increase.\n\u003e\u003e This email focuses directly on that.\n\u003e\u003e\n\u003e\u003e Useful features outside block size context, such as anti-malleability or\n\u003e\u003e fraud proof features, are not covered in depth.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 4.1.  Observations on data structure formats and views\n\u003e\u003e\n\u003e\u003e SW creates two *views* of each transaction and block.  SW has blocks and\n\u003e\u003e extended blocks.  Similarly, there exists transactions and extended\n\u003e\u003e transactions.\n\u003e\u003e\n\u003e\u003e This view is rendered to clients depending on compatibility level.  Newer\n\u003e\u003e clients see extended blocks and extended transactions.  Older clients see\n\u003e\u003e blocks (limit 1M), and do not see extended blocks.  Older clients see\n\u003e\u003e upgraded transactions as unsigned, anyone-can-pay transactions.\n\u003e\u003e\n\u003e\u003e Each extended transaction exists in two states, one unsigned and one\n\u003e\u003e signed, each of which passes validation as a valid bitcoin transaction.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 4.2.  Observations on behavior of older transaction creation\n\u003e\u003e\n\u003e\u003e Transactions created by older clients will not use the extended\n\u003e\u003e transaction format.  All data is stored the standard 1M block as today.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 4.3.  Observations on new block economic model\n\u003e\u003e\n\u003e\u003e SW complicates block economics by creating two separate, supply limited\n\u003e\u003e resources.\n\u003e\u003e\n\u003e\u003e The core block economic resource is heavily contended.  Older clients use\n\u003e\u003e core blocks exclusively.  Newer clients use core block s more\n\u003e\u003e conservatively, storing as much data as possible in extended blocks.\n\u003e\u003e\n\u003e\u003e The extended block economic resource is less heavily contended, though\n\u003e\u003e that of course grows over time as clients upgrade.\n\u003e\u003e\n\u003e\u003e Because core blocks are more heavily contended, it is presumed that older\n\u003e\u003e clients will pay a higher fee than newer clients (subject to elasticity\n\u003e\u003e etc.).\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 5.1.  Problem:  Pace of roll-out will be slow - Whole Ecosystem must be\n\u003e\u003e considered.\n\u003e\u003e\n\u003e\u003e The current apparent proposal is to roll out Segregated Witness as a soft\n\u003e\u003e fork, and keep block size at 1M.\n\u003e\u003e\n\u003e\u003e The roll-out pace cannot simply be judged by soft fork speed - which is\n\u003e\u003e months at best.  Analysis must the layers above:  Updating bitcoin-core\n\u003e\u003e (JS) and bitcoinj (Java), and then the timelines to roll out those updates\n\u003e\u003e to apps, and then the timeline to update those apps to create extended\n\u003e\u003e transactions.\n\u003e\u003e\n\u003e\u003e Overall, wallet software and programmer libraries must be upgraded to\n\u003e\u003e make use of this new format, adding many more months (12+ in some stacks)\n\u003e\u003e to the roll out timeline.  In the meantime, clients continue to contend\n\u003e\u003e entirely for core block space.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 5.2.  Problem:   Hard fork to bigger block size Just Works(tm) with most\n\u003e\u003e software, unlike SW.\n\u003e\u003e\n\u003e\u003e A simple hard fork such as BIP 102 is automatically compatible with the\n\u003e\u003e vast range of today's ecosystem software.\n\u003e\u003e\n\u003e\u003e SW requires merchants to upgrade almost immediately, requires wallet and\n\u003e\u003e other peripheral software upgrades to make use of.  Other updates are\n\u003e\u003e opt-in and occur more slowly.  BIP 70 processors need some updates.\n\u003e\u003e\n\u003e\u003e The number of LOC that must change for BIP 102 is very small, and the\n\u003e\u003e problem domain well known, versus SW.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 5.3.  Problem:   Due to pace, Fee Event not forestalled.\n\u003e\u003e\n\u003e\u003e Even presuming SW is merged into Bitcoin Core tomorrow, this does not\n\u003e\u003e address the risk of a Fee Event and associated Economic Change in the\n\u003e\u003e coming months.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 5.4.  Problem:   More complex economic policy, new game theory, new\n\u003e\u003e bidding structure risks.\n\u003e\u003e\n\u003e\u003e Splitting blocks into two pieces, each with separate and distinct\n\u003e\u003e behaviors and resource values, creates *two fee markets.*\n\u003e\u003e\n\u003e\u003e Having two pricing strata within each block has certainly feasible - that\n\u003e\u003e is the current mining policy of (1) fee/KB followed by (2) priority/age.\n\u003e\u003e\n\u003e\u003e Valuable or not - e.g. incentivizing older clients to upgrade - the fact\n\u003e\u003e remains that SW creates a more-complex bidding structure by creating a\n\u003e\u003e second economic resource.\n\u003e\u003e\n\u003e\u003e *This is clearly a change to a new economic policy* with standard risks\n\u003e\u003e associated with that.  Will that induce an Economic C hange Event (see def\n\u003e\u003e last email)?  *Unlikely*, due to slow rollout pace.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 5.5.  Problem:  Current SW mining algorithm needs improvement\n\u003e\u003e\n\u003e\u003e Current SW block template maker does a reasonable job, but makes some\n\u003e\u003e naive assumptions about the fee market across an entire extended block.\n\u003e\u003e This is a mismatch with the economic reality (just described).\n\u003e\u003e\n\u003e\u003e 5.6.   Problem:  New, under-analyzed attack surfaces\n\u003e\u003e\n\u003e\u003e Less significant and fundamental but still worth noting.\n\u003e\u003e\n\u003e\u003e This is not a fundamental SW problem, but simply standard complexity risk\n\u003e\u003e factors:  splitting the signatures away from transactions, and creating a\n\u003e\u003e new apparently-unsigned version of the transaction opens t he possibility\n\u003e\u003e of some network attacks which cause some clients to degrade down from\n\u003e\u003e extended block to core block mode temporarily.\n\u003e\u003e\n\u003e\u003e There is a chance of a failure mode that fools older clients into\n\u003e\u003e thinking fraudulent data is valid (judgement: unlikely vis hashpower but\n\u003e\u003e not impossible)\n\u003e\u003e\n\u003e\u003e 6. Conclusions and recommendations\n\u003e\u003e\n\u003e\u003e It seems unlikely that SW provides scaling in the short term, and SW\n\u003e\u003e introduces new economics complexities.\n\u003e\u003e\n\u003e\u003e A \"short term bump\" hard fork block size increase addresses economic and\n\u003e\u003e ecosystem risks that SW does not.\n\u003e\u003e\n\u003e\u003e Bump + SW should proce ed in parallel, independent tracks, as orthogonal\n\u003e\u003e issues.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 7. Appendix - Other SW comments\n\u003e\u003e\n\u003e\u003e Hard forks provide much stronger validation, and ensure the network\n\u003e\u003e operates at a fully trustless level.\n\u003e\u003e\n\u003e\u003e SW hard fork is preferred, versus soft fork.  Soft forking SW places a\n\u003e\u003e huge amount of trust on miners to validate transaction signatures, versus\n\u003e\u003e the rest of the network, as the network slowly upgrades to newer clients.\n\u003e\u003e\n\u003e\u003e An SW hard fork could also add several zero-filled placeholders in a\n\u003e\u003e merkle tree for future use.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------\n\u003e\u003e\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151216/3bfa78f6/attachment-0001.html\u003e"}