Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 604C8305 for ; Mon, 27 Jul 2015 12:44:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.help.org (mail.help.org [70.90.2.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CBA2279 for ; Mon, 27 Jul 2015 12:44:49 +0000 (UTC) Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA ; Mon, 27 Jul 2015 08:44:40 -0400 To: bitcoin-dev@lists.linuxfoundation.org References: <20150727120829.GA27361@savin.petertodd.org> From: Milly Bitcoin Message-ID: <55B627BA.9040108@bitcoins.info> Date: Mon, 27 Jul 2015 08:44:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150727120829.GA27361@savin.petertodd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks 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, 27 Jul 2015 12:44:50 -0000 > The ugly thing is I think everyone in this process recognises the > meta-consensus nature of the debate already. Notice how Gavin Andresen's > initial blocksize posts were in the form of a non-technical blog, making > non-technical arguments to the public - not the Core dev team - in ways > not conducive to open response. A rather annoying example is Jeff > Garzik's recent efforts: a fundementally broken troll pull-req raising > the blocksize to 2MB that simply can't be merged for reasons unrelated > to the blocksize, followed by very public and loud efforts to spin a > non-issue - closing a pull-req that had no real impact on blockchain > capacity - into a broader reddit furor over a "changed" policy on > scaling. As a PR effort to the public this was fairly effective: framing > the Core dev team's actions as a change and raising the blocksize as a > default action puts the team on the defensive. As a way of building > consensus among the Core dev team, Garzik's actions are very > counterproductive. You are correct. It is also counterproductive to take cheap shots at vendors in order to garner consulting revenue. Measuring risk in a systematic way against known metrics is the way to go. Tweeting, blogging, and drama are generally counterproductive. When the issue is raised most of the developers shun the idea so until some of the developers become mature and experienced you will be left with all this teenager nonsense where everybody calls each other "trolls" on Reddit instead of engaging in real risk analysis. Russ