path: root/61/1305ec3ea3ca0eead3e7921ab943645fc1a919

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 A32A1416
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 00:13:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com
	[209.85.192.175])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 12AF8185
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 00:13:46 +0000 (UTC)
Received: by pdrg1 with SMTP id g1so146564745pdr.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 17:13:45 -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=xucCpZh5hMSUZeesgNAvsGLXj5Cnrz4Loxr7XETIeu8=;
	b=F0oa5zmnuc0E0armgRWB9nBJmMKXcTqOUoj5GDLryEJwf8pq+mt+I9Ku4E7O7TgSN6
	BcQjF6aLBwL3e7hI509IQT79Hf48MX3ot9YBy7EmIGhF+Dypru8ATfachwLr+qjxHhDX
	Zb+3JFNqCNRmxzxpqXJc1OKJDRFywR24OqSQa7JY+livXkGlGZnWwzgwGZgpQRrFcW3C
	gCp9XOm7YeQan1eWpsAyRnCAYliragJ/zJzx43RVMPd3vHT7c+WCJW2D/klIsrrmsrSH
	lC9BFyjWIBKpe4v1a7tCvsvKJzdAz1Lp6YvPjzW3arHcXBeKsdSVqX5qRR5iw9Od9qWM
	dfWg==
X-Received: by 10.66.62.194 with SMTP id a2mr11954984pas.67.1437610425749;
	Wed, 22 Jul 2015 17:13:45 -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
	fy5sm5310613pdb.93.2015.07.22.17.13.43
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Wed, 22 Jul 2015 17:13:44 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_725C1316-2FCC-41BC-A60D-A372E13197FC";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CAApLimjiF6zH8GAbTajMTW6p8GtXCGRa5GcV+N2z1soY5fQy+A@mail.gmail.com>
Date: Wed, 22 Jul 2015 17:13:42 -0700
Message-Id: <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>
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,
	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: Thu, 23 Jul 2015 00:13:47 -0000


--Apple-Mail=_725C1316-2FCC-41BC-A60D-A372E13197FC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


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

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.

> 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 =
parameter 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 =
first securing overwhelming (near unanimous) consensus=E2=80=A6or =
without having yet built a mechanism that can merge divergent chains =
gracefully.

> Cory
>=20
>> 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:
>>=20
>> If the developers fail to reflect user consensus, the network will =
let us
>> know.
>>=20
>>=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,
>>=20
>> 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
>>=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
>>=20
>>=20


--Apple-Mail=_725C1316-2FCC-41BC-A60D-A372E13197FC
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

iQIcBAEBCgAGBQJVsDG2AAoJEJNAI64YFENUT2EQAJfsqnfoHh1sq67w7CJ/K/Bl
BJ8qT9ZUF/IZCFXPMIRbJsGJtDdrbQg8FGsrLDFByH2xMlmOKqarTx/R6wnKJu40
Oa56VmmL9CrNcTFtv61BBphQWVGUYd9Rf8hFc4IQo1/d+gmN0RMHaEgQqxOQTJqr
424Oxw0RbPW/gsBP7UM5098moxbvjhZFxZZwKlTL3tKEjMYAlsmloYTDqYg1FW7e
Lk97RkTWw2E5NjksO32+Mn6LVBii11UKSTlqJRaniOEH6KXsWOXaBKleAmEpx9kJ
tdadUyjrd37qjtx8JD5eyzNYk6nSr9I3RXfLFYYy1++6QYlq/zKcOGPgTaBA0HTt
mgJaAj6B7Sj39iJnaO53uWRplECiZ3Oesqjbo0+w/rUvcLZZNk+EUJksp3I9fYOR
j+Is6SMxd/76F3Q/rkVbBzQL0YN5Xk/HaRowLdK+fshmcFH174l4nazEbI+GFBIq
g0g3UdYLpfGMgg/GLBX4WUiQjezkTt8gjdlAj018XOlpkeeZYuJ+sxgbYEpr41gO
mRJpV+LD/evQsOeIgF+cPaAmtRcYWXRtetzoVC6ZXhKMw2EfqYEKjs8p5muYRVri
dEbsEwC3KHCm9AaV3Cjseg0c7Ln9oDU/1PnSlQ7ONqGetj5owMiJ0tcIw3ofzgqL
HHf2DifWsJjBEmLVxlC7
=CQ3d
-----END PGP SIGNATURE-----

--Apple-Mail=_725C1316-2FCC-41BC-A60D-A372E13197FC--