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 882D7323 for ; Sat, 27 Jun 2015 07:43:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E72C718E for ; Sat, 27 Jun 2015 07:43:01 +0000 (UTC) Received: by wicgi11 with SMTP id gi11so34137348wic.0 for ; Sat, 27 Jun 2015 00:43:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Jz89Ua1l1brGhYhaF3r9MVw6CWCAqLR1S4bwuVxd5G0=; b=yjupWgecTi+e/ozyuFVa4HY0KAqvQJojiUsIObKR/NJfH3sUyYtEknoWIdCCAHtt7H vTibeaqanCcSZ3mXAgGL9XfHmfECFIbsmoGrRQNU8B/+vmuR4wJLyCYlbNg+OlACSNNO WLhRDHpnrqP+03oLa3Ti8MXopBz8gZ/4SpuFBxyOemFUFtWJzgajTrx2pvQ7Hn4rUc+Y nl5nvjMDaDMBv/jbhhZpPk9ykUs45n5yqARJlR9m45iDvCIDSJEx3rak+2DTPvpo9ZPE votaflvCOqHa7FGsXNRSaxj0MMVMZkZ7bUo0WfXWafVlZj5mh3OI4dC2NGWmz/cNzn5p GYSQ== X-Received: by 10.180.186.99 with SMTP id fj3mr3938460wic.10.1435390980464; Sat, 27 Jun 2015 00:43:00 -0700 (PDT) Received: from amethyst.visucore.com (dhcp-089-098-228-253.chello.nl. [89.98.228.253]) by mx.google.com with ESMTPSA id k16sm46452969wjr.7.2015.06.27.00.42.58 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 27 Jun 2015 00:42:59 -0700 (PDT) Date: Sat, 27 Jun 2015 09:43:00 +0200 From: "Wladimir J. van der Laan" To: Pieter Wuille Message-ID: <20150627074259.GA25420@amethyst.visucore.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] The need for larger blocks 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: Sat, 27 Jun 2015 07:43:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Fri, Jun 26, 2015 at 04:09:18PM +0200, Pieter Wuille wrote: > People say that larger blocks are necessary. In the long term, I agree - in > the sense that systems that do not evolve tend to be replaced by other > systems. This evolution can come in terms of layers on top of Bitcoin's > blockchain, in terms of the technology underlying various aspects of the > blockchain itself, and also in the scale that this technology supports. > > I do, however, fundamentally disagree that a fear for a change in economics > should be considered to necessitate larger blocks. If it is, and there is > consensus that we should adapt to it, then there is effectively no limit > going forward. This is similar to how Congress voting to increase the > copyright term retroactively from time to time is really no different from > having an infinite copyright term in the first place. This scares me. Fully agree Pieter. Couldn't have stated it better. It has been disappointing and scary to see political pressure tactics being used to change a distributed consensus system. By using the system everyone agreed on one set of consensus rules, that was the "social contract" of Bitcoin. To me, the consensus rules are more like rules of physics than laws. They cannot be changed willy-nilly according to needs of some groups, much less than lower gravity can be legislated to help the airline industry. It is shocking to hear wide misunderstanding that it is supposedly 'the developers' that decide on such changes. As if this is merely a private top-down project. No, the point was that this can continue without any kind of central guidance, with expected stability. As a developer I work on improving the technical aspects and fixing bugs, not on 'governing' it. By expecting a few developers to make controversial decisions you are breaking the expectations, as well as making life dangerous for those developers. I'll jump ship before being forced to merge an even remotely controversial hardfork. The stressful conditions of last weeks have thus made me hostile toward the idea of hardforks. At least to hardforks that make politically loaded changes. In this case further centralization to well-connected geographic locales by increasing network bandwidth requirements. Resiliency and decentralization are the key aspects. I would not want to risk breaking the system, or at least wildly changing its properties and applicability out of perceived necessity, and fear. Wladimir -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCgAGBQJVjlOMAAoJEHSBCwEjRsmmveAH+wWN6j+0LsLibl2XWs3hxs64 nOT63JMNEIYzSsxZkEkzU4AWsdPG8TWXeaYhaR5rd7pXspFHHFYpPNxyOAWB4nY9 yS9eI4JRkOLtZY+rulFppkvnpggL82MFcT5rMNom+S1+EKE6C1NFqXl+OzZqatWL pysza7ZHg/d3hKWkm/JtlfTYTOgrxFIX6INghfQiOl2hEyXE5iZF8+CRnZQA4dG7 jr/Jn2H4EzkUF8SDYVkIYsX+hPL5ib9mMm12ZXH8M8lFkdwweJCwbA7tVtNoalG3 dzHb/8rotlqiDTNuLIlB7TE4maivcr2cXVKTfry6HBRJvNf0cD3oP67vCQj6iis= =pipo -----END PGP SIGNATURE-----