Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2020-09-01 📝 Original message: > Unfortunately, while ...

📅 Original date posted:2020-09-01
📝 Original message:
> 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>;