[bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
rusty at rustcorp.com.au
Thu Aug 27 03:08:42 UTC 2015
Btc Drak via bitcoin-dev <bitcoin-dev at 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?
More information about the bitcoin-dev