[Lightning-dev] Witness asymmetric payment channels
lloyd.fourn at gmail.com
Tue Sep 1 20:27:15 UTC 2020
> 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
> 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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Lightning-dev