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 06EA8C74 for ; Wed, 16 Dec 2015 18:34:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 97941116 for ; Wed, 16 Dec 2015 18:34:39 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id to4so77803553igc.0 for ; Wed, 16 Dec 2015 10:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2W8l02HAf/xHUlgxWF5t9t4GJgfI0upaIwIVgz84FLk=; b=D8kC/hWYVZ3Zusg2Id+jGAujnmS2NYxAKUosnKPSzsZVSXZ0zSKv93sUNWf00HR9FS aMwCeBcR0HxLalTPTqU+6cJ4JrgxPbmaxoDS+4yyEy77Zy1jmy7qOgNgFiJpsY92HFnZ gkgJanBG8bykC55bI/mc7yAlXkI7KP97XbAYZkSfjqmpx0C0ksxkbpEobAUvcpF0NIZP pC1m7v4tP8H7Grcixxes3wx7TfPkyePavQOX+F9smD/nA/yywN2v49bVSM2AIK052OSb elqJ3lHdi3Y4TNCdeu/daknXLN96FhQw5GrI++hRBaU31IIPOctAbFL/zpRiqzQnQKNP nLOw== MIME-Version: 1.0 X-Received: by 10.50.161.33 with SMTP id xp1mr12120017igb.4.1450290872813; Wed, 16 Dec 2015 10:34:32 -0800 (PST) Received: by 10.36.80.6 with HTTP; Wed, 16 Dec 2015 10:34:32 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Dec 2015 19:34:32 +0100 Message-ID: From: Pieter Wuille To: Jeff Garzik Content-Type: text/plain; charset=UTF-8 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 development mailing list Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard 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, 16 Dec 2015 18:34:40 -0000 On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev wrote: > 2) If block size stays at 1M, the Bitcoin Core developer team should sign a > collective note stating their desire to transition to a new economic policy, > that of "healthy fee market" and strongly urge users to examine their fee > policies, wallet software, transaction volumes and other possible User > impacting outcomes. You present this as if the Bitcoin Core development team is in charge of deciding the network consensus rules, and is responsible for making changes to it in order to satisfy economic demand. If that is the case, Bitcoin has failed, in my opinion. What the Bitcoin Core team should do, in my opinion, is merge any consensus change that is uncontroversial. We can certainly - individually or not - propose solutions, and express opinions, but as far as maintainers of the software goes our responsibility is keeping the system running, and risking either a fork or establishing ourselves as the de-facto central bank that can make any change to the system would greatly undermine the system's value. Hard forking changes require that ultimately every participant in the system adopts the new rules. I find it immoral and dangerous to merge such a change without extremely widespread agreement. I am personally fine with a short-term small block size bump to kick the can down the road if that is what the ecosystem desires, but I can only agree with merging it in Core if I'm convinced that there is no strong opposition to it from others. Soft forks on the other hand only require a majority of miners to accept them, and everyone else can upgrade at their leisure or not at all. Yes, old full nodes after a soft fork are not able to fully validate the rules new miners enforce anymore, but they do still verify the rules that their operators opted to enforce. Furthermore, they can't be prevented. For that reason, I've proposed, and am working hard, on an approach that includes Segregated Witness as a first step. It shows the ecosystem that something is being done, it kicks the can down the road, it solves/issues half a dozen other issues at the same time, and it does not require the degree of certainty needed for a hardfork. -- Pieter