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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 064A318A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 3 Oct 2015 14:31:07 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149056.authsmtp.com (outmail149056.authsmtp.com
[62.13.149.56])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 56DAC24C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 3 Oct 2015 14:31:06 +0000 (UTC)
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t93EV4rD008413
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 3 Oct 2015 15:31:05 +0100 (BST)
Received: from muck (port-87-193-173-182.static.qsc.de [87.193.173.182])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t93EV1u3038945
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 3 Oct 2015 15:31:03 +0100 (BST)
Date: Sat, 3 Oct 2015 16:30:56 +0200
From: Peter Todd <pete@petertodd.org>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20151003143056.GA27942@muck>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS"
Content-Disposition: inline
X-Server-Quench: 60192dfe-69db-11e5-b39a-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktdYVUxDEF1
UkhIR0JTEQ9rABYB BVAWVQdzfgZYeXlz e0dqXG9eVENldAg5
S00hc2xDZmdjYGkb VQ5bcQJXPgVKfxZH PgYqSXUENTcaZ3s1
Qko5ZGE4eG0HcnkE GghUcF4bHlAgPhMX ZCsvJAgCO2YoeQgJ
DjIXYhtUI0tZNEg/ PRMkXkgVewIJBwZX BExWSDNeb1wGWys1
BB9XFVIeHXVWQS5a DRBA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 87.193.173.182/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
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
Subject: [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: Sat, 03 Oct 2015 14:31:07 -0000
--qMm9M+Fa2AknHoGS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics,
which can be summarized conceptually as a relative CHECKLOCKTIMEVERIFY.
However, CSV does define behavior for the previously undefined nSequence
field, which is the only "free-form" field we currently have in the
transaction serialization format that can be used for future upgrades -
we should justify this new behavior carefully as it limits our options
in the future. Adding new fields to the serialization format is very
difficult, due to the very broad system-wide impact of the hard-fork
required to do so.
So we need to make the case for two main things:
1) We have applications that need a relative (instead of absolute CLTV)
2) Additionally to RCLTV, we need to implement this via nSequence
To show we need RCLTV BIP112 provides the example "Escrow with Timeout",
which is a need that was brought up by GreenAddress, among others; I
don't think we have an issue there, though getting more examples would
be a good thing. (the CLTV BIP describes seven use cases, and one
additional future use-case)
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.
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.
--=20
'peter'[:-1]@petertodd.org
00000000000000000ea95b4a24d0a510d4b5a98186f904dc16da07c41189d8b8
--qMm9M+Fa2AknHoGS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWD+adXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZWE5NWI0YTI0ZDBhNTEwZDRiNWE5ODE4NmY5MDRkYzE2
ZGEwN2M0MTE4OWQ4YjgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwmzAf/b1NtKnXWL448NnQZasJh6+uH
4tyYOp6BhNUAXxpN8ZR2WLjrUSYDsh6gAily5fM5dW+zsmoBoHt5dJ0QzgQoJ+p1
zQ+BzXZo+L12xCtntMqr13ZZTmQWVFSGU+zhdpuQ6QZ6iepjEmw8tMF86Z6bMykN
fRFWF0c9mYyrSLa1RxUNxw3qWFOH9Jroy83XonkL6uj4LeZsVd4vB/jSsRsq+qX0
HJX/abu0MdEUVKPm3Hp5n5MKPzEnufJGRtRjZoN8F3Ok1+Jl6Ox6C5iyNE12MJsd
ufv/O+LOIDDobtBCkfBYu4nrXS0kiep7pIf+OqX9SuTRsmOMosqI2wiSJwSLBw==
=O9ap
-----END PGP SIGNATURE-----
--qMm9M+Fa2AknHoGS--
|
