Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

[Rusty Russell <rusty@rustcorp.com.au>]

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.