> > > Fortunately, I am wrong. At least in the case of non-aggregated 2-of-2 you > can deterministically produce the encrypted signature by yourself for any > commitment transaction as long as you use a deterministic nonce. > But I think if using MuSig you would need to store each two party > generated encrypted signature. > Seeing as the likely way forward would be to use MuSig on an output which > has a taproot which hides a discrete 2-of-2 this may not be a problem. >
Upon further reflection I was missing something obvious when I came to this conclusion. You can't produce the adaptor signature for a commitment transaction deterministically without the encryption key (the other party's publication point). As long as we have to store the other party's per-commitment publication point we still need O(n) storage where n is the number of commitment transactions. Sorry for the confusion. Fortunately I had a bit of a breakthrough which allows us to eliminate publication points altogether and enables O(1) storage when 2-of-2 multi-signatures are instantiated with or without key aggregation (i.e. MuSig or OP_CHECKMULTISIG). ### Eliminating Publication Points In favor of "revocable signatures" (for OP_CHECKMULTISIG) I propose replacing the publication point with a static key that remains the same with each commitment transaction. The encryption key for each commitment transaction adaptor signature is (Ra + A) for Alice and (Rb + B) for Bob. Therefore, Alice broadcasting her commitment transaction would reveal the discrete log of Ra + A (and Bob Rb + B). Note that if Alice has not revealed her recvocation key (Ra) for this commitment transaction she is not in trouble since her static key A is blinded by Ra. If she has then Bob will learn her static secret key for A. The intuition here is that the revocation key acts as a blinding factor for the static key in the same way a nonce blinds your secret key in a schnorr signature (more on that later). If you haven't revealed your revocation key then you are free to use that signature. If you have revealed the revocation key then you have in effect "revoked" the signature. Now we need to make sure that if a party learns the secret key of the other they can efficiently punish them so make the following changes to my original proposal: Balance output for Alice is 2-of-2(A , Rb + B) Balance output for Bob is 2-of-2(Ra + A, B) The implication of the above structure is that if you broadcast a commitment transaction the other party can take their balance immediately. If you broadcasted a revoked commitment transaction then they can take their output and yours immediately. PTLC outputs and all subsequent transaction outputs then simplify to 2-of-2(A,B) on every output. Yay! Consider a PTLC paying to Alice. The PTLC-success output can be 2-of-2(A,B). If Alice broadcasted it and it has been revoked then Bob knows A and B so he can punish her. The converse is true for the PTLC-timeout. This elegant uniformity extends to other off-chain protocols hosted in these channels e.g. DLCs Since A and B are static per channel and the secret keys for Ra and Rb can be incrementally derived from subsequent values (as in the present lightning spec) we have O(1) communication. In practice each 2-of-2(A,B) should be randomized so they don't all look the same. ### Revoking key aggregated schnorr signatures (for MuSig) Even with the above improvement there is still O(n) storage if using key aggregation (MuSig) on the funding transaction output. Key aggregation may be desirable here since you may want to not use a taproot spend to broadcast a commitment transaction. Since the two party adaptor signature scheme needs randomness from both parties, you would have to store the other party's nonce and retrieve it to deterministically produce the adaptor signature so you can extract Ra + A (if Alice broadcasts) from the witness of the commitment transaction. Fortunately, there is a natural way to revoke a key aggregated signature you helped produce without using adaptor signatures at all: just reveal the nonce you used for it to the other party. This prevents you from broadcasting it since the other party can now extract your secret key from it! Explicitly, two party signature generate two Schnorr signatures for the key A + B in the form: sa = ra + rb' + H(Ra + Rb' || A + B || m)(a + b) sb = ra' + rb + H(Ra' + Rb || A + B || m)(a + b) - (ra,rb) are the revocation secret keys, - (ra', rb') are typical deterministically produced[1] nonces with Ra' = ra' * G etc. - (a,b) are the static secret keys Only Alice knows sa and only Bob knows sb but they are both signatures on the same commitment transaction. This is the witness asymmetry in the protocol. When revoking the commitment transaction associated with sa Alice reveals ra to Bob and vice versa. If Alice uses sa after that, Bob can deterministically produce rb' and ra (because each revocation key can be derived from the last) and therefore can produce: ra + rb' + H(Ra + Rb' || A + B || m)b which when subtracted from sa and divided by H(Ra + Rb' || A + B || m) will yield b (Bob's static secret key). The advantage of witness asymmetric channels using discrete keys over present lightning seems to boil down to a simpler transaction structure (in favour of using more complicated cryptography). However, for key aggregation there is a measurable improvement in communication complexity: It halves the amount of interactive signatures that need to be computed per payment. This is because each PTLC does not need to be duplicated across the asymmetric state of both parties. Zeeman pointed out in [2] that the number of signing rounds (which this does not improve) may be prohibitive anyway for payment applications at least so it remains to be seen whether this efficiency can be utilised for payment PTLCs in LN. Thankfully, there are still advancements being made in Schnorr key aggregated signing so the right answer to this might change over time.[3] [1] The caveats about not using deterministic nonces in MuSig can be avoided here since we necessarily have state in LN. [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html [3] https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5df9d6 Cheers, LL
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
