On Thu, Sep 22, 2016 at 10:47:03AM +0200, Tom via bitcoin-dev wrote:
> On Wednesday 21 Sep 2016 18:45:55 adiabat via bitcoin-dev wrote:
> > Hi-
> > 
> > One concern is that this doesn't seem compatible with Lightning as
> > currently written.  Most relevant is that non-cooperative channel close
> > transactions in Lightning use OP_CHECKSEQUENCEVERIFY, which references the
> > sequence field of the txin; if the txin doesn't have a sequence number,
> > OP_CHECKSEQUENCEVERIFY can't work.
> > 
> > LockByBlock and LockByTime aren't described and there doesn't seem to be
> > code for them in the PR (186).  If there's a way to make OP_CLTV and OP_CSV
> > work with this new format, please let us know, thanks!
> 
> LockByBlock and LockByTime are still TODOs because I didn't have time to go
> in-dept into how BIP68 does the encoding.
> The intent is that these tags, while loading, will set the sequence integer in 
> the txin as the old version does. And while saving we do the reverse.
> 
> In other words; the lack of sequence number in the saved format doesn't affect 
> the in-memory format of the transaction. The in-memory version is the one that 
> script will operate on.
> 
> This means that there is no change in how CSV will work before and after on 
> any level other than serialisation.

CSV uses per-input sequence numbers; you only have a per-tx equivalent.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org