Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-21 📝 Original message: On Wed, Mar 20, 2019 at ...
📅 Original date posted:2019-03-21
📝 Original message:
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
📝 Original message:
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