Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

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