I know my reply is a long one but please read before you hit send. I
have 2 proposals: fast BIP102 + slow SWSF and fast SWSF only. I guess no
one here is arguing for not doing segwit; and it is on the top of my
wish list. My main argument (maybe also Jeff's) is that segwit is too
complicated and may not be a viable short term solution (with the
reasons I listed that I don't want to repeat)
And also I don't agree with you that BIP102 is *strictly* inferior than
segwit. We never had a complex softfork like segwit, but we did have a
successful simple hardfork (BIP50), and BIP102 is very simple. (Details
in my last post. I'm not going to repeat)
Mark Friedenbach 於 2015-12-17 04:33 寫到:
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.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
