MIME-Version: 1.0
In-Reply-To: <9869fe48a4fc53fc355a35cead73fca2@xbt.hk>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
	<49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
	<9869fe48a4fc53fc355a35cead73fca2@xbt.hk>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Thu, 17 Dec 2015 17:33:26 +0800
Message-ID: <CAOG=w-sMdp1+mcNZc_yfwx59EAwSkFUHekRrqcYXsuLVoCw=1A@mail.gmail.com>
To: jl2012 <jl2012@xbt.hk>
Content-Type: multipart/alternative; boundary=001a1140ac0e27dce5052714b8c3
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

--001a1140ac0e27dce5052714b8c3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 everyo=
ne
> to upgrade. The actual hardfork happened on 16 August. Everything complet=
ed
> 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 miner=
s
> 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 the=
y
> 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 uncertain=
ty
> if we keep discussing.
>
>
> Matt Corallo via bitcoin-dev =E6=96=BC 2015-12-16 15:50 =E5=AF=AB=E5=88=
=B0:
>
>> 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
>

--001a1140ac0e27dce5052714b8c3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>There are many reasons to support segwit be=
yond it being a soft-fork. For example:<br><br>* the limitation of non-witn=
ess data to no more than 1MB makes the quadratic scaling costs in large tra=
nsaction validation no worse than they currently are;<br></div>* redeem scr=
ipts in witness use a more accurate cost accounting than non-witness data (=
further improvements to this beyond what Pieter has implemented are possibl=
e); and<br></div>* segwit provides features (e.g. opt-in malleability prote=
ction) which are required by higher-level scaling solutions.<br><br></div>W=
ith that in mind I really don&#39;t understand the viewpoint that it would =
be better to engage a strictly inferior proposal such as a simple adjustmen=
t of the block size to 2MB.<br><div><div><div><div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Thu, Dec 17, 2015 at 1:32 PM, jl2012 v=
ia bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are at least =
2 proposals on the table:<br>
<br>
1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately equa=
ls to 2MB actual limit<br>
<br>
2. BIP102: 2MB actual limit<br>
<br>
Since the actual limits for both proposals are approximately the same, it i=
s not a determining factor in this discussion<br>
<br>
The biggest advantage of SWSF is its softfork nature. However, its complexi=
ty is not comparable with any previous softforks we had. It is reasonable t=
o doubt if it could be ready in 6 months<br>
<br>
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.<br>
<br>
So we have a very complicated softfork vs. a very simple hardfork. The only=
 reason makes BIP102 not easy is the fact that it&#39;s a hardfork.<br>
<br>
The major criticism for a hardfork is requiring everyone to upgrade. Is tha=
t really a big problem?<br>
<br>
First of all, hardfork is not a totally unknown territory. BIP50 was a hard=
fork. The accident happened on 13 March 2013. Bitcoind 0.8.1 was released o=
n 18 March, which only gave 2 months of grace period for everyone to upgrad=
e. The actual hardfork happened on 16 August. Everything completed in 5 mon=
ths without any panic or chaos. This experience strongly suggests that 5 mo=
nths is already safe for a simple hardfork. (in terms of simplicity, I beli=
eve BIP102 is even simpler than BIP50)<br>
<br>
Another experience is from BIP66. The 0.10.0 was released on 16 Feb 2015, e=
xactly 10 months ago. I analyze the data on <a href=3D"https://bitnodes.21.=
co" rel=3D"noreferrer" target=3D"_blank">https://bitnodes.21.co</a> and fou=
nd that 4600 out of 5090 nodes (90.4%) indicate BIP66 support. Considering =
this is a softfork, I consider this as very good adoption already.<br>
<br>
With the evidence from BIP50 and BIP66, I believe a 5 months pre-announceme=
nt 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 aba=
ndoned and no one will get robbed.<br>
<br>
<br>
My primary proposal:<br>
<br>
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 powe=
r and 80% of trading volume would be good enough<br>
<br>
16 - 31 Jan 2016: release 0.11.3 with BIP102 with ISM vote requiring 80% of=
 hashing power<br>
<br>
1 Jun 2016: the first day a 2MB block may be allowed<br>
<br>
Before 31 Dec 2016: release SWSF<br>
<br>
<br>
<br>
My secondary proposal:<br>
<br>
Now: Work on SWSF in a turbo mode and have a deadline of 1 Jun 2016<br>
<br>
1 Jun 2016: release SWSF<br>
<br>
What if the deadline is not met? Maybe pushing an urgent BIP102 if things b=
ecome really bad.<br>
<br>
<br>
In any case, I hope a clear decision and road map could be made now. This t=
opic has been discussed to death. We are just bringing further uncertainty =
if we keep discussing.<br>
<br>
<br>
Matt Corallo via bitcoin-dev =E6=96=BC 2015-12-16 15:50 =E5=AF=AB=E5=88=B0:=
<span class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
A large part of your argument is that SW will take longer to deploy<br>
than a hard fork, but I completely disagree. Though I do not agree<br>
with some people claiming we can deploy SW significantly faster than a<br>
hard fork, once the code is ready (probably a six month affair) we can<br>
get it deployed very quickly. It&#39;s true the ecosystem may take some<br>
time to upgrade, but I see that as a feature, not a bug - we can build<br>
up some fee pressure with an immediate release valve available for<br>
people to use if they want to pay fewer fees.<br>
<br>
=C2=A0On the other hand, a hard fork, while simpler for the ecosystem to<br=
>
upgrade to, is a 1-2 year affair (after the code is shipped, so at<br>
least 1.5-2.5 from today if we all put off heads down and work). One<br>
thing that has concerned me greatly through this whole debate is how<br>
quickly people seem to think we can roll out a hard fork. Go look at<br>
the distribution of node versions on the network today and work<br>
backwards to get nearly every node upgraded... Even with a year<br>
between fork-version-release and fork-activation, we&#39;d still kill a<br>
bunch of nodes and instead of reducing their security model, lead them<br>
to be outright robbed.<br>
<br>
</blockquote>
<br></span>
_______________________________________________<div class=3D"HOEnZb"><div c=
lass=3D"h5"><br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div></div></div></div></div></div>

--001a1140ac0e27dce5052714b8c3--