I think people have a variety of sequences in mind, eg some would prefer to deploy versionBits first, so that subsequent features can be deployed in parallel (currently soft-fork deployment is necessarily serialised).
Others think do seg-witness first because scale is more important. Some want to do seg-witness as a hard-fork (personally I think that would take a bit longer to deploy & activate - the advantage of soft-fork is that it's lower risk and we have more experience of it). I've seen a few people want to do BIP 102 first (straight move to 2MB and only that) and then do seg-witness and other scaling work later. That's possible also and before Luke observed that you could do a seg-witness based block-size increase via soft-fork, people had been working following the summary from the montreal workshop discussion posted on this list about a loose plan of action, people had been working on something like BIP 102 to 2-4-8 kind of space, plus validation cost accounting. So I think personally soft-fork seg-witness first, but hey I'm not writing code at present and I'm very happy for wiser and more code and deployment detail aware minds to figure out the best deployment strategy, I wouldnt mind any of the above, just think seg-witness soft-fork is the safest and fastest. The complexity risk - well on the plus side it is implemented and it reduces deployment risk, and it's anyway needed work to have a robust malleability fix which is needed for a whole range of bitcoin smart-contract, and scaling features, including for example greenAddress like faster transactions as used by BitPay?, BitGo and GreenAddress as well as lightning related proposals and basically any smart-contract use that involves multiple clauses and dependent transactions. Also re complexity risk Greg has highlighted that the complexity and overhead difference is really minor. About knock on code changes needed, a bunch of the next steps for Bitcoin are going to need code changes, I think our scope to improve and scale Bitcoin are going to be severely hampered if we restricted ourselves with the pre-condition that we cant make protocol improvements. I think people in core would be happy to, and have done this kind of thing multiple times in the past, to help people for free on volunteer time integrate and fix up related code in various languages and FOSS and commercial software that is affected. As to time-line Luke I saw guestimated by march 2016 on reddit. Others maybe be more or less conservative. Probably a BIP and testing are the main thing, and that can be helped by more eyes. The one advantage of BIP 102 like proposal is simplicity if one had to do a more emergency hard-fork. Maybe companies and power users, miners and pool operators could help define some requirements and metrics about an industry wide service level they are receiving relative to fees. The other thing which is not protocol related, is that companies can help themselves and help Bitcoin developers help them, by working to improve decentralisation with better configurations, more use of self-hosted and secured full nodes, and decentralisation of policy control over hashrate. That might even include buying a nominal (to a reasonably funded startup) amount of mining equipment. Or for power users to do more of that. Some developers are doing mining. Blockstream and some employees have a little bit of hashrate. If we could define some metrics and best practices and measure the improvements, that would maybe reduce miners concerns about centralisation risk and allow a bigger block faster, alongside the IBLT & weak block network protocol improvements. Adam On 14 December 2015 at 19:44, Jonathan Toomim via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > 1. I think we should limit the sum of the block and witness data to > nBlockMaxSize*7/4 per block, for a maximum of 1.75 MB total. I don't like the > idea that SegWit would give us 1.75 MB of capacity in the typical case, but > we have to have hardware capable of 4 MB in adversarial conditions (i.e. > intentional multisig). I think a limit to the segwit size allays that concern. > > 2. I think that segwit is a substantial change to how Bitcoin works, and I > very strongly believe that we should not rush this. It changes the block > structure, it changes the transaction structure, it changes the network > protocol, it changes SPV wallet software, it changes block explorers, and it > has changes that affect most other parts of the Bitcoin ecosystem. After we > decide to implement it, and have a final version of the code that will be > merged, we should give developers of other Bitcoin software time to implement > code that supports the new transaction/witness formats. > > When you guys say "as soon as possible," what do you mean exactly? > > On Dec 10, 2015, at 2:47 PM, jl2012--- via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > >> It seems the current consensus is to implement Segregated Witness. SW opens >> many new possibilities but we need a balance between new features and >> deployment time frame. I'm listing by my priority: >> >> 1-2 are about scalability and have highest priority >> >> 1. Witness size limit: with SW we should allow a bigger overall block size. >> It seems 2MB is considered to be safe for many people. However, the exact >> size and growth of block size should be determined based on testing and >> reasonable projection. >> >> 2. Deployment time frame: I prefer as soon as possible, even if none of the >> following new features are implemented. This is not only a technical issue >> but also a response to the community which has been waiting for a scaling >> solution for years _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
