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
Description: Digital signature
_______________________________________________ bitcoin-dev mailing list firstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev