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