Date: Sat, 27 Jun 2015 14:09:39 +0200
From: "Wladimir J. van der Laan" <laanwj@gmail.com>
To: Jorge =?iso-8859-1?Q?Tim=F3n?= <jtimon@jtimon.cc>
Message-ID: <20150627120935.GD25420@amethyst.visucore.com>
References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>
	<20150627074259.GA25420@amethyst.visucore.com>
	<CABm2gDr3orTHMN1q8vGmy3NpXWPy5i=zHhGneDGUk=ney3-e+Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABm2gDr3orTHMN1q8vGmy3NpXWPy5i=zHhGneDGUk=ney3-e+Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] The need for larger blocks
Precedence: list

Jorge,

> Provided they're also uncontroversial, they don't need to be that
> different (in terms of deployment) from softforks. Since they risks
> are bigger you just need to give more time for users and alternative
> software to upgrade.

Sure, most extreme: if secp256k1 or SHA256 starts to show chinks in its armor, or practical quantum computing is getting powerful enough to factor discrete logarithms of those sizes, I don't doubt everyone would go along with a proposal to add new crypto algos.

I do expect there are other possible hardforks that are uncontroversial. Either

- minor issues (maybe solving the time-warp issue with mining) issues planned on the long term
- features that are not politically loaded, on the long term
- major emergencies (anything that is clearly an 'exploit' with regard to coin holders or miners)

Not sure though. The only way to find out is to propose them and see. Maybe wait a bit until things have cooled down...

Note that anything non-critical and non-controversial can be planned and time-locked, say, 5 years ahead, obliviating the need for anyone to quickly upgrade their client.

Wladimir