On 20 Mar 2019, at 4:07 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Hi aj,

Re-reading again, I think perhaps I was massively confused by this:

- alternatively, we could require every script to have a valid signature
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


where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
a key they both know the private key for. In the first case, Alice
would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
Bob would just do a SIGHASH_ALL sig with his own key. In the second,
Alice and Bob would share partial NOINPUT sigs of the tx with P, and
finish that when they wanted to publish.

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`?


It means either.

If you use <A> CHECKSIGVERIFY <B> CHECKSIG style, A and B will exchange the NOINPUT sig, and they will add the required non-NOINPUT sig when needed.

If you use <muSig(A,B)> CHECKVERIFY <Q> CHECKSIG, A and B will co-sign the muSig(A,B) with NOINPUT. They will also share the private key of Q, so they could produce a non-NOINPUT sig when needed.

The first style is slightly easier as it doesn’t need muSig. But with 3 or more parties, the second style is more efficient.

However, if you use watchtower, you have to use the second style. That means you need to share the private key for Q with the watchtower, That also means the watchtower will have the ability to reply the NOINPU muSig. But it is still strictly better than anyone-can-replay.