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