Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1584EDCD for ; Wed, 9 Dec 2015 11:08:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com [209.85.213.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 64F97133 for ; Wed, 9 Dec 2015 11:08:16 +0000 (UTC) Received: by vkha189 with SMTP id a189so41447013vkh.2 for ; Wed, 09 Dec 2015 03:08:15 -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=yFs0JIhFskss2F33lj+1PcjEpElCgBMpYs+zJ6sfmT4=; b=Rbv7dP8i4YaRk+EX+pOxpWhE/1/SU3KvnnYt9odPLROqJVx9i0tNbXx3lAuK//UfBr 4krnj3MB1MmpvV30tOEXrgIYQTgvvcqeyfIAKB0EisDlXrPYUbjmTgDHu9m/BWRsbF76 GnCMnqoEBYhwF4CHmiEVGepUUSxPmsk91ajdLOCieIJqXfHCuW7+OWVyURfnG/MKT80T ZtcBHqyN1gpC/vDFSUaVtkShqZE6wZMwCwX1tQpflK0ya1CAml1UkE1jnVRPcBVXrTxp Wr9JuXfW0x/dGdvGnmo0sDZBNcHCnk6wppv5BhJYrX6QtBXM8U/qjTaPQH1XfvAG7JpR mLKQ== 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=yFs0JIhFskss2F33lj+1PcjEpElCgBMpYs+zJ6sfmT4=; b=G5dDHW+1amTyrcdxh7vBWvmxpk2MjGCFtYcV6rR0tjT+H3egkXXzLBt4msn5a+Pld5 hP7ak1XYlQO+bSzh586BIUc9XWKbu56cUy21GFZZo2ZU+R2tMV/cRZYWVyX4WlUlovGv JlKfdt0mv4hRr7o1pchHPNjXSsqD+zpOFtdysdztG2zvMTd7I6hO6dT+A83llvEqNxqw ahc4CoXnPFo9L0cKXePsZlRtB0m8OfL6LLcWAZ0djNgDmNHKLximoKCM/PnqI1j7VOfl HuL1tcX57C8kHNgFG9b8AV9up5tOq1wuGlHvztD+gepHbuV4SESC7smLKit2jDQpAwBQ 0Teg== X-Gm-Message-State: ALoCoQnQxxRcggZrt01x7wgbdstlYNFra+KPiym5hhxumJ2w6xaBCBlG0b0tebLkCOWk3503VIk5hDmGxZ0Xnuua1bTTuYo/bQ== MIME-Version: 1.0 X-Received: by 10.31.169.137 with SMTP id s131mr4147119vke.144.1449659295532; Wed, 09 Dec 2015 03:08:15 -0800 (PST) Received: by 10.31.236.70 with HTTP; Wed, 9 Dec 2015 03:08:14 -0800 (PST) Received: by 10.31.236.70 with HTTP; Wed, 9 Dec 2015 03:08:14 -0800 (PST) In-Reply-To: References: <20151208110752.GA31180@amethyst.visucore.com> Date: Wed, 9 Dec 2015 12:08:14 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Gregory Maxwell Content-Type: multipart/alternative; boundary=001a11425bf05b1fa60526751b2a X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,URIBL_BLACK autolearn=no 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] Capacity increases for the Bitcoin system. 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: Wed, 09 Dec 2015 11:08:20 -0000 --001a11425bf05b1fa60526751b2a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fair enough. On Dec 9, 2015 4:03 PM, "Gregory Maxwell" wrote: > On Wed, Dec 9, 2015 at 7:54 AM, Jorge Tim=C3=B3n wrote= : > > From this question one could think that when you said "we can do the > > cleanup hardfork later" earlier you didn't really meant it. And that > > you will oppose to that hardfork later just like you are opposing to > > it now. > > As said I disagree that making a softfork first and then move the > > commitment is less disruptive (because people will need to adapt their > > software twice), but if the intention is to never do the second part > > then of course I agree it would be less disruptive. > > How long after the softfork would you like to do the hardfork? > > 1 year after the softfork? 2 years? never? > > I think it would be logical to do as part of a hardfork that moved > commitments generally; e.g. a better position for merged mining (such > a hardfork was suggested in 2010 as something that could be done if > merged mining was used), room for commitments to additional block > back-references for compact SPV proofs, and/or UTXO set commitments. > Part of the reason to not do it now is that the requirements for the > other things that would be there are not yet well defined. For these > other applications, the additional overhead is actually fairly > meaningful; unlike the fraud proofs. > --001a11425bf05b1fa60526751b2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Fair enough.

On Dec 9, 2015 4:03 PM, "Gregory Maxwell&qu= ot; <greg@xiph.org> wrote:
On Wed, Dec 9, 2015 at 7:= 54 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> From this question one could think that when you said "we can do = the
> cleanup hardfork later" earlier you didn't really meant it. A= nd that
> you will oppose to that hardfork later just like you are opposing to > it now.
> As said I disagree that making a softfork first and then move the
> commitment is less disruptive (because people will need to adapt their=
> software twice), but if the intention is to never do the second part > then of course I agree it would be less disruptive.
> How long after the softfork would you like to do the hardfork?
> 1 year after the softfork? 2 years? never?

I think it would be logical to do as part of a hardfork that moved
commitments generally; e.g. a better position for merged mining (such
a hardfork was suggested in 2010 as something that could be done if
merged mining was used), room for commitments to additional block
back-references for compact SPV proofs, and/or UTXO set commitments.
Part of the reason to not do it now is that the requirements for the
other things that would be there are not yet well defined. For these
other applications, the additional overhead is actually fairly
meaningful; unlike the fraud proofs.
--001a11425bf05b1fa60526751b2a--