Good morning aj, > > Then each update transaction pays out to: > > OP_IF > > <csv_delta> OP_CSV OP_DROP > > <muSig(A_si,B_si)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG > > OP_ELSE > > <i> OP_CHECKLOCKTIMEVERIFY OP_DROP > > <muSig(A_u,B_u)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG > > OP_ENDIF > > Yeah. > > I think we could potentially make that shorter still: > > IF OP_CODESEPARATOR <i> OP_CHECKLOCKTIMEVERIFY OP_DROP ENDIF > <muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS > > Signing with NOINPUT,NOSCRIPT and codeseparatorpos=1 enforces CLTV > and allows binding to any prior update tx -- so works for an update tx > spending previous update txs; while signing with codeseparatorpos=-1 > and NOINPUT but committing to the script code and nSequence (for the > CSV delay) allows binding to only that update tx -- so works for the > settlement tx. That's two pubkeys, two sigs, and the taproot point > reveal.
Actually, the shared keys are different in the two branches above. The "update" branch (which has no `OP_CSV`) uses the same constant `A_u` and `B_u` points. The "state commit" branch (which has `OP_CSV`) uses different `A_si` and `B_si` points depending on `i` (state/sequence number). Also, I cannot understand `OP_CODESEPARATOR`, please no. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
