Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 40123267 for ; Thu, 30 Jul 2015 14:28:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 706B18F for ; Thu, 30 Jul 2015 14:28:30 +0000 (UTC) Received: by ioii16 with SMTP id i16so55310626ioi.0 for ; Thu, 30 Jul 2015 07:28:30 -0700 (PDT) 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=RBBlybTGnLt1xKeyYwZv8Is+AOcYYV+tBxY2XB8+DpM=; b=CA1u07O7fJ4AfC3GhFrVwGc/LaFUYc/ZZHdm8UK5q5rsbNn21faTsi2q+VfNwOiBOq LYwYY/GFHfdRtXJsW/K1wJSKCQn6tInNYfOlZeGj6NUX5TzyXQ5vy8jjXjccgQ3mYaW3 0P44H95EPkQ4gKVwkmY2widqLPC7AIyS/roObejdatX8IOERV2sqI1uGzwXcvtt5qMtR 6FtqCZvg0i/Hcsbyda5IK8812Xilnq/Av7CCl+qvplFEilQVB0Nvtc1ZoWROgxHgnNgf uf6295w9GCtXewu4dqipn4dCSwmk75vqjCqBFZ+ZL4geqmAUfTqxfD1cFdJYuuhB7M8a /CsA== MIME-Version: 1.0 X-Received: by 10.107.3.33 with SMTP id 33mr11157207iod.132.1438266509940; Thu, 30 Jul 2015 07:28:29 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Thu, 30 Jul 2015 07:28:29 -0700 (PDT) In-Reply-To: References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> <37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org> <55B94FAD.7040205@mail.bihthai.net> <74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com> Date: Thu, 30 Jul 2015 16:28:29 +0200 Message-ID: From: Pieter Wuille To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a113ed3a46ae2c9051c1884af X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary 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: Thu, 30 Jul 2015 14:28:31 -0000 --001a113ed3a46ae2c9051c1884af Content-Type: text/plain; charset=UTF-8 On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen wrote: > On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille > wrote: > >> Let's scale the block size gradually over time, according to >> technological growth. > > > Yes, lets do that-- that is EXACTLY what BIP101 intends to do. > Oh come on. Immediately increasing to 8 MB while miners currently don't even seem to bother validating blocks? With the added belt&suspenders reality check of miners, who won't produce > blocks too big for whatever technology they're using. > Or a future where miners are even more centralized than now, which avoids all problems relay and propagation speed has? > So what do you think the scalability road map should look like? Should we > wait to hard fork until Blockstream Elements is ready for deploying on the > main network, and then have One Grand Hardfork that introduces all the > scalability work you guys have been working on (like Segregated Witness and > Lightning)? > Lightning does not require a hard fork, except that larger blocks would be very useful for its bulk settlements. Or is the plan to avoid controversy by people voluntarily moving their > bitcoin to a sidechain where all this scaling-up innovation happens? > As I have said a dozen times now: sidechains are a mechanism for experimentation. Maybe through them we will discover technology that allows better on-chain and/or off-chain scalability, but people moving their coins to a sidechain has far worse security tradeoffs than just increasing the Bitcoin blockchain. No plan for how to scale up is the worst of all possible worlds, and the > lack of a direction or plan(s) is my main objection to the current status > quo. > Ok, here is a proposal I was working on. I'd like to have had more time, but I agree a direction/plan are needed to align expectations for the future: https://gist.github.com/sipa/c65665fc360ca7a176a6. > And any plan that requires inventing brand-new technology is going to be > riskier than scaling up what we already have and understand, which is why I > think it is worthwhile to scale up what we have IN ADDITION TO working on > great projects like Segregated Witness and Lightning. > And I think that the reason that so many people care about this suddenly is because of a fear that somehow the current block size "won't be enough". Bitcoin has utility at any block size, and perhaps more at some values for it than others. Talking about "not enough" is acknowledging that we really believe the block size should scale to demand, while it is the other way around. -- Pieter --001a113ed3a46ae2c9051c1884af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen <g= avinandresen@gmail.com> wrote:
=




<= div>As I have said a dozen times now: sidechains are a mechanism for experi= mentation. Maybe through them we will discover technology that allows bette= r on-chain and/or off-chain scalability, but people moving their coins to a= sidechain has far worse security tradeoffs than just increasing the Bitcoi= n blockchain.


Ok, here is a proposal I was working on. I'd like to have had more ti= me, but I agree a direction/plan are needed to align expectations for the f= uture:=C2=A0 = https://gist.github.com/sipa/c65665fc360ca7a176a6.

<= div class=3D"gmail_extra">

And any plan that requires in= venting brand-new technology is going to be riskier than scaling up what we= already have and understand, which is why I think it is worthwhile to scal= e up what we have IN ADDITION TO working on great projects like Segregated = Witness and Lightning.

An= d I think that the reason that so many people care about this suddenly is b= ecause of a fear that somehow the current block size "won't be eno= ugh". Bitcoin has utility at any block size, and perhaps more at some = values for it than others. Talking about "not enough" is acknowle= dging that we really believe the block size should scale to demand, while i= t is the other way around.

--
Pieter
--001a113ed3a46ae2c9051c1884af--