[Lightning-dev] Witness asymmetric payment channels

Lloyd Fournier 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200902/ccfda71e/attachment.html>


More information about the Lightning-dev mailing list