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
|
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 79B122180
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Oct 2015 17:41:26 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148096.authsmtp.net (outmail148096.authsmtp.net
[62.13.148.96])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0973D27D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Oct 2015 17:41:24 +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 t98HfNZ8065737;
Thu, 8 Oct 2015 18:41:23 +0100 (BST)
Received: from muck (de2x.mullvad.net [46.165.208.203])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t98HfKP3032047
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 8 Oct 2015 18:41:22 +0100 (BST)
Date: Thu, 8 Oct 2015 19:41:20 +0200
From: Peter Todd <pete@petertodd.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Message-ID: <20151008174120.GA9291@muck>
References: <20151003143056.GA27942@muck>
<87lhbgn4fa.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY"
Content-Disposition: inline
In-Reply-To: <87lhbgn4fa.fsf@rustcorp.com.au>
X-Server-Quench: ca9b39eb-6de3-11e5-b39a-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgoUF1YAAgsB AmMbWlxeVFx7W2E7 bwxPbANYfEhOVxto
UEtWR1pVCwQmRRUJ fkhlMhpydAdGfHk+ YEJiXj4IDU0odk8o
EFNSQTgFeGZhPWUC AkNRJh5UcAFPdx8U a1UrBXRDAzANdhEy
HhM4ODE3eDlSNhEd aSEgBnEpbH82MxgX ai4vJxQBLAVADxo+
ZxorJ1JUGUELPw0v KlYqUEkVKFcODW8W GkZRATFQO1RJWyom RQhaVEgRHVUA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 46.165.208.203/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
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: Thu, 08 Oct 2015 17:41:26 -0000
--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> writes:
> > However I don't think we've done a good job showing why we need to
> > implement this feature via nSequence.
>=20
> It could be implemented in other ways, but nSequence is the neatest and
> most straightforward I've seen.
>=20
> - I'm not aware of any other (even vague) proposal for its use? Enlighte=
n?
There's three that immediately come to mind:
Gregory Maxwell has proposed it as a way of discouraging miners from
reorging chains, by including some of the low-order bits of a previous
block header in nSequence.
A few people have proposed implementing proof-of-stake blocksize voting
with nSequence.
> - BIP68 reserves much of it for future use already.
Well, a few low-order bits, if you want to use RCLTV functionality; pure
RCLTV would save a lot more bits.
> If we apply infinite caution we could never use nSequence, as there
> might be a better use tommorrow.
Indeed! But lets make sure we have a good argument in the BIP.
--=20
'peter'[:-1]@petertodd.org
00000000000000000de60f807a5fd32057510e7715038ecbc888052861b6a5c1
--4Ckj6UjgE2iN1+kY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWFqq9XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZGU2MGY4MDdhNWZkMzIwNTc1MTBlNzcxNTAzOGVjYmM4
ODgwNTI4NjFiNmE1YzEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udyM+Af9Fta4GSWvY3JEumGy/FgsoRpD
cOTcvwkoWD/YlwvnhVbiPc9hzvSngi022s3XDw8qQTUXqaV22hxQ/Iwd37SqAjEr
Vvr6mPlJwxAJ0S/zznifY0cfPwHfFtUceB/QpwatT/QoDlHqYLbmxxSjuPuL8g2q
BRO2XGdE7X22nOLqnybO4JOHKlsnlO/xLdeoZUml173DVKR7UA0TJi+CadIkU1Bs
GTNAjrug8IgoxdZE2Cn82EGyQMGgItzLlch0d0Lw6VIn7Z+14B8dyEMWJAHbZxnE
GbDD1fMTlffb+0LRmlFHVJ7RqxSKYcH7qLIwplUNITLI1e8LjqY6Katcs5I8ng==
=TzhN
-----END PGP SIGNATURE-----
--4Ckj6UjgE2iN1+kY--
|
