> Unfortunately, while thinking about the above statement I realised > there is worse storage complexity. > In order to punish a revoked commitment transaction efficiently you > need to extract the publication secret. > But in order to do that you need to keep around the encrypted > signature (a.k.a adaptor signature) **for that particular commitment > transaction**. > This means you have O(n) storage, unlike the present spec which has > O(1) by deriving the previously revealed revocation secret from the > present one (this can't be done with adaptor signatures). > This doesn't seem to be addressed in the original work. > > Yikes! This might be a fatal flaw to this proposal unless it can be addressed. >
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. LL
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
