Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <EMmw5p_aZLoAKdZKan47iSwAq_X9flneBX-1nOOpIpk08NzihG0yZedl0R5G2HLwlrjUCqscSa9uVTKPc83ewQIXbjKOHXSDeX-i8AV7Suw=@protonmail.ch>
Date: Mon, 27 Feb 2017 08:50:07 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <09746CD6-10FB-4F3B-B4E1-AE12E504141B@voskuil.org>
References: <jo5-7HCZX7tgdMpIQgK85HCPP14FWxvOIbjV_oerIfc-HOP1GbK3SxFX82Ls23yU1L7y95QsFFggddMNdo5Sxy7YhTJhRFN1f8d6PaA8b7s=@protonmail.ch>
	<CADL_X_fUuTexNYBt=rZUXRuXpKrpyTiiXYkxTxquispLGV6ezQ@mail.gmail.com>
	<EMmw5p_aZLoAKdZKan47iSwAq_X9flneBX-1nOOpIpk08NzihG0yZedl0R5G2HLwlrjUCqscSa9uVTKPc83ewQIXbjKOHXSDeX-i8AV7Suw=@protonmail.ch>
To: shaolinfry <shaolinfry@protonmail.ch>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Moving towards user activated soft fork activation
Precedence: list

On Feb 27, 2017, at 8:02 AM, shaolinfry via bitcoin-dev <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:

>> 3) In terms of complexity for mining pool operators, how well does this m=
odel scale if there are N soft forks and the pool doesn't want to opt-in to a=
ny of them? Couldn't this result in those pool operators having to run not j=
ust one border node, but a multitude of "chained" border nodes if the soft f=
orks are spread across different software implementations?
>=20
> While BIP9 allows for 29 parallel deployments I think it is unrealistic to=
 expect there would be such a high number of active parallel deployments at a=
ny one time: History shows soft forks take a minimum of 6 months design, con=
sensus building, coding and testing before deployment. With such a high bar,=
 I do not envisage more than a couple of parallel deployments at any given t=
ime. I also do not envisage "conflicting" soft forks, as that would not meet=
 consensus from the technical community on the basis of safety and sanity. I=
n any case, the deployment strategy of each soft fork should be considered o=
n a case by case basis.

The relationship between a codebase and chain fork implementations is simila=
r to vendor lock-in, and is being used in a similar manner.

There is nothing preventing a single codebase from implementing all forks an=
d exposing the option to apply any non-conflicting combination of them.

While this has not been the norm libbitcoin now utilizes this approach. Curr=
ently the options to apply any activated Bitcoin forks are exposed via confi=
g. I personally am not working to implement non-activated forks at this poin=
t, but that's just prioritization.

Recently I objected to BIP90. This hard fork is presented as a code simplifi=
cation and a performance optimization. I showed in the discussion that it wa=
s neither. Nevertheless we implemented this additional code and give the use=
r the option to apply it or not. It's application produces no performance be=
nefit, but it ensures that the choice of forks remains in the hands of the u=
ser.

e=