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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
Return-Path: <joseph@lightning.network>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A2B831DEE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Oct 2015 20:00:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com
[209.85.220.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E205E17B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Oct 2015 20:00:41 +0000 (UTC)
Received: by padhy16 with SMTP id hy16so79122543pad.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 06 Oct 2015 13:00:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=lightning.network; s=google;
h=date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to;
bh=Ibf6vafSUFuiOUeqUWeBrkOHN9M5Hup8ryQCxWvkY/c=;
b=RsHd14E9iC0Lwoc5ebuhKI0w9xhlxw+Y7y7mT4WKjRiTdCPNGTiu2W7Atnc4JwmQMg
IY2KdhgdmotISQk5rM1dMs3kzgYVGwd18YvyRhCVP8ZuYVbLNrzzIgs44G9LguRWZd81
Lf+5I25FR0ZKx01FmcSpdRg3OMtncLenZnu8U=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:date:from:to:cc:subject:message-id:references
:mime-version:content-type:content-disposition:in-reply-to;
bh=Ibf6vafSUFuiOUeqUWeBrkOHN9M5Hup8ryQCxWvkY/c=;
b=KMi7X86EvPsOMT7vOaYaZamH2TZ9b5/CZ2zq1HntFFZ4Nhvvcv/1e6ALT2m1AG4G3a
E4g+eWXhUeRr46rOlw/yLyYW4KDf5i0W271rbSgbb0ui75Bd9nSxggVF8LqBJ5B1/boe
V9TTqKkOgipGRYqD/GqYrAoeiJ2dcGigObPQcDES+gryUS2VOUtYpwIBKTT2xT7TXqKO
2JAIe6T9IYwodOrBBnTlpkMxJTpR0K1bctuoEladSYbszI9BO5HG8MqObWiKjP51m5dC
hKflN5E6mU/+hqVKZ0uzOu8jjDFYuOuQF0Bdq9PG44zNVvPcdRamxDoNXpS3qqeHIF+V
H8Qg==
X-Gm-Message-State: ALoCoQnF5l5SzNpRmR9DRid7bSoB4aakjvKW5vbDb1Exg/6nbyhFCtmXI4QoC+epF9mBEBXhGlmr
X-Received: by 10.69.1.67 with SMTP id be3mr49584374pbd.78.1444161641685;
Tue, 06 Oct 2015 13:00:41 -0700 (PDT)
Received: from localhost (c-73-15-214-48.hsd1.ca.comcast.net. [73.15.214.48])
by smtp.gmail.com with ESMTPSA id
fm3sm32045371pbb.36.2015.10.06.13.00.40
(version=TLSv1/SSLv3 cipher=OTHER);
Tue, 06 Oct 2015 13:00:41 -0700 (PDT)
Date: Tue, 6 Oct 2015 13:00:31 -0700
From: Joseph Poon <joseph@lightning.network>
To: Peter Todd <pete@petertodd.org>
Message-ID: <20151006200031.GA4076@lightning.network>
References: <20151003143056.GA27942@muck>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151003143056.GA27942@muck>
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to
motivate the change
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: Tue, 06 Oct 2015 20:00:42 -0000
Hi Peter,
On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote:
> So we need to make the case for two main things:
>
> 1) We have applications that need a relative (instead of absolute CLTV)
Lightning network needs RCLTV for bidireciontal payment channels without
an explicit expiration date. Without a relative locktime, there is an
economic tradeoff between longer channel expiry dates due to lower fees,
and the time-value delay for non-cooperation. Due to this tradeoff,
there is a risk that people may create channels with entities which they
believe will be around in the future and act in a particular way. In
other words, it is possible that people will attach reputation as part
of their decision-making for channel creation.
> 2) Additionally to RCLTV, we need to implement this via nSequence
>
> However I don't think we've done a good job showing why we need to
> implement this feature via nSequence. BIP68 describes the new nSequence
> semantics, and gives the rational for them as being a
> "Consensus-enforced tx replacement" mechanism, with a bidirectional
> payment channel as an example of this in action. However, the
> bidirectional payment channel concept itself can be easily implemented
> with CLTV alone. There is a small drawback in that the initial
> transaction could be delayed, reducing the overall time the channel
> exists, but the protocol already assumes that transactions can be
> reliably confirmed within a day - significantly less than the proposed
> 30 days duration of the channel. That example alone I don't think
> justifies a fairly complex soft-fork that limits future upgrades; we
> need more justification.
The examples (including for Lightning Network) in BIP 112 provides a
rationale for using a relative locktime which cannot be achieved using
CLTV/hard-nLocktime alone. Without BIP 112, I agree the example in BIP
68 can also be done with nLocktime, but I think they sort of go
together?
However, there are some advantages to using some kind of relative
locktime field such as nSequence over purely a script opcode. This is
especially useful if one presumes some kind of long-term malleability
fix which does not include directly signing the TXID of the parent
transaction. It allows one to update dependent spending transactions
after-the-fact; after transactions are signed. If there are
unbroadcasted 2-of-2 multisig output transactions, where Tx1 is
confirmed on-chain and off-chain Tx2 spends from Tx1, they can elect to
spend Tx3a from the output of Tx2. Tx3a can have an nSequence value
which requires a minimum of 100 block confirmations of Tx2 to elapse
before Tx3a can be broadcast. As neither Tx2 or Tx3a have yet broadcast,
they can elect to double-spend Tx2 with a new transaction with a lower
nSequence value, e.g. Tx3b. This is important, as Tx2 will *always* be
spendable so creating new revocation rules is useful for Tx2.
I think Mark had once described the general idea is to have a similar
separation of the opcode and the actual validation of block height in
the codebase as nLockTime/OP_CLTV, as having pure validation in the
script which may make things a bit ugly.
> So, what else can the community come up with? nSequence itself exists
> because of a failed feature that turned out to not work as intended;
> it'd be a shame to make that kind of mistake again, so let's get our
> semantics and use-cases in the BIPs and documented before we deploy.
I agree. There may be some impact for future changes in Bitcoin, wrt BIP
68. For BIP 112, I think the impact could be minimal, but there may be
future interpretations of nSequence. In particular, in the long term
there may be some kind of need for some kind of "timestop" bit (to
define whether to count relative blockheight or timestopped
blockheight), which already consumes unreserved space. To account for
more than one upgrade, the next future upgrade after BIP 68 may be
implemented by taking the unused most significant bit in nSequence as
defined in BIP 68 in combination with using up a version field bit.
jl1202 had previously suggested doing this for BIP 68 itself:
e7b394187fd96bd77a1c49f7c9b7a9b2@xbt.hk
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011358.html
As-is, the only actual tradeoff made by BIP 68 is reducing range by
half. I think BIP 68 works as-is or with burning an nVersion bit today,
as it should allow for future (necessary) upgrades.
--
Joseph Poon
|
