Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2016-09-22 📝 Original message:On Thu, Sep 22, 2016 at ...

📅 Original date posted:2016-09-22
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160922/e0b97186/attachment.sig>;