MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <CABm2gDq4f0ettDhh14jZ0zztSwSJ0Z=KDEeMTOJxTHF8VV+KXw@mail.gmail.com>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
	<20151208110752.GA31180@amethyst.visucore.com>
	<CABm2gDpcek=u=Rpe68EMOq6M7Bji9J=s5VvoQWKRqaQDAP5kTw@mail.gmail.com>
	<CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@mail.gmail.com>
	<CAAS2fgTGYSiAJHZq80rD4UieV8XetS=W0b45b5onWAS9gF-F7g@mail.gmail.com>
	<CABsx9T1i50Gvxj18W=n2mYGNpsMrSkDT26CdA3aQqT5FFN86yw@mail.gmail.com>
	<CAAS2fgSxpSat3VOje3-C4zgaRUVJVx-eRJbSYJqhvfR5SvCDwA@mail.gmail.com>
	<CAF_2MyUJMdJyh7FKq6UYCtwJZQ59i-pnWT_tFEK5EQx65iwHDQ@mail.gmail.com>
	<CAAS2fgS-jjEVeHf_LErppTadtAaSeBum+KiGHpoo=Jz5BZArsQ@mail.gmail.com>
	<CABm2gDq4f0ettDhh14jZ0zztSwSJ0Z=KDEeMTOJxTHF8VV+KXw@mail.gmail.com>
Date: Wed, 9 Dec 2015 08:03:45 +0000
Message-ID: <CAAS2fgTAFgANJ495xiOkiW-OeFA_VZHhhR5uL+jVaoYQz_yBPg@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Precedence: list

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. 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.