📅 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>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 13:00:48
in reply to nevent1q…g0tp
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 13:00:48Event JSON
{
"id": "24c6f22fc4dcc0cf568a7488e2eec3cdf6af45d07e65936f2fd3bce84d682a6b",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315648,
"kind": 1,
"tags": [
[
"e",
"2aa40f2c405c7c0ea417d01f817a9ac6c4bf677087182c06195ea2808279c070",
"",
"root"
],
[
"e",
"bb397cad6cd5a5a5572518af82655d12f338002a9f20b6d1d7a978d61a5e777b",
"",
"reply"
],
[
"p",
"b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e"
]
],
"content": "📅 Original date posted:2020-09-01\n📝 Original message:\n\u003e Unfortunately, while thinking about the above statement I realised\n\u003e there is worse storage complexity.\n\u003e In order to punish a revoked commitment transaction efficiently you\n\u003e need to extract the publication secret.\n\u003e But in order to do that you need to keep around the encrypted\n\u003e signature (a.k.a adaptor signature) **for that particular commitment\n\u003e transaction**.\n\u003e This means you have O(n) storage, unlike the present spec which has\n\u003e O(1) by deriving the previously revealed revocation secret from the\n\u003e present one (this can't be done with adaptor signatures).\n\u003e This doesn't seem to be addressed in the original work.\n\u003e\n\u003e Yikes! This might be a fatal flaw to this proposal unless it can be\naddressed.\n\u003e\n\nFortunately, I am wrong. At least in the case of non-aggregated 2-of-2 you\ncan deterministically produce the encrypted signature by yourself for any\ncommitment transaction as long as you use a deterministic nonce.\nBut I think if using MuSig you would need to store each two party generated\nencrypted signature.\nSeeing as the likely way forward would be to use MuSig on an output which\nhas a taproot which hides a discrete 2-of-2 this may not be a problem.\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200902/ccfda71e/attachment.html\u003e",
"sig": "ba9927df186f6ecbc9431e0e1d0308ed8862c4430d6496c2e3fd06ddb4da245d878b2b7a26020f775d0321dc9babea1c91c419e49ccaf32e6eaf5b393b5c63bf"
}