MIME-Version: 1.0
In-Reply-To: <CABsx9T1Wgf8u-ZKXmiRhQwdJNkDJg9RL_o2j2cWxP-6nKmxS2Q@mail.gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
	<CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com>
	<D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
	<CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
	<37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org>
	<CAAS2fgSaRqxi3X0J3F05nA-tyRRikY1whkpAOuGJJpFSAR017w@mail.gmail.com>
	<COL131-DS222F0D512C6A5B47BF62C2CD8C0@phx.gbl>
	<55B94FAD.7040205@mail.bihthai.net>
	<COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl>
	<CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
	<CAEX2NSc6FXsDLEpRq7YOxQErpBxS7tW8Afk-T9VUyeb2qS2brQ@mail.gmail.com>
	<74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com>
	<F7601CF2-2B89-4D11-8B56-8FFF63A4063C@gmail.com>
	<CAPg+sBjsQPUZEj0LFHBWuM4E+4SsUu4C9fcb7OJX4SC4+omvPQ@mail.gmail.com>
	<CABsx9T1Wgf8u-ZKXmiRhQwdJNkDJg9RL_o2j2cWxP-6nKmxS2Q@mail.gmail.com>
Date: Thu, 30 Jul 2015 17:36:13 +0200
Message-ID: <CABm2gDo=PjdOJtXQ+T2UNXubreSZXigEnRFRwhd-nAGvWXs+AQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
	temporary
Precedence: list

On Thu, Jul 30, 2015 at 4:05 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Jul 30, 2015 at 8:50 AM, Pieter Wuille <pieter.wuille@gmail.com>
> 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.