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

[Anthony Towns <aj@erisian.com.au>]

On Wed, Mar 20, 2019 at 08:07:00AM +0000, ZmnSCPxj via Lightning-dev wrote:
> Re-reading again, I think perhaps I was massively confused by this:
> > that commits to the input. In that case, you could do eltoo with a
> > script like either:
> > <A> CHECKSIGVERIFY <B> CHECKSIG
> > or <P> CHECKSIGVERIFY <Q> CHECKSIG
> Do you mean that *either* of the above two scripts is OK, *or* do you mean they are alternatives within a single MAST or `OP_IF`?

I meant "either of the two scripts is okay".

> In the blob sent to Watchtower, A (or B) includes the `SIGHASH_NOINPUT` as well as the `q` private key.
> Would it be safe for Watchtower to know that?

I think so. From Alice/Bob's point-of-view, the NOINPUT sig ensures they
control their money; and from the network's point-of-view (or at least
that part of the network that thinks NOINPUT is unsafe) the Q private
key being shared makes the tx no worse than a 1-of-n multisig setup,
which has to be dealt with anyway.

> 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.

Cheers,
aj