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 0359DB88 for ; Sat, 27 Jun 2015 11:04:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4D231121 for ; Sat, 27 Jun 2015 11:04:26 +0000 (UTC) Received: by wguu7 with SMTP id u7so106372790wgu.3 for ; Sat, 27 Jun 2015 04:04:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ROGBfUP+NV96XjLJ8x1ggFtKF2sgbIUJQJb6EVNfYN0=; b=ipKryAKP0Gqs6reMwolLzuKnR/cCIOD1yPvHnemv+cN0gBxmOYSw3QmuV7V2uY7CGn GVHdf6k9I/db1PAUoUTV9Imdw07Jti5vVqVMYIEawm2qACha3yW1/MZMhgTTI6D9lwac pntcPhA263f35b+BIrir7ClpHiZKqdN/cHrpewy8YvTrB/17X+wsGHVB0H/oAGqi4vw3 1vDZsOMtq8vbpAj2O2oxCnsQs0HJbSzCXvlnoKpEyk/kAtDSLCycShjllFQRFfZa0pNs eDiMgFvoJuvMImoBywRYJ8N8wqviNwAIBulI6BWmNsN/zytnuagKJBazLNnIqzQUYmOG n5Og== X-Gm-Message-State: ALoCoQkahALiARwmO7xJV8+uIlOmRCkAOxFkAr8DyqELepKEHpkhh+rHu5Qcx7U8RX5S6uce49uj MIME-Version: 1.0 X-Received: by 10.194.58.7 with SMTP id m7mr10860807wjq.109.1435403064636; Sat, 27 Jun 2015 04:04:24 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Sat, 27 Jun 2015 04:04:24 -0700 (PDT) In-Reply-To: <20150627102912.06E2641A3E@smtp.hushmail.com> References: <20150627074259.GA25420@amethyst.visucore.com> <20150627095501.C59B541A40@smtp.hushmail.com> <20150627100400.GC25420@amethyst.visucore.com> <20150627102912.06E2641A3E@smtp.hushmail.com> Date: Sat, 27 Jun 2015 13:04:24 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: NxtChg Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 11:04:27 -0000 On Sat, Jun 27, 2015 at 12:29 PM, NxtChg wrote: > > On 6/27/2015 at 1:04 PM, "Wladimir J. van der Laan" wrote: > >> Then you won't risk the other 'passengers' who don't consent to it. > > But you can look at it the other way: what about risking the 'passengers' when the plane suddenly doesn't fly anymore? > > Increasing block limit increases the risk of centralization, but it also keeps the current status quo of blocks not being filled, rather then risking an unknown option of hitting the limit hard. But that option is not unknown, that's the point of this thread. "Doing nothing" would require to fix the mempool to scale with the number of unconfirmed transaction. This is something that we will eventually have to fix unless the plan is to eventually remove the blocksize limit. What will happen with full blocks is that fees will likely rise and the transactions with bigger fees will get confirmed first. This is something that will eventually happen unless the blocksize limit is removed before ever being hit. What this thread is saying is that this option (the so-called "doing nothing" option, which actually requires more work than any of the current proposals for increasing the blocksize) is perfectly valid, which is in contradiction to a perceived "need to increase the blocksize limit soon". Increasing the block size is only an option, not a "need". And changing the consensus rules and forcing everybody to adapt their software to the changes is certainly not "maintaining the status quo", I'm getting tired of hearing that absurd notion.