There are many reasons to support segwit beyond it being a soft-fork. For example:
* the limitation of non-witness data to no more than 1MB makes the quadratic scaling costs in large transaction validation no worse than they currently are; * redeem scripts in witness use a more accurate cost accounting than non-witness data (further improvements to this beyond what Pieter has implemented are possible); and * segwit provides features (e.g. opt-in malleability protection) which are required by higher-level scaling solutions. With that in mind I really don't understand the viewpoint that it would be better to engage a strictly inferior proposal such as a simple adjustment of the block size to 2MB. On Thu, Dec 17, 2015 at 1:32 PM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > There are at least 2 proposals on the table: > > 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately > equals to 2MB actual limit > > 2. BIP102: 2MB actual limit > > Since the actual limits for both proposals are approximately the same, it > is not a determining factor in this discussion > > The biggest advantage of SWSF is its softfork nature. However, its > complexity is not comparable with any previous softforks we had. It is > reasonable to doubt if it could be ready in 6 months > > For BIP102, although it is a hardfork, it is a very simple one and could > be deployed with ISM in less than a month. It is even simpler than BIP34, > 66, and 65. > > So we have a very complicated softfork vs. a very simple hardfork. The > only reason makes BIP102 not easy is the fact that it's a hardfork. > > The major criticism for a hardfork is requiring everyone to upgrade. Is > that really a big problem? > > First of all, hardfork is not a totally unknown territory. BIP50 was a > hardfork. The accident happened on 13 March 2013. Bitcoind 0.8.1 was > released on 18 March, which only gave 2 months of grace period for everyone > to upgrade. The actual hardfork happened on 16 August. Everything completed > in 5 months without any panic or chaos. This experience strongly suggests > that 5 months is already safe for a simple hardfork. (in terms of > simplicity, I believe BIP102 is even simpler than BIP50) > > Another experience is from BIP66. The 0.10.0 was released on 16 Feb 2015, > exactly 10 months ago. I analyze the data on https://bitnodes.21.co and > found that 4600 out of 5090 nodes (90.4%) indicate BIP66 support. > Considering this is a softfork, I consider this as very good adoption > already. > > With the evidence from BIP50 and BIP66, I believe a 5 months > pre-announcement is good enough for BIP102. As the vast majority of miners > have declared their support for a 2MB solution, the legacy 1MB fork will > certainly be abandoned and no one will get robbed. > > > My primary proposal: > > Now - 15 Jan 2016: formally consult the major miners and merchants if they > support an one-off rise to 2MB. I consider approximately 80% of mining > power and 80% of trading volume would be good enough > > 16 - 31 Jan 2016: release 0.11.3 with BIP102 with ISM vote requiring 80% > of hashing power > > 1 Jun 2016: the first day a 2MB block may be allowed > > Before 31 Dec 2016: release SWSF > > > > My secondary proposal: > > Now: Work on SWSF in a turbo mode and have a deadline of 1 Jun 2016 > > 1 Jun 2016: release SWSF > > What if the deadline is not met? Maybe pushing an urgent BIP102 if things > become really bad. > > > In any case, I hope a clear decision and road map could be made now. This > topic has been discussed to death. We are just bringing further uncertainty > if we keep discussing. > > > Matt Corallo via bitcoin-dev 於 2015-12-16 15:50 寫到: > >> 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. >> >> > _______________________________________________ > > 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
