Re: [bitcoin-dev] Bitcoin Core and hard forks

From: Eric Lombrozo <elombrozo@gmail•com>
To: Cory Fields <lists@coryfields•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Date: Wed, 22 Jul 2015 16:53:39 -0700	[thread overview]
Message-ID: <068B7F93-A1DF-4F8D-84FC-B787C5429D6A@gmail.com> (raw)
In-Reply-To: <CAApLimjMPvXHM4McB+xBrho2hktz8Rr7QZyU-Dgbgd7sFdoyLw@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 4873 bytes --]

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…but 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:
> 
> 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.
> 
> 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.
> 
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
> 
> Cory
> 
> 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.
>> 
>> 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.
>> 
>> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> 
>> I wouldn't go quite that far.  The reality is somewhere in the middle, as
>> Bryan Cheng noted in this thread:
>> 
>> 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.
>> 
>> The developers propose a new version, by publishing a new release.  The
>> individual network nodes choose to accept or reject that.
>> 
>> So I respectfully disagree with "core devs don't control the network" and
>> "core devs control the network" both.
>> 
>> 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.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> 
>> Hi Pieter,
>> 
>> I think a core area of disagreement is this:
>> 
>> Bitcoin Core is not running the Bitcoin economy, and its developers have no
>> authority to set its rules.
>> 
>> 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.
>> 
>> 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:
>> 
>> 1. Swallow it even if they hate it
>> 2. Fork the project and fork the block chain with it (XT)
>> 
>> 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.
>> 
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
>> 
>> 
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #1.2: Type: text/html, Size: 6785 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]