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
110
111
112
113
114
115
116
117
118
119
|
Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2234D1E24
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 18:15:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B2ABC18D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 18:15:05 +0000 (UTC)
Received: from mail-io0-f176.google.com ([209.85.223.176]) by
mrelay.perfora.net (mreueus002) with ESMTPSA (Nemesis) id
0MS3pM-1a68qQ2fr0-00TFKa for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 20:15:04 +0200
Received: by ioii196 with SMTP id i196so57513538ioi.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Sep 2015 11:15:03 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.15.27 with SMTP id x27mr6498356ioi.51.1443636903964;
Wed, 30 Sep 2015 11:15:03 -0700 (PDT)
Received: by 10.50.32.164 with HTTP; Wed, 30 Sep 2015 11:15:03 -0700 (PDT)
In-Reply-To: <CA+w+GKRKGS=KZrLtiW8Zbn4EQH_TELfQR+TfrADCMXLR22Q+tw@mail.gmail.com>
References: <20150927185031.GA20599@savin.petertodd.org>
<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
<CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
<CA+w+GKRKGS=KZrLtiW8Zbn4EQH_TELfQR+TfrADCMXLR22Q+tw@mail.gmail.com>
Date: Wed, 30 Sep 2015 14:15:03 -0400
Message-ID: <CALqxMTGqGbJLFNerw+1goR2g54+vn=ECgzx++_oRznrzJWfd4g@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:PX3SA1xlyr/HIUU64Oh6Qj1DTkgWg/zIq7Mb0qGhvk67SP7Om9U
iSV3nNGyi+ZVhsoFGkF0CS9G75mNBfGkR6/ULBBglju7qH+qv58/QO06uh0KbX8MFTZTkep
6Kf24MNu/PIrlB9E6JTj7vb9W8ouxP8BQQyNx6ivMiyWWd2yKtGx0tYmSozIyfql15qUtdF
GlZCH4w9yBQGlkvpY9m8Q==
X-UI-Out-Filterresults: notjunk:1;V01:K0:xiSRVqB2Q3k=:NpTkvh7STCG84PGcN6XAyN
ibo+OrAcdKeb5isI5yacoB51PgbrB6UUWluU+dX7TV6xcUrCYmVZ3KK6GaFZpK9uqg9tJVWVe
WND+DBWt0lGx1fGVoHmoem8WhOxsUdjgK5mNf3CA1Ci6Be9PMXw/tQPHLsgp5VcLWKHUAZkvR
OPO0JQDpp4PWcL7/jCiQcVrm3OfcFP+11JTVyfsOOfI0O2RuNUGZJkUvo5C6P4HYOJUVEexhQ
NmS8DfWIUCH+B0JYE9QUMUFCe4F/fhwLHHRvOkozL8VA+U/RKYmAQuux/gDU3a8saITUfZOaX
gr0V0XHf7bS11+aXnNrOC39oDbQl1/1Rw6I361MU34fCEzwcehdI4bD2XINioHV46ZnuQqADA
RCko4VAR9JB7JXmUUXua/FaOX86monqZBAC94k4W8JieccMwbflGdDp1bpn2XJ8rgMmXVwamZ
4Zbr/bPukoTvilaUUW8pGJrSaXeZdf3bNg5Ub2lpFEuLlhRSqPxs0viE1EkSWKGuqF0uD5jWG
Dw4bkNRwGx6Pcx5INEMMm2lhHWw4l5b6HiKAW7PYolVIV4zi1mH/Pr9tzJmgnDKtQx0AdnI8M
JRMXQn89sgc+jNnhcYXNCQIRVCxe8mgDTVmKWrps+XIX1L8Rguj4lkE99ej9QgTxosNV1haye
p/qt4ItzI8xiAweT4Gx1NS8A0JSmxFx+kLlRZoACi6CXxQA==
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
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] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
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: Wed, 30 Sep 2015 18:15:06 -0000
On 30 September 2015 at 13:11, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Have I missed a proposal to change BIP101 to be a real hardfork
>
> There's no such thing as a "real" hard fork - don't try and move the goal
> posts. SPV clients do not need any changes to do the right thing with BIP
> 101, they will follow the new chain automatically, so it needs no changes.
BIP101 is a hybrid: in some ways it is a hard-fork and in other ways
it is a soft-fork. It is a hard-fork to full-nodes, but also a
soft-fork to SPV clients, as by definition the SPV miners are having
changes made whether they approve or not as they are not even aware of
the change.
> To repeat: CLTV does not have consensus at the moment.
I think people are saying CLTV is long discussed and does have consensus.
> Several people have asked several times now: given the very real and widely
> acknowledged downsides that come with a soft fork, what is the specific
> benefit to end users of doing them?
>
> Until that question is answered to my satisfaction I continue to object to
> this BIP on the grounds that the deployment creates financial risk
> unnecessarily.
Let's not conflate CLTV with a discussion about future possible
deployment methods. Forks are an interesting but different topic.
Soft-forks have a lot of mileage on them at this point, hard-forks do
not, and are anyway inherently higher riskier, even ignoring our lack
of practical experience with planned hard-forks.
With a soft-fork, while it's clear there is a temporary security model
reduction for SPV nodes (and non-upgraded full nodes) in the period
before they upgrade, this is preferable to the risks of a system-wide
coordinated hard-fork upgrade. There is some limit if the complexity
of soft-forking a feature is quite complicated (eg one could argue
that with soft-fork extension-blocks vs hard-fork method of increasing
block-size for example). So the balance, which I think is easily met
with CLTV, is that soft-fork is simple-enough technically and the
feature is entirely non-controversial and additive functionality
improvement without downside or reason for dissent.
To my view this is an answer to your question "what is the specific
benefit to end users of doing [soft-forks]" -- it is a lower risk, and
therefore faster way to deploy non-controversial (additive) changes.
Given the CLTV is useful for improving lightning efficiency this is
good for improving Bitcoin's scalability.
Adam
|
