From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E2907D18 for ; Thu, 17 Dec 2015 07:54:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C1B1D184 for ; Thu, 17 Dec 2015 07:54:41 +0000 (UTC) Received: by mail-io0-f169.google.com with SMTP id e126so46769930ioa.1 for ; Wed, 16 Dec 2015 23:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r0Ethd/QID/fWuCewKdcT9Q+ioLrT4Ff7ZlLlmMISsc=; b=SBJ6jFxlEAAR6nlLugXMCkhnD2IhrYSa8gqFDSEaz8o5XKz7RIHm3Xlwy/GjZBE8IF EFCGMMYW2E8gThuySAgubG5LyIAjTCHgRMB0qMK7aUfjop5GV+c6VegNAPNRA6epMopr zC1lFSmaVT+QXX65CHbi1vKqyvvb7dXYyBbwn10WbgRrO3vvFdzl6VN8FhZt1q2hKs+I 5QtSR+M1j1yT14ypCXnfdl1svvWPjed66KYV3BtW6ZPUVH/uN30NSQPxS+KkKALtzix9 gxf/lGLQjT7eyHXKYzmbg6fTpRobijYkaa+v0t342Y8dNIUaRWZU5Z9Wfxmd1r8mGmoQ 59OA== MIME-Version: 1.0 X-Received: by 10.107.25.4 with SMTP id 4mr44305647ioz.185.1450338881204; Wed, 16 Dec 2015 23:54:41 -0800 (PST) Received: by 10.64.234.198 with HTTP; Wed, 16 Dec 2015 23:54:41 -0800 (PST) In-Reply-To: <9869fe48a4fc53fc355a35cead73fca2@xbt.hk> References: <49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com> <9869fe48a4fc53fc355a35cead73fca2@xbt.hk> Date: Wed, 16 Dec 2015 23:54:41 -0800 Message-ID: From: Corey Haddad To: jl2012 Content-Type: multipart/alternative; boundary=001a113fd65ed178cb052713550f X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 17 Dec 2015 12:36:00 +0000 Cc: Jeff Garzik via bitcoin-dev Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 07:54:43 -0000 --001a113fd65ed178cb052713550f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A planned hardfork, similar to certain softforks, leaves users with some reduction in security. It does not leave them defenseless. Consider the following: 1: Hard to be robbed on the basis of hashpower. In reality the old chain will see mining all but stop, and blocks would be hours to days apart even if a couple percentage points of hashpower failed to switch over. Six confirmations would certainly take days. If the fork can be scheduled at the beginning of a difficulty period, the old chain would almost certainly not even ever make it to the next retargeting. 2: Hard to be robber on the basis of awareness. Expect there to be fairly widespread coverage in the Bitcoin press, and as the fork draws near, maybe coverage in business and tech publications. Further, the alert keys will certainly be used, so node operators will get the message directly. 3: There still needs to be a targeted attack by a fraudster on an unaware node operator. To fall victim, one needs to give up something of value to an attacker in exchange for Bitcoins (on the old chain). The typical uninitiated full-node user (probably a small subset anyway) is typically going to be buying bitcoin from a trusted source, and then saving or spending them, or perhaps gambling. They are not, typically, going to be providing a service or selling goods in exchange for Bitcoin unless they are at least somewhat aware of what is going on in the Bitcoin space. It's possible, of course, but we are talking about small numbers here of people who fit the above. All three parts of the above would have to go perfectly wrong for someone to loose out. Someone somewhere will probably get scammed as a result of a hardfork. That stinks, and we should make reasonable efforts to help them avoid that fate. But at this point in Bitcoin's development, it is still in beta, it's still an economic experiment, and we can't allow the software to become hamstrung out of fear that some inattentive user might bungle their security. If they merely waited for 6 confirmations, as is the standard advice, they would be waiting for days. If that along doesn't give them a hint that something is wrong, it might still be too early days for them to be playing with Bitcoin for anything important. I support a hardfork deployment that takes 80% of hashpower activate + a 4-month delay. On Wed, Dec 16, 2015 at 9: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 > --001a113fd65ed178cb052713550f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A planned hardfork, similar to certain softforks, leaves u= sers with some reduction in security.=C2=A0 It does not leave them defensel= ess.=C2=A0 Consider the following:

1: Hard to be robbed on the basis= of hashpower.

In reality the old chain will see mining all but stop= , and blocks would be hours to days apart even if a couple percentage point= s of hashpower failed to switch over.=C2=A0 Six confirmations would certain= ly take days.=C2=A0 If the fork can be scheduled at the beginning of a diff= iculty period, the old chain would almost certainly not even ever make it t= o the next retargeting.

2: Hard to be robber on the basis of awarene= ss.

Expect there to be fairly widespread coverage in the Bitcoin pre= ss, and as the fork draws near, maybe coverage in business and tech publica= tions.=C2=A0 Further, the alert keys will certainly be used, so node operat= ors will get the message directly.

3: There still needs to be a targ= eted attack by a fraudster on an unaware node operator.

To fall vict= im, one needs to give up something of value to an attacker in exchange for = Bitcoins (on the old chain).=C2=A0 The typical uninitiated full-node user (= probably a small subset anyway) is typically going to be buying bitcoin fro= m a trusted source, and then saving or spending them, or perhaps gambling.= =C2=A0 They are not, typically, going to be providing a service or selling = goods in exchange for Bitcoin unless they are at least somewhat aware of wh= at is going on in the Bitcoin space.=C2=A0 It's possible, of course, bu= t we are talking about small numbers here of people who fit the above.
<= br>All three parts of the above would have to go perfectly wrong for someon= e to loose out.=C2=A0 Someone somewhere will probably get scammed as a resu= lt of a hardfork.=C2=A0 That stinks, and we should make reasonable efforts = to help them avoid that fate.=C2=A0 But at this point in Bitcoin's deve= lopment, it is still in beta, it's still an economic experiment, and we= can't allow the software to become hamstrung out of fear that some ina= ttentive user might bungle their security.=C2=A0 If they merely waited for = 6 confirmations, as is the standard advice, they would be waiting for days.= =C2=A0 If that along doesn't give them a hint that something is wrong, = it might still be too early days for them to be playing with Bitcoin for an= ything important.

I support a hardfork deployment that takes 80% of = hashpower activate + a 4-month delay.
=
On Wed, Dec 16, 2015 at 9:32 PM, jl2012 via = bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:
There are at least 2 p= roposals on the table:

1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately equa= ls to 2MB actual limit

2. BIP102: 2MB actual limit

Since the actual limits for both proposals are approximately the same, it i= s not a determining factor in this discussion

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

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 tha= t really a big problem?

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)

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 https://bitnodes.21.co 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.

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.


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 powe= r 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 b= ecome really bad.


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.


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.

=C2=A0On 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.


 _______________________________________________

--001a113fd65ed178cb052713550f--