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>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to
 motivate the change
Precedence: list


--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--