From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 60F1225A for ; Wed, 19 Aug 2015 09:47:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 82EE2F2 for ; Wed, 19 Aug 2015 09:47:24 +0000 (UTC) Received: by lagz9 with SMTP id z9so116030707lag.3 for ; Wed, 19 Aug 2015 02:47:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NqvshBxTiNpX/zoiVcmFJ7gOpsXEl7/47SBuFSTRqro=; b=DG4Kq9y8FNiqFKEVULXhqW3IxYcymEAdWDTAtduLGMEhN13c/lp2VCo3xPQpBoa0aV mr4aGyEgLXcw9cQgbA3W5WcmsS6BmPzrfxJu3dZi1u/hTGeoM5ez9hFiQuT6Vv/MZOht pPNjihJRWAlNekPu+AdU8uevWkNseYISXtF9UN1Xe0CWJ6eLAFiCQFjxqNP5dbyqhCmT B43Q1av+tZTW/UxJ3uyfvaeMxyRxhvdbTdihUNQVsoLZkVy6tEiYhX28crHTLOpK8Lmo jE7yOPYkS5e+X0jP6R0mLsGjEpdxBqaheQ5/tqlTTbsclEjpiuGNoM/Kofq9rFFIlKff kz9A== X-Gm-Message-State: ALoCoQnpmiXtBkAwger80IpsXbuW7piI6qDf/BSzeMyWaN/EjfG2cHV6oWHn1S/Js47tjs0chkSU MIME-Version: 1.0 X-Received: by 10.153.7.66 with SMTP id da2mr10239399lad.117.1439977643015; Wed, 19 Aug 2015 02:47:23 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Wed, 19 Aug 2015 02:47:22 -0700 (PDT) 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> <20150818094612.2344943128@smtp.hushmail.com> Date: Wed, 19 Aug 2015 11:47:22 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: NxtChg Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 09:47:25 -0000 On Tue, Aug 18, 2015 at 11:46 AM, NxtChg via bitcoin-dev 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).