path: root/56/027cd8038d4cce294e81952916b3a9f2eb03c9

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EB00A49D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 23:53:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com
	[209.85.220.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E960FE0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 23:53:43 +0000 (UTC)
Received: by pacan13 with SMTP id an13so147916366pac.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 16:53:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to;
	bh=kR0t5FAQEZbodwqkz95hUdF/DeGJ03J4IgtUzH9lJKs=;
	b=h3mP+36ynTXmIPGBbf/qgl2q8t8R3PaR7pUqeOomjsWafdOr3zpWMIpF+6NUc76k4c
	nhEqQYL3HRXoSZt1Gp/X8fYmcTlkhdfiobIb+Udot9LVr+j1Q4Kb/jpS8CBxj5A5+C/M
	zoxMzkAfYMzUSkmiBXMVo2NJAhV6oXCN0eaa0icHF1FE9HVMQI069uD+W7Avq1PWjUn6
	2lcFf+/C6Pm0yeEGz+Y65qlX5fdLU3A/PoS7T2TSKxnajQD2B4fYo1Rq6PO49cXL9JFv
	8KcVjbKVsKUKcRFqYwSuKXL1NHB2c3qC6ADh2I4EGgsdIT9Y06/rdItD9KBOBEqtpNM0
	ZW2A==
X-Received: by 10.66.66.173 with SMTP id g13mr11666050pat.155.1437609223556;
	Wed, 22 Jul 2015 16:53:43 -0700 (PDT)
Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
	cl15sm5312454pdb.27.2015.07.22.16.53.41
	(version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 22 Jul 2015 16:53:42 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_5A620A44-CC81-42CD-BF23-BEAEBA4DA285";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CAApLimjMPvXHM4McB+xBrho2hktz8Rr7QZyU-Dgbgd7sFdoyLw@mail.gmail.com>
Date: Wed, 22 Jul 2015 16:53:39 -0700
Message-Id: <068B7F93-A1DF-4F8D-84FC-B787C5429D6A@gmail.com>
References: <COL402-EAS482BCC1B2EFF6D50273832CD830@phx.gbl>
	<CAApLimjMPvXHM4McB+xBrho2hktz8Rr7QZyU-Dgbgd7sFdoyLw@mail.gmail.com>
To: Cory Fields <lists@coryfields.com>
X-Mailer: Apple Mail (2.2098)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 23:53:45 -0000


--Apple-Mail=_5A620A44-CC81-42CD-BF23-BEAEBA4DA285
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B7CFDC83-CED9-478C-979D-E88604365C82"


--Apple-Mail=_B7CFDC83-CED9-478C-979D-E88604365C82
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

FWIW, I had worked on something similar a while back: =
https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf =
<https://github.com/CodeShark/bitcoin/blob/coinparams_new/altconf/bitcoin.=
conf>

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

> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
>=20
> I realize that it'd be opening Pandora's Box, and likely met with very
> loud and reasonable arguments about the obvious terrible implications,
> but it's at least an alternative to the current status quo of Core's
> conflation with the consensus rules. 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
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
>=20
> Cory
>=20
> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>> If the developers fail to reflect user consensus, the network will =
let us
>>> know.
>>=20
>> This is true with the caveat that there must be more than one option =
present
>> for the network to show it's preference.  If developers discourage =
anything
>> that forks from the rules enforced by Bitcoin Core, they harm the =
network's
>> ability to inform us of a failure to reflect user consensus.
>>=20
>> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>=20
>> I wouldn't go quite that far.  The reality is somewhere in the =
middle, as
>> Bryan Cheng noted in this thread:
>>=20
>> Quoting BC,
>>> Upgrading to a version of Bitcoin Core that is incompatible with =
your
>>> ideals is in no way a forced choice, as you have stated in your =
email;
>>> forks, alternative clients, or staying on an older version are all =
valid
>>> choices. If the majority of the network chooses not to endorse a =
specific
>>> change, then the majority of the network will continue to operate =
just fine
>>> without it, and properly structured consensus rules will pull the =
minority
>>> along as well.
>>=20
>> The developers propose a new version, by publishing a new release.  =
The
>> individual network nodes choose to accept or reject that.
>>=20
>> So I respectfully disagree with "core devs don't control the network" =
and
>> "core devs control the network" both.
>>=20
>> There are checks-and-balances that make the system work.  Consensus =
is most
>> strongly measured by user actions after software release.  If the =
developers
>> fail to reflect user consensus, the network will let us know.
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>=20
>> Hi Pieter,
>>=20
>> I think a core area of disagreement is this:
>>=20
>> Bitcoin Core is not running the Bitcoin economy, and its developers =
have no
>> authority to set its rules.
>>=20
>> In fact Bitcoin Core is running the Bitcoin economy, and its =
developers do
>> have the authority to set its rules. This is enforced by the reality =
of
>> ~100% market share and limited github commit access.
>>=20
>> You may not like this situation, but it is what it is. By refusing to =
make a
>> release with different rules, people who disagree are faced with only =
two
>> options:
>>=20
>> 1. Swallow it even if they hate it
>> 2. Fork the project and fork the block chain with it (XT)
>>=20
>> There are no alternatives. People who object to (2) are inherently
>> suggesting (1) is the only acceptable path, which not surprisingly, =
makes a
>> lot of people very angry.
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
>>=20
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_B7CFDC83-CED9-478C-979D-E88604365C82
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">FWIW, I had worked on something similar a while back:&nbsp;<a =
href=3D"https://github.com/CodeShark/bitcoin/blob/coinparams_new/altconf/b=
itcoin.conf" =
class=3D"">https://github.com/CodeShark/bitcoin/tree/coinparams_new/altcon=
f</a><div class=3D""><br class=3D""></div><div class=3D"">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. =
:)</div><div class=3D""><br class=3D""><div><blockquote type=3D"cite" =
class=3D""><div class=3D"">On Jul 22, 2015, at 4:42 PM, Cory Fields via =
bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D"">I'm not sure why =
Bitcoin Core and the rules and policies that it<br class=3D"">enforces =
are being conflated in this thread. There's nothing stopping<br =
class=3D"">us from adding the ability for the user to decide what their =
consensus<br class=3D"">parameters should be at runtime. In fact, that's =
already in use:<br class=3D"">./bitcoind -testnet. As mentioned in =
another thread, the chain params<br class=3D"">could even come from a =
config file that the user could edit without<br class=3D"">touching the =
code.<br class=3D""><br class=3D"">I realize that it'd be opening =
Pandora's Box, and likely met with very<br class=3D"">loud and =
reasonable arguments about the obvious terrible implications,<br =
class=3D"">but it's at least an alternative to the current status quo of =
Core's<br class=3D"">conflation with the consensus rules. The idea =
really is no different<br class=3D"">than suggesting that someone fork =
the codebase and implement their own<br class=3D"">changes, it just cuts =
out most of the work required.<br class=3D""><br class=3D"">With that in =
place, consensus changes would be more about lobbying and<br =
class=3D"">coalitions, and less about pull requests.<br class=3D""><br =
class=3D"">Cory<br class=3D""><br class=3D"">On Wed, Jul 22, 2015 at =
6:40 PM, Raystonn via bitcoin-dev<br class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br =
class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" =
class=3D"">If the developers fail to reflect user consensus, the network =
will let us<br class=3D"">know.<br class=3D""></blockquote><br =
class=3D"">This is true with the caveat that there must be more than one =
option present<br class=3D"">for the network to show it's preference. =
&nbsp;If developers discourage anything<br class=3D"">that forks from =
the rules enforced by Bitcoin Core, they harm the network's<br =
class=3D"">ability to inform us of a failure to reflect user =
consensus.<br class=3D""><br class=3D"">On 22 Jul 2015 3:31 pm, Jeff =
Garzik via bitcoin-dev<br class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br =
class=3D""><br class=3D"">I wouldn't go quite that far. &nbsp;The =
reality is somewhere in the middle, as<br class=3D"">Bryan Cheng noted =
in this thread:<br class=3D""><br class=3D"">Quoting BC,<br =
class=3D""><blockquote type=3D"cite" class=3D"">Upgrading to a version =
of Bitcoin Core that is incompatible with your<br class=3D"">ideals is =
in no way a forced choice, as you have stated in your email;<br =
class=3D"">forks, alternative clients, or staying on an older version =
are all valid<br class=3D"">choices. If the majority of the network =
chooses not to endorse a specific<br class=3D"">change, then the =
majority of the network will continue to operate just fine<br =
class=3D"">without it, and properly structured consensus rules will pull =
the minority<br class=3D"">along as well.<br class=3D""></blockquote><br =
class=3D"">The developers propose a new version, by publishing a new =
release. &nbsp;The<br class=3D"">individual network nodes choose to =
accept or reject that.<br class=3D""><br class=3D"">So I respectfully =
disagree with "core devs don't control the network" and<br =
class=3D"">"core devs control the network" both.<br class=3D""><br =
class=3D"">There are checks-and-balances that make the system work. =
&nbsp;Consensus is most<br class=3D"">strongly measured by user actions =
after software release. &nbsp;If the developers<br class=3D"">fail to =
reflect user consensus, the network will let us know.<br class=3D""><br =
class=3D""><br class=3D""><br class=3D""><br class=3D""><br class=3D""><br=
 class=3D""><br class=3D""><br class=3D""><br class=3D""><br =
class=3D""><br class=3D"">On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn =
via bitcoin-dev<br class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br =
class=3D""><br class=3D"">Hi Pieter,<br class=3D""><br class=3D"">I =
think a core area of disagreement is this:<br class=3D""><br =
class=3D"">Bitcoin Core is not running the Bitcoin economy, and its =
developers have no<br class=3D"">authority to set its rules.<br =
class=3D""><br class=3D"">In fact Bitcoin Core is running the Bitcoin =
economy, and its developers do<br class=3D"">have the authority to set =
its rules. This is enforced by the reality of<br class=3D"">~100% market =
share and limited github commit access.<br class=3D""><br class=3D"">You =
may not like this situation, but it is what it is. By refusing to make =
a<br class=3D"">release with different rules, people who disagree are =
faced with only two<br class=3D"">options:<br class=3D""><br class=3D"">1.=
 Swallow it even if they hate it<br class=3D"">2. Fork the project and =
fork the block chain with it (XT)<br class=3D""><br class=3D"">There are =
no alternatives. People who object to (2) are inherently<br =
class=3D"">suggesting (1) is the only acceptable path, which not =
surprisingly, makes a<br class=3D"">lot of people very angry.<br =
class=3D""><br =
class=3D"">_______________________________________________<br =
class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""><br class=3D""><br class=3D""><br =
class=3D"">_______________________________________________<br =
class=3D"">bitcoin-dev mailing list<br =
class=3D"">bitcoin-dev@lists.linuxfoundation.org<br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""><br =
class=3D""></blockquote>_______________________________________________<br=
 class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_B7CFDC83-CED9-478C-979D-E88604365C82--

--Apple-Mail=_5A620A44-CC81-42CD-BF23-BEAEBA4DA285
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

iQIcBAEBCgAGBQJVsC0DAAoJEJNAI64YFENU2rAQAMAJjg4Eo/xjeUgeP+B8Qt/F
gPx/RxC3DJ/NuGSrJZu0WD/BdQoeQU+1aK4vAHzsqN3c52RELaNQgY77N+QJq7tU
YIGiLikDGgRVkrCis+O76i4YH1Sr3/JR+Ao8ItnWbqm6TdciiGj0JIqnZMdXzAqD
23Rka8Vp6cpfNhPp+AhysM2SHmdJK31qr/MXJjsnGvU7H1EzPhpiZmpB7NlCbi7T
vOQLaiEko74MjmuB5NAWBqLbCwGrJkVDBim0qkZNYFpUKf9RcE9CBzyh2GP2R8ae
xrnbA2mI8Ie1HVj9P5vL8IwKLE8jvVGFkuOiO5bEoRlmrZfr5Hbo9/bZTnmcEJhg
5tpXhKmPg9iIbZW6zV5nYQrpFNnQkAfaP1KYBF2fovdVFhfllnOdudkm3pN14RHp
+xe7oHwrmPjg8Ld0fxIyLzaLquUfZ+mgPvgbhl4Sgr4gVLklbQSKEjVwBOYHP16s
Ow0ZoZyuFxyeh9yM0Mh0wL9fVu/dlF0Yx/PKTTu+fO5fOqn+MayKbH/FN+m7ngmY
9GRHXLXfRPm5NKI1uAGc9I+IP5ghk+fiC50SfgOIBpZJ1NHlL+Fv5i+sMWmq8Vsf
8yKLMpr6RROzIxmSM1w2lni8aahifjJCM6Lc2FitsNk5K6pPgiu1CYxQWJNWsTEO
s/rBu4MJ3Cc5jePtQjmg
=10pX
-----END PGP SIGNATURE-----

--Apple-Mail=_5A620A44-CC81-42CD-BF23-BEAEBA4DA285--