Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_72A70D00-E466-4464-B099-2943312A12B4";
	protocol="application/pgp-signature"; micalg=pgp-sha512
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CAApLimhFNeQ-1kpTT0YtOz2X0th563quOq1cFGhmL6VJcxFv8Q@mail.gmail.com>
Date: Wed, 22 Jul 2015 17:43:02 -0700
Message-Id: <D02A0586-83CA-4BD6-B607-73570C695081@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>
	<CAApLimhFNeQ-1kpTT0YtOz2X0th563quOq1cFGhmL6VJcxFv8Q@mail.gmail.com>
To: Cory Fields <lists@coryfields.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Precedence: list


--Apple-Mail=_72A70D00-E466-4464-B099-2943312A12B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


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

In general, new consensus rules are not trivial to implement. Block size =
limits are exceptional in being so simple to change in the code. So what =
you=E2=80=99re proposing sounds more like a plugin model supporting =
dynamic linking than a configuration file.

>>> 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.
>>=20
>> That=E2=80=99s exactly what my coinparams_new branch does. Adding a =
parameter for maximum block size would be straightforward.
>>=20
>>> 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.
>>=20
>> Yes, indeed - this would be a special case.
>>=20
>>> 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.
>>=20
>> I do not encourage anyone to try to fork an existing blockchain =
without first securing overwhelming (near unanimous) consensus=E2=80=A6or =
without having yet built a mechanism that can merge divergent chains =
gracefully.
>=20
> 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.

The real problem isn=E2=80=99t so much the difficulty of creating forks =
of the codebase - but the fact that unless a fork has overwhelming =
support, blockchains cannot guarantee irreversibility of =
transactions=E2=80=A6which defeats their entire purpose.

--Apple-Mail=_72A70D00-E466-4464-B099-2943312A12B4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVsDiWAAoJEJNAI64YFENUVwMP/j8//ocBVHxp1JeI+k3WppT5
0z6+yyCIR8eo5lyAj/ngAM1Jcah7l75/bYwcP0RjqS9cBxV5FlTBv0/bosTx9boK
ix7jE68X0jVq8fiUIhm7sFHbjdfx0c4/eh63MFjNdopDA7wXRKEzuf0CzJQQ5QkJ
skvvNXf8nuSoHoff+55kTiiGob1BT8xdxaenIB9VRgYAITOSJbqPVp8QeimzIGYd
XGTG8Xp4Bg+AttdJFDjsE/1lnKRv1Xzt2Ti7U8nHXkU0KBQ6nl5oVW+fGCtFEld3
3e8/AcW/bTgrrkOA5F1IV9gjbA8WoSaGqo6RUCY0o7tl8etkoREU/Xj9g/VZ7gLi
MgVU+1lMspx40lktoFJEc5aHzXLiKAErcZ6EMpJ7RQ9ot38DMeLZBdFhr/+LOQYE
/6oysni7UbAvZL3GLzDFcjQ+R1ojkb1efXF4Iq6QafcarGF5YymjAtXRrxTg/STU
UNN/XcvoCTyRKroPjiKSvr6tBRh1K1X9OpUT3kqLY16MpKHIR7I5p0oJ13F2J61e
shes8FV2EqKMTfef7c4lO1gi+8INe4B2qroExVkyupE+cYaPk3KSv2YLqYd29nVv
OQfXj/mbtB1RTWS9+C4YsLSwyRtx+2Hua4u+uWQQLFkar98GEFPZWGug6Gmo2uc/
OhM7vpdr0u7BQCbTKa/a
=9mEl
-----END PGP SIGNATURE-----

--Apple-Mail=_72A70D00-E466-4464-B099-2943312A12B4--