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 DDBEC482 for ; Thu, 30 Jul 2015 15:36:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B2EA413D for ; Thu, 30 Jul 2015 15:36:14 +0000 (UTC) Received: by wicmv11 with SMTP id mv11so26025962wic.0 for ; Thu, 30 Jul 2015 08:36:13 -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=111hROVqOrNV+rNOhhaEGjtQ560vvhVOfrmRhTpeHZE=; b=HKly9LxF5mIe2b8uFrqiKix0+9DDYgWcwvwFZXLqwx9UaejhyacK+Hd4mIzV/TwH7V PI542MAr/kajCrEeoTpdqJE3X7Zq0+/gUfokO+ZU6pOskFsbYOj8wYj5MhrTQD7EVyZa bb60YCBGKXr5hd81Np8NXFgfVUW66NGpYjlkmR6UY11kUFXukgQvoGdxi4xzsMpAIbdo acQn/DIUNKPB5sJBKReFZUwJuKK1M/Uz8aucKNaDNlTSw7wyOLxCZUvSCepzjCUvBy33 Mz+gSPbQwLj1lj3Wfg8ccbvu+WMlzr27+X0422NWR+3yYVHkY/oeiiQ0/TlBwubZD5XK 0DWQ== X-Gm-Message-State: ALoCoQnV1M2hm9oGbq79PSGIppxNRTwPyOtLLglNyRDtKOSPNPo1wzCdlAZeeUttW6xevX+TKwVQ MIME-Version: 1.0 X-Received: by 10.194.238.39 with SMTP id vh7mr16733317wjc.109.1438270573391; Thu, 30 Jul 2015 08:36:13 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 08:36:13 -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 17:36:13 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Gavin Andresen 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 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 15:36:16 -0000 On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen via bitcoin-dev wrote: > On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille > 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)? Apparently lightning doesn't require Segregated Witnesses: cltv and rcltv may be enough (although I'm not up to date to the latest designs). I definitely don't think we should wait to have SW ready to be deployable in Bitcoin to have other hardforks. I think we should have an uncontroversial hardfork as soon as possible, if anything, to set a precedent and show the world that hardforks are possible in Bitcoin, see https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#code > Or is the plan to avoid controversy by people voluntarily moving their > bitcoin to a sidechain where all this scaling-up innovation happens? Any scaling up innovation that happens in sidechains can be adopted by Bitcoin too. In fact, some of those changes (like op_maturity/rcltv/scv) are needed in Bitcoin for a fully p2p Bitcoin sidechain to be even possible. I really think lightning should be possible in Bitcoin main (and not just sidechains) as soon as possible. > 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. Not necessarily. How are older payment channels designs (different from lightning) that don't even require cltv riskier than a hardfork? In any case, yes, both things are kind of orthogonal and we can work on both (and more) at the same time.