public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mark Friedenbach <mark@friedenbach.org>
To: jl2012 <jl2012@xbt.hk>
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 17:33:26 +0800	[thread overview]
Message-ID: <CAOG=w-sMdp1+mcNZc_yfwx59EAwSkFUHekRrqcYXsuLVoCw=1A@mail.gmail.com> (raw)
In-Reply-To: <9869fe48a4fc53fc355a35cead73fca2@xbt.hk>

[-- Attachment #1: Type: text/plain, Size: 5252 bytes --]

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 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.
>>
>>
> _______________________________________________
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6168 bytes --]

  parent reply	other threads:[~2015-12-17  9:33 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16 20:38 [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin 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
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 [this message]
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='CAOG=w-sMdp1+mcNZc_yfwx59EAwSkFUHekRrqcYXsuLVoCw=1A@mail.gmail.com' \
    --to=mark@friedenbach.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jl2012@xbt.hk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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