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 2C36914DA for ; Tue, 1 Sep 2015 20:08:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from cock.li (cock.li [176.9.0.140]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C101E182 for ; Tue, 1 Sep 2015 20:08:39 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 01 Sep 2015 20:08:37 +0000 From: Monarch To: Eric Voskuil In-Reply-To: <55E5F05E.9060409@voskuil.org> References: "\"\\\"\\\\\\\"<602b978abcedd92fbed85f305d9d7bfe@cock.li> <55E4B8C9.5030606@openbitcoinprivacyproject.org> \\\" \\\" <5A3D7824-F1E3-421B-A32A-0EF21DD215BD@gmx.com> <5b7c2ba6e785e59595c2ee9a4596f097@cock.li> <55E5CB5C.2020405@conformal.com>" <67820b46cdcb549aac36b9496b19b6b0@cock.li>" <55E5F05E.9060409@voskuil.org> Message-ID: X-Sender: monarch@cock.li User-Agent: Roundcube Webmail/0.9.5 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD 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, libbitcoin@lists.dyne.org Subject: Re: [bitcoin-dev] Your Gmaxwell exchange 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: Tue, 01 Sep 2015 20:08:40 -0000 On 2015-09-01 18:37, Eric Voskuil wrote: > Whether intended or otherwise this is an attack on the idea of > decentralized bitcoin development. The option to fork or roll your own > is open source, not decentralization. Decentralization requires > *actually doing so*. One step down that path, even for a fork, is a > major commitment. > > Common consensus check code is now available in several bitcoin > implementations. The claim that this is outrageously difficult is > misleading. It's just engineering work that needs to get done if > Bitcoin > is to survive. > There's no requirement for there to be multiple interpretations of the consensus code, this is why libbitcoinconsensus exists. Why do you think Bitcoins survival is predicated on reimplementation? > These are issues that affect the satoshi client as much as other > implementations, and therefore don't support your premise. > I'm aware that these problems apply to Bitcoin Core.