summaryrefslogtreecommitdiff
path: root/36/64c8e736991d6abf29090d9281b5ca9738714c
blob: c065f0384fc7a009f275a2bfb09a2df0e344b5d8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DDBEC482
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 30 Jul 2015 15:36:14 +0000 (UTC)
Received: by wicmv11 with SMTP id mv11so26025962wic.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <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
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<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.