From: Rusty Russell <rusty@rustcorp.com.au>
To: Btc Drak <btcdrak@gmail.com>, jl2012@xbt.hk
In-Reply-To: <CADJgMzsLU5tQDLp0NWDwE6S476PdwvrOWOpn8oQ+5JPyoyi8gQ@mail.gmail.com>
References: <CADJgMztgE_GkbrsP7zCEHNPA3P6T=aSFfhkcN-q=gVhWP0vKXg@mail.gmail.com>
	<CADJgMzv8G3EqLBwEYRHJZ+fO_Jwzy0koi2pJ_iNRkXmoVarGcg@mail.gmail.com>
	<CABm2gDod9z6ksgaCv86qFCyKLTQSL3+oNns+__5H77hVhs05DQ@mail.gmail.com>
	<CAOG=w-sbOcaogkic2i4A5eZnBQ79LUibsGy0dyKyvQg53ktY1Q@mail.gmail.com>
	<55DA6470.9040301@thinlink.com>
	<CAAS2fgQKQpHu-nC1uSrigDx2JLUt64p-LqidVmiuULDE0MJCFQ@mail.gmail.com>
	<85537faedb1e601d243e3edb666fa844@xbt.hk>
	<CAOG=w-vXFcq1bCkviWOK8nh5wz77tYy9hbLXCn8nGLzNRTSgOw@mail.gmail.com>
	<d7ba4da921d3ab55dc774dbd78c21744@xbt.hk>
	<CADJgMzsLU5tQDLp0NWDwE6S476PdwvrOWOpn8oQ+5JPyoyi8gQ@mail.gmail.com>
User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.4.1
	(x86_64-pc-linux-gnu)
Date: Thu, 27 Aug 2015 12:38:42 +0930
Message-ID: <87k2shig1x.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for
	relative locktime
Precedence: list

Btc Drak via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> This BIP has been assigned BIP112 by the BIP repository maintainer. I
> have updated the pull request accordingly.
>
> Regarding the suggestion to cannibalise version, by your own
> disadvantage list, we would lose fine grained control over txins which
> neuters the usefulness considerably. Also using version is also ugly
> because there isn't a semantic association with what we are trying to
> do, whereas, sequence is associated with transaction finality and is
> thus the more appropriate and logical field to use.

OK, having implemented lightning test code against the initial proposal,
I can give the following anecdata:

- I screwed up inversion in my initial implementation.  Please kill it.

- 256 second granularity would be be fine in deployment, but a bit
  painful for testing (I currently use 60 seconds, and "sleep 61").  64
  would work better for me, and works roughly as minutes.

- 1 year should be sufficient as a max; my current handwave is <= 1 day
  per lightning hop, max 12 hops, though we have no deployment data.

- We should immediately deploy an IsStandard() rule which insists that
  nSequence is 0xFFFFFFFF or 0, so nobody screws themselves when we
  soft fork and they had random junk in there.

Aside: I'd also like to have nLockTime apply even if nSequence !=
0xFFFFFFFF (another mistake I made).  So I'd like an IsStandard() rule
to say it nLockTime be 0 if an nSequence != 0xFFFFFFFF.  Would that
screw anyone currently?

Thanks,
Rusty.