From aj at erisian.com.au  Thu Mar 21 09:06:14 2019
From: aj at erisian.com.au (Anthony Towns)
Date: Thu, 21 Mar 2019 19:06:14 +1000
Subject: [Lightning-dev] More thoughts on NOINPUT safety
In-Reply-To: <isp2OcX23r-Tfl-WSbybuKnppjVlZV52AM1GGEaQd8uHlkliikUBvK49WOnzgaxOjDuOCNdu6CsmHt6kfK0z_FRrOgYAYWrWaDniZA3EEZQ=@protonmail.com>
References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au>
	<87k1gubdjm.fsf@rustcorp.com.au> <87woku9q3g.fsf@rustcorp.com.au>
	<UOdt33VfD8o6NfeDKMSip0hUmy1_jyo65-ihunuMRRg8IfXEOq-W60-TPoINm5HErPqnY_-yd1x_VnnVihrvtXRA2OHkjeROZheZ_QV0Zvo=@protonmail.com>
	<isp2OcX23r-Tfl-WSbybuKnppjVlZV52AM1GGEaQd8uHlkliikUBvK49WOnzgaxOjDuOCNdu6CsmHt6kfK0z_FRrOgYAYWrWaDniZA3EEZQ=@protonmail.com>
Message-ID: <20190321090614.7ir64g2ehn3pz2cb@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