Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E389BEB2 for ; Thu, 17 Dec 2015 13:09:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com [209.85.213.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B636B150 for ; Thu, 17 Dec 2015 13:09:06 +0000 (UTC) Received: by mail-vk0-f44.google.com with SMTP id a189so45890500vkh.2 for ; Thu, 17 Dec 2015 05:09:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ac5wTfy9q8WH3gpNfH/llgBAsEODiV4zCd1Thr3OM1Y=; b=ArYDoCzrQpF2kTpZNAtHKq5oTjDEPkt658KvpLFALudG/j4BRpitnwmYDikk3OmRn9 oSwOqAU2xZpY2pvybaXx7u1jvnKq2TBDvrmSP0/k3fJN5hYlqQToWAy4lJvbPRfFWIjS x8FVhTa6v6mr5rmiBB/+J60BMmqo6zhs///2Gu4Zbs+lJSfJr+agaHD0w+tSSz4n8ZZu Axzf2xMvKOyzUMdJGODSH/ZJFpvXCLgPLk6QTiPAas2mAM6cdZwQU2OJw6eVfjnv8wzJ 2IisNojVF70hrcE5ww+mQjoL1XiVxscBsBH4JoZmbHqoEk3+AVOBU2PgPXecM0041wu6 AOJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ac5wTfy9q8WH3gpNfH/llgBAsEODiV4zCd1Thr3OM1Y=; b=XvzC26cSen+8J4mg4CUlj3uRPz3MaNLIPYLWD4+hXu8u1f+eVFQPaje7h21PjZEoR2 ufgNFus/C+HwGRwkTu6RW/ldpfjqC2kam9ulPjSOmR3IelCnQ8ftm7WIRFKbUC557cxh RYWe9vOGA1xicBulJ+wbOMOw1PYvG0JP6ZnXhY78tjtTu0Vu8AKnSub+4vdAsbXqd/Wj AgQgqAWOPdHIyPj5CHHm6D2Vlw9x4QVnP3bO02Gr5E5rOiHa5qasgxLC41ADmbltglm+ UOS0nolQ44NoeTy2JREKack21gybiBEi36SEVJZU/ov6Di+kQNxkWsnnw+2iUuplwWwW m0gQ== X-Gm-Message-State: ALoCoQmUyzpR0EFQfupAjZ5GTzpJZ6LsD6IHX5RVPvGiT9zYCxOP1F7+sKPKedE27o9BtEVyzy2lgPahzz1Ce5tedtoTuTBSpw== MIME-Version: 1.0 X-Received: by 10.31.149.10 with SMTP id x10mr11663550vkd.144.1450357745749; Thu, 17 Dec 2015 05:09:05 -0800 (PST) Received: by 10.31.236.70 with HTTP; Thu, 17 Dec 2015 05:09:05 -0800 (PST) Received: by 10.31.236.70 with HTTP; Thu, 17 Dec 2015 05:09:05 -0800 (PST) In-Reply-To: References: <49257841-66C8-4EF7-980B-73DC604CA591@mattcorallo.com> <9869fe48a4fc53fc355a35cead73fca2@xbt.hk> Date: Thu, 17 Dec 2015 14:09:05 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Corey Haddad Content-Type: multipart/alternative; boundary=001a11408b143bd659052717ba7e X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 Cc: 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 13:09:08 -0000 --001a11408b143bd659052717ba7e Content-Type: text/plain; charset=UTF-8 Although I agree that how safe a pre-hardfork upgrade period is depends on the complexity of the changes (we should assume everyone may need time to reimplementat it themselves in their own implementations, not just upgrade bitcoin core) and bip102 is indeed a very simple hardfork, I think less than 6 months for a hardfork is starting to push it too much. For a more complex hardfork (say, a SW hardfork or a collection of many little fixes) I believe 1 year or more would make more sense. BIP99 recommends a time threshold (height or median time) + 95% miner upgrade confirmation with BIP9 (version bits). So how about the following plan? 1) Deploy BIP102 when its ready + 6 median time months + 95% miner upgrade confirmation 2) Deploy SW when it's ready + 95% miner upgrade confirmation via bip9. Note that both "when it's ready" depend on something we are not paying a lot of attention to: bip9's implementation (just like bip113, bip68-112, bip99, the coinbase-commitments-cleanup post-SW uncontroversial hardfork, etc). Unless I'm missing something, 2 mb x4 = 8mb, so bip102 + SW is already equivalent to the 2-4-8 "compromise" proposal (which by the way I never liked, because I don't think anybody should be in a position to "compromise" anything and because I don't see how "let's avoid an unavoidable economic change for a little bit longer" arguments can reasoably claim that "we need to kick the can down the road exactly 3 more times" or whatever is the reasoning behind it). --001a11408b143bd659052717ba7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Although I agree that how safe a pre-hardfork upgrade period= is depends on the complexity of the changes (we should assume everyone may= need time to reimplementat it themselves in their own implementations, not= just upgrade bitcoin core) and bip102 is indeed a very simple hardfork, I = think less than 6 months for a hardfork is starting to push it too much. For a more complex hardfork (say, a SW hardfork or a collection of many lit= tle fixes) I believe 1 year or more would make more sense.

BIP99 recommends a time threshold (height or median time) + = 95% miner upgrade confirmation with BIP9 (version bits).
So how about the following plan?

1) Deploy BIP102 when its ready + 6 median time months + 95%= miner upgrade confirmation

2) Deploy SW when it's ready + 95% miner upgrade confirm= ation via bip9.

Note that both "when it's ready" depend on som= ething we are not paying a lot of attention to: bip9's implementation (= just like bip113, bip68-112, bip99, the coinbase-commitments-cleanup post-S= W uncontroversial hardfork, etc).

Unless I'm missing something, 2 mb x4 =3D 8mb, so bip102= + SW is already equivalent to the 2-4-8 "compromise" proposal (w= hich by the way I never liked, because I don't think anybody should be = in a position to "compromise" anything and because I don't se= e how "let's avoid an unavoidable economic change for a little bit= longer" arguments can reasoably claim that "we need to kick the = can down the road exactly 3 more times" or whatever is the reasoning b= ehind it).

--001a11408b143bd659052717ba7e--