From ZmnSCPxj at protonmail.com  Thu Mar 21 10:05:09 2019
From: ZmnSCPxj at protonmail.com (ZmnSCPxj)
Date: Thu, 21 Mar 2019 10:05:09 +0000
Subject: [Lightning-dev] More thoughts on NOINPUT safety
In-Reply-To: <20190321090614.7ir64g2ehn3pz2cb@erisian.com.au>
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>
	<20190321090614.7ir64g2ehn3pz2cb@erisian.com.au>
Message-ID: <5v4CPrMXyoMw0i1WtYYuIa_rMgkpq5NpnDhTNqTTZtfKKnFtwrbEGJnTD8ul71EM-MNpuo1R4znv4tPpwwm3Ys3m2Dbm3xsOGi96NYE9qfU=@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