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 DD67EE54 for ; Fri, 18 Dec 2015 07:56:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6AF88122 for ; Fri, 18 Dec 2015 07:56:59 +0000 (UTC) Received: by mail-io0-f179.google.com with SMTP id q126so81688597iof.2 for ; Thu, 17 Dec 2015 23:56:59 -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=COCVhbTy3+d8GoE6H7F78XrhJZ6GKgzBk73zz5IUxy8=; b=Ihz0zjK97Bqz6z/xPu0bC3BaOVETn0yY8xgXQvmARJYIB6QKglWHi1MxVaAPHrmFYR 43wq/AoqgnaqRmNfDMhir80tFv3nQfnEiGLqMDaPFKf06jbtQUidctXz1tXHNQyxFf1h 2w7mUFQAAJcqf9ejDoHHfeTeaGn+JKc/wMucLQt0R8YJTmsAhRYcPSQS6awcLsi5o9KL oq2fDQ0kuIaWkjk6QNXisQlnH171+TmxtC5tj3enrfVVj08ROsO1GRg/Jg8JWomStxgB LjCQ1Sf8Cd7ri2jYScjQmKyeLVJ4AjNWTbjvpLze3b5jpEF+zuhRu49AYiwMv7ND48Jx 1lzg== MIME-Version: 1.0 X-Received: by 10.107.165.197 with SMTP id o188mr3186326ioe.132.1450425418876; Thu, 17 Dec 2015 23:56:58 -0800 (PST) Received: by 10.36.80.6 with HTTP; Thu, 17 Dec 2015 23:56:58 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Dec 2015 08:56:58 +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: Fri, 18 Dec 2015 07:57:00 -0000 On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik wrote: >> 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. > > Diverging from the satoshi block size change plan[1] and current economics > would seem to require a high level of months-ahead communication to users. I don't see any plan, but will you say the same thing when the subsidy dwindles, and mining income seems to become uncertain? It will equally be an economic change, which equally well will have been predictable, and it will equally well be treatable with a hardfork to increase the subsidy. Yes, I'm aware the argument above is a straw man, because there was clear expectation that the subsidy would go down asymptotically, and much less an expectation that the blocksize would remain fixed forever. But I am not against a block size increase hard fork. My talk on segregated witness even included proposed pursuing a hard fork at a slightly later stage. But what you're arguing for is that - despite being completely expected - blocks grew fuller, and people didn't adapt to block size pressure and a fee market, so the Core committee now needs to kick the can down the road, because we can't accept the risk of economic change. That sounds very much like a bailout to me. Again. I am not against growth, but increasing in response to fear of economic change is the wrong approach. Economic change is inevitable. > Segregated Witness does not kick the can, it solves none of the problems #1, > #3 - #8 explicitly defined and listed in email #1. > > 1) A plan of "SW + no hard fork" is gambling with ECE risk, gambling there > will be no Fee Event, because the core block size is still heavily contended > -- 100% contended at time out SW rollout. That is an assumption. I expect demand for transactions at a given feerate to stop growing at a certain contention level (and we've reached some level of contention already, with mempools not being cleared for significant amounts of time already). > SW mitigates this > - only after several months That is assuming a hard fork consensus forming, deployment, activation, ... goes faster than a softfork. > - only assuming robust adoption rates by up-layer ecosystem software, and That's not required. Everyone who individually switches to new transactions gets to do 1.75x more transactions for the same price (and at the same time gets safer contracts, better script upgradability, and more security models at their disposal), completely independent of whether anyone else in the ecosystem does the same. > - only assuming transaction volume growth is flat or sub-linear The only question is how many transactions for what price. Contention always happens at a specific feerate level anyway. > Those conditions must go as planned to fulfill "SW kicked the can" -- a lot > of if's. > > As stated, SW is orthogonal to the drift-into-uncharted-waters problem > outlined in email #1, which a short term bump does address. Both SW and a short bump (which is apparently not what BIP102 does anymore?) increase capacity available per price, and yes, they are completely orthogonal. My only disagreement is the motivation (avoiding economic change, as opposed to aiming for safe growth) and the claim that a capacity increase hardfork is easier and safe(r) to roll out quickly than sortfork SW. Apart from that, we clearly need to do both at some point. -- Pieter