MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Thu, 17 Dec 2015 05:00:24 -0500
From: jl2012 <jl2012@xbt.hk>
To: Mark Friedenbach <mark@friedenbach.org>
In-Reply-To: <CAOG=w-sMdp1+mcNZc_yfwx59EAwSkFUHekRrqcYXsuLVoCw=1A@mail.gmail.com>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
	<49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
	<9869fe48a4fc53fc355a35cead73fca2@xbt.hk>
	<CAOG=w-sMdp1+mcNZc_yfwx59EAwSkFUHekRrqcYXsuLVoCw=1A@mail.gmail.com>
Message-ID: <18f0e80b0a55272a61d547f59efc6c9d@xbt.hk>
User-Agent: Roundcube Webmail/1.0.5
Cc: Jeff Garzik via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling
 Bitcoin
Precedence: list

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.