Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0B22B480 for ; Thu, 30 Jul 2015 14:05:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9C72F17B for ; Thu, 30 Jul 2015 14:05:36 +0000 (UTC) Received: by lagw2 with SMTP id w2so25793598lag.3 for ; Thu, 30 Jul 2015 07:05:35 -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=RB0PBnsdOkPvPvzfNp+daDJgVhdvONz0tlh4W3xLxhY=; b=ShaylUrvYIRsV1o46mVKdMjj1cPALh7LikY7qkkUhqIxJG415anP1dOFL/sobXeF49 NMNEOfSyq4vbTH4jHe6BDosyDxkd9feOj7mc527o0Gcrsm4JOv04HI9omj6CSJgLZ0Uz pgmmBWURHfW0g/5DW3R84r9G8pm+s62wVSqPCfaJePHvmXChgThkvYScqq9f4iwxsmDx 2BiySPT4ElnbSZhcwd6v14M0OcoQS5+ErV4+o5thpse07vGqjd9DdIjCAkiG83D5AH5R t4ShYzGmV85+ps+/Isq2xiu7B+Szss7nmSYCl4WE611N6+X/P5HqFEED3Un9zfLxp9A8 X4LA== MIME-Version: 1.0 X-Received: by 10.152.22.99 with SMTP id c3mr45491900laf.32.1438265134872; Thu, 30 Jul 2015 07:05:34 -0700 (PDT) Received: by 10.25.18.228 with HTTP; Thu, 30 Jul 2015 07:05:34 -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 10:05:34 -0400 Message-ID: From: Gavin Andresen To: Pieter Wuille Content-Type: multipart/alternative; boundary=089e0158b6c074ff81051c1832c4 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:05:50 -0000 --089e0158b6c074ff81051c1832c4 Content-Type: text/plain; charset=UTF-8 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. With the added belt&suspenders reality check of miners, who won't produce blocks too big for whatever technology they're using. ------- 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)? Or is the plan to avoid controversy by people voluntarily moving their bitcoin to a sidechain where all this scaling-up innovation happens? 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. 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. -- -- Gavin Andresen --089e0158b6c074ff81051c1832c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <pieter.wuille@gmail.com<= /a>> 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 d= o.

Wit= h the added belt&suspenders reality check of miners, who won't prod= uce blocks too big for whatever technology they're using.

=
-------

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 (lik= e Segregated Witness and Lightning)?

Or is the plan to avoid controversy by peopl= e voluntarily moving their bitcoin to a sidechain where all this scaling-up= innovation happens?

No plan for how to scale up is the worst of all possible w= orlds, and the lack of a direction or plan(s) is my main objection to the c= urrent status quo.

= And any plan that requires inventing brand-new technology is going to be ri= skier than scaling up what we already have and understand, which is why I t= hink it is worthwhile to scale up what we have IN ADDITION TO working on gr= eat projects like Segregated Witness and Lightning.

-- =
--
Gavin Andresen

--089e0158b6c074ff81051c1832c4--