MIME-Version: 1.0
In-Reply-To: <B340ACFF-600F-45A9-BFE9-B831A4C6DD8E@gmail.com>
References: <COL402-EAS482BCC1B2EFF6D50273832CD830@phx.gbl>
	<CAApLimjMPvXHM4McB+xBrho2hktz8Rr7QZyU-Dgbgd7sFdoyLw@mail.gmail.com>
	<068B7F93-A1DF-4F8D-84FC-B787C5429D6A@gmail.com>
	<CAApLimjiF6zH8GAbTajMTW6p8GtXCGRa5GcV+N2z1soY5fQy+A@mail.gmail.com>
	<B340ACFF-600F-45A9-BFE9-B831A4C6DD8E@gmail.com>
Date: Wed, 22 Jul 2015 20:34:23 -0400
Message-ID: <CAApLimhFNeQ-1kpTT0YtOz2X0th563quOq1cFGhmL6VJcxFv8Q@mail.gmail.com>
From: Cory Fields <lists@coryfields.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Precedence: list

On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:
>
>> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists@coryfields.com> wrote:
>>
>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo@gmail.com> wro=
te:
>>> FWIW, I had worked on something similar a while back:
>>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>>
>>> I like the idea in principle=E2=80=A6but we should require a new genesi=
s block,
>>> different magic bytes, and a different network port at the very least. =
:)
>>>
>>
>> Not sure if serious, so I'll assume you are :)
>
> Only being partly serious - I strongly am in favor of a sufficiently modu=
larized codebase that swapping out consensus rules is fairly straightforwar=
d and easy to test. I=E2=80=99m not in favor of encouraging forking an exis=
ting blockchain without having mechanisms in place to gracefully merge back=
 without significant network disruptions. We do not have this yet.
>

Again, why? If someone wants to create a scamcoin, they can. If
someone wants to burn money on a scamcoin, equally, they can. I'm not
sure how this is any different. If someone manages to garner realistic
support for a hard-fork, I don't see the benefit in forcing them to
use forked software.. that only leaves Core in the middle because it's
forced to choose a side (not choosing is unfortunately a side as
well). It doesn't remove the reality of the split.

>> Why? The idea in this case would be to allow the user to decide
>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>> runtime rather than the likely alternative of "./bitcoind" vs
>> "./bitcoin-fork=E2=80=9D.
>
> That=E2=80=99s exactly what my coinparams_new branch does. Adding a param=
eter for maximum block size would be straightforward.
>
>> Chain params may be identical other than the value of some future
>> event (miner vote for example), in which case the configs would run
>> identically until that point.
>
> Yes, indeed - this would be a special case.
>
>> If your concern is about nodes with different configs communicating
>> with eachother, I'd like to reiterate: the idea really is no different
>> than suggesting that someone fork the codebase and implement their own
>> changes, it just cuts out most of the work required.
>
> I do not encourage anyone to try to fork an existing blockchain without f=
irst securing overwhelming (near unanimous) consensus=E2=80=A6or without ha=
ving yet built a mechanism that can merge divergent chains gracefully.

Well of course. It would be a terrible idea. People would try it and
fail, and lose money. But for those crying foul at Core for being the
consensus/policy gatekeeper, it seems to me that user-selectable
params is the only logical solution.