<div dir="ltr"><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div><br></div><div>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.</div><div>But I think if using MuSig you would need to store each two party generated encrypted signature.</div><div>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.<br></div></div></blockquote><div><br></div><div>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). <br></div><div>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.<br></div><div><br></div><div>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).<br></div><div><br></div><div>### Eliminating Publication Points In favor of  "revocable signatures" (for OP_CHECKMULTISIG)<br></div><div><br></div>I propose replacing the publication point with a static key that remains the same with each commitment transaction.</div><div class="gmail_quote">The encryption key for each commitment transaction adaptor signature is (Ra + A)  for Alice and (Rb + B) for Bob. <br></div><div class="gmail_quote">Therefore, Alice broadcasting her commitment transaction would reveal the discrete log of Ra + A (and Bob Rb + B).<br></div><div class="gmail_quote">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.</div><div class="gmail_quote">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).</div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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:<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Balance output for Alice is  2-of-2(A , Rb + B)</div><div class="gmail_quote">Balance output for Bob is   2-of-2(Ra + A, B)</div><div class="gmail_quote"><br></div><div class="gmail_quote">The implication of the above structure is that if you broadcast a commitment transaction the other party can take their balance immediately.</div><div class="gmail_quote"> If you broadcasted a revoked commitment transaction then they can take their output and yours immediately.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">PTLC outputs and all subsequent transaction outputs then simplify to 2-of-2(A,B) on every output. Yay!<br></div><div>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. <br></div><div>The converse is true for the PTLC-timeout.</div><div>This elegant uniformity extends to other off-chain protocols hosted in these channels e.g. DLCs<br></div><div><br></div><div>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.</div><div>In practice each 2-of-2(A,B) should be randomized so they don't all look the same. <br></div><div><br></div><div class="gmail_quote">### Revoking key aggregated schnorr signatures (for MuSig)<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Even with the above improvement there is still O(n) storage if using key aggregation (MuSig) on the funding transaction output.<br></div><div class="gmail_quote">Key aggregation may be desirable here since you may want to not use a taproot spend to broadcast a commitment transaction.<br></div><div class="gmail_quote"> 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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote">This prevents you from broadcasting it since the other party can now extract your secret key from it!</div><div class="gmail_quote">Explicitly, two party signature generate two Schnorr signatures for the key A + B in the form:</div><div class="gmail_quote"><br></div><div class="gmail_quote">sa = ra + rb' + H(Ra + Rb' || A + B || m)(a + b)</div><div class="gmail_quote">sb = ra' + rb + H(Ra' + Rb || A + B || m)(a + b)</div><div class="gmail_quote"><br></div><div class="gmail_quote">- (ra,rb) are the revocation secret keys, <br></div><div class="gmail_quote">- (ra', rb') are typical deterministically produced[1] nonces with Ra' = ra' * G etc. <br></div><div class="gmail_quote">- (a,b) are the static secret keys  <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Only Alice knows sa and only Bob knows sb but they are both signatures on the same commitment transaction.</div><div class="gmail_quote"> This is the witness asymmetry in the protocol.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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:</div><div class="gmail_quote"><br></div><div class="gmail_quote"> ra + rb' + H(Ra + Rb' || A + B || m)b<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">which when subtracted from sa and divided by H(Ra + Rb' || A + B || m)

 will yield b (Bob's static secret key).</div><div class="gmail_quote"><br></div><div class="gmail_quote">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). <br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote">This is because each PTLC does not need to be duplicated across the asymmetric state of both parties.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote">Thankfully, there are still advancements being made in Schnorr key aggregated signing so the right answer to this might change over time.[3]<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">[1] The caveats about not using deterministic nonces in MuSig can be avoided here since we necessarily have state in LN.<br></div><div class="gmail_quote">[2] 
 <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html">https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html</a> <br></div><div class="gmail_quote">[3] <a href="https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5df9d6">https://medium.com/blockstream/musig-dn-schnorr-multisignatures-with-verifiably-deterministic-nonces-27424b5df9d6</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote"><br></div><div class="gmail_quote">LL<br></div></div>