MIME-Version: 1.0
In-Reply-To: <20150818094612.2344943128@smtp.hushmail.com>
References: <20150817100918.BD1F343128@smtp.hushmail.com>
	<1439815244.89850.YahooMailBasic@web173102.mail.ir2.yahoo.com>
	<20150817133438.DDD4243128@smtp.hushmail.com>
	<CE3B7411-2863-4D6B-85B0-4F28D4D7F391@gmail.com>
	<20150818094612.2344943128@smtp.hushmail.com>
Date: Wed, 19 Aug 2015 11:47:22 +0200
Message-ID: <CABm2gDp1h_iQKkyS5MUE0R85_DJcCZBKwop1731CbLR-AGOX1A@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: NxtChg <nxtchg@hush.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Precedence: list

On Tue, Aug 18, 2015 at 11:46 AM, NxtChg via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Eric,
>
>>FWIW...
>
> These are all good points and I agree with most of them. Yes, the block size debate is a lucky historical accident, which makes it easier for XT to pull off the split, but that's not the point.
>
> The point is, the split _must_ happen because the centralized governance of Bitcoin became a bigger problem than the risks of a fork or larger blocks.
>
> You cannot govern a decentralized currency with a centralized entity.

Nobody has complained about Bitcoin-XT (nor libbitcoin, nor libcoin,
nor against any other of the multiple alternative implementations of
bitcoin).
Please, understand that people are worried about the schism hardfork,
not about the software fork (which happened long ago when some of
Hearn's changes were reverted due to security concerns). If Bitcoin-XT
didn't had a schism hardfork, nobody would be calling it "an altcoin".
For consensus rules we use "the implementation is the specification"
as a principle for multiple reasons. By separating libconsensus (a
work in progress [far less progress than I would like]) we remove
Bitcoin Core's privileged position: Bitcoin Core wouldn't be "the
specification of the consensus rules" anymore, just a reference
implementation that is not "consensus-safer" compared to alternative
implementations (since they can use libconsensus directly [or a
software fork of it in the case of a reasonable schism hardfork]).

> That's why we shouldn't fear hard forks - they are the new reality, and if we cannot set up a reliable process for them to happen then there _is_ no decentralized Bitcoin and we all might as well just give up and go home.

We have many reasons to fear schism hardforks (
https://github.com/jtimon/bips/blob/bip-forks/bip-0099.mediawiki#Schism1_hardforks
), even though they may be unavoidable at some point (ie for an
ASIC-reset hardfork).