From: jl2012 <jl2012@xbt•hk>
To: Matt Corallo <lf-lists@mattcorallo•com>
Cc: Jeff Garzik via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin
Date: Thu, 17 Dec 2015 00:32:11 -0500 [thread overview]
Message-ID: <9869fe48a4fc53fc355a35cead73fca2@xbt.hk> (raw)
In-Reply-To: <49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com>
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.
>
next prev parent reply other threads:[~2015-12-17 5:32 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 20:38 Jeff Garzik
2015-12-16 20:50 ` Matt Corallo
2015-12-16 21:51 ` Jameson Lopp
2015-12-16 22:29 ` Matt Corallo
2015-12-16 22:32 ` Matt Corallo
2015-12-17 2:21 ` Jeff Garzik
2015-12-17 2:44 ` Eric Lombrozo
2015-12-17 2:58 ` Jeff Garzik
2015-12-17 3:48 ` Adam Back
2015-12-17 5:32 ` jl2012 [this message]
2015-12-17 7:54 ` Corey Haddad
2015-12-17 13:09 ` Jorge Timón
2015-12-17 15:51 ` sickpig
2015-12-17 17:55 ` Anthony Towns
2015-12-18 10:01 ` sickpig
2015-12-19 7:50 ` Mark Friedenbach
2015-12-19 23:03 ` Dave Scotese
2015-12-17 9:33 ` Mark Friedenbach
2015-12-17 10:00 ` jl2012
2015-12-17 10:57 ` Anthony Towns
2015-12-17 6:14 ` Marcel Jamin
2015-12-16 20:59 ` Pieter Wuille
2015-12-16 21:27 ` Jeff Garzik
2015-12-16 21:36 ` Pieter Wuille
2015-12-16 22:09 ` Jeff Garzik
2015-12-16 22:10 ` Jeff Garzik
2015-12-17 18:27 ` Jeff Garzik
2015-12-17 18:46 ` jl2012
2015-12-17 18:52 ` Jeff Garzik
2015-12-17 21:18 ` Eric Lombrozo
2015-12-17 21:31 ` Adam Back
2015-12-17 3:52 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9869fe48a4fc53fc355a35cead73fca2@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox