Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D40FB1C52 for ; Mon, 5 Oct 2015 16:53:57 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 843861B2 for ; Mon, 5 Oct 2015 16:53:57 +0000 (UTC) Received: from ishibashi.localnet (adsl-98-70-226-45.gnv.bellsouth.net [98.70.226.45]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 6B55410836EC; Mon, 5 Oct 2015 16:51:59 +0000 (UTC) X-Hashcash: 1:25:151005:bitcoin-dev@lists.linuxfoundation.org::7wn36e3AhPC9UiUe:z3xq X-Hashcash: 1:25:151005:sergio.d.lerner@gmail.com::NONiME=o+3WRuiMb:du060 From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Sergio Demian Lerner Date: Mon, 5 Oct 2015 16:51:57 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.6-gentoo; KDE/4.14.8; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201510051651.58728.luke@dashjr.org> X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,RCVD_IN_SBL, T_RP_MATCHES_RCVD autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate 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: Mon, 05 Oct 2015 16:53:57 -0000 On Monday, October 05, 2015 3:56:33 PM Sergio Demian Lerner via bitcoin-dev wrote: > Some of the people on this mailing list are blindly discussing the > technicalities of a soft/hard fork without realizing that is not Mike's > main intention. At least I perceive (and maybe others too) something else > is happening. > > Let me try to clarify: the discussion has nothing to do with technical > arguments. I generally like more hard forks than soft forks (but I won't > explain why because this is not a technical thread), but for CLTV this is > quite irrelevant (but I won't explain why..), and I want CLTV to be > deployed asap. > > Mike's intention is to criticize the informal governance model of Bitcoin > Core development and he has strategically pushed the discussion to a > dead-end where the group either: > > 1) ignores him, which is against the established criteria that all > technical objections coming from anyone must be addressed until that person > agrees, so that a change can be uncontroversial. If the group moves forward > with the change, then the "uncontroversial" criteria is violated and then > credibility is lost. So a new governance model would be required for which > the change is within the established rules. > > 2) respond to his technical objections one after the other, on never ending > threads, bringing the project to a standstill. > > As I don't want 2) to happen, then 1) must happen, which is what Mike > wants. I have nothing for or against Mike personally. I just think Mike > Hearn has won this battle. But having a more formal decision making process > may not be too bad for Bitcoin, maybe it can actually be good. This discussion is *necessarily* about soft/hard fork technicalities, as there is no governance in Bitcoin beyond the *nature* of the consensus protocol. The "established criteria" you mention is merely the nature of hardforks. It is completely inapplicable and has never been the necessary case for softforks, which can be enforced by merely a miner majority. Luke