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 _______________________________________________ Lightning-dev mailing list Lightningfirstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev