{"type":"rich","version":"1.0","title":"Lloyd Fournier [ARCHIVE] wrote","author_name":"Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)","author_url":"https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-12-11\n📝 Original message:\nHi list,\n\nCurrently, if your lightning node has data loss there are two ways of\nrecovering your funds once you have established which channels you had with\nwhich peers:\n\n1. Wait until your peer closes the channel. The downside is that you have\nno control over when this happens.\n2. Connect to your peer and ask them to close it. The downside is that to a\nmalicious actor this request reads like \"now is a good time to steal my\nmoney or extort me\".\n\nWhat if instead we could somehow covertly get a signed cooperative\nsettlement transaction for the most recent state without your peer knowing\nthat you've received it?\nLuckily this mystical and almost incoherent requirement is provided by one\nof the oldest and well developed cryptographic primitives: the so called\n\"Oblivious Transfer\" (OT).\n\nhttps://en.wikipedia.org/wiki/Oblivious_transfer\n\nThe idea might go something like this: every time you connect to your peer\nthey present you with an unsigned cooperative settlement transaction for\nall channels you have with them. You and your peer then do an oblivious\ntransfer where they send you their signatures on the transaction or nothing\n(whichever you choose). If you want to carry on with the channel you reveal\nto the sender that you chose nothing. If you are recovering funds you\nchoose the signatures and broadcast the transaction.\n\nFor this to be useful we have an extra requirement over typical OT which is\nthat we can verify the contents of the message we didn't choose. i.e. even\nif we are not doing a recovery we have to be able to verify that the\nsignatures we were offered were valid (wihout actually ever being able to\nuse them!). Otherwise a malicious party could just be sending us invalid\nsignatures in the OT the whole time. The name for this oblivious signatures.\n\n## Constructing\n\nOblivious signatures can be created using any verifiable encrypted\nsignature scheme where the encryption key is a group element (this includes\nadaptor signatures).\nIn [1] they actually use adaptor signatures without calling them that to\ncreate a Schnorr oblivious signature scheme that is similar to what you\nwould do with BIP340 Schnorr in practice.\nI used this in [2] to create scriptless lotteries in Bitcoin.\n\nTo start assume that you have three functions (which can be instantiated\nwith adaptor signatures):\n\n- `encrypted_sign(x, m, Y) -\u003e e`\n- `encrypted_signature_verify(X, m, Y) -\u003e true/false`\n- `decrypt_signature(e, y) -\u003e s`\n\nWhere X is the public signing key Y is the encryption key and (x,y) are\ntheir corresponding secret keys.\nIn our case x can be thought of as a secret key on a funding output.\n\nFirst, the party receiving the offer decides whether they want to receive\nthe settlement tx signature by setting c = 0  or otherwise c = 1 and then\ncreates a pedersen commitment Y to c by choosing a random y:\n\nY = y *G + c * H\n\nand sends the commitment Y to its peer.\n\nThe peer then sends `e = encrypted_sign(x, settlement_tx, Y)` back.\n\nIf c = 0 (i.e. it is doing a covert recovery) it does `s =\ndecrypt_signature(e, y)` and attaches to the settlement transaction and\nbroadcasts it.  The channel is now successfully closed assuming the\nencrypted signature was valid.\n\nIf c = 1 (i.e. the node is fine and it wants to continue the channel) then\nit checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it passes\nit sends the commitment blinding y back to prove that it doesn't have the\nsignature (i.e. prove c = 1). If verification fails then the node is\nmalicious and it fails the channel. Note that it is not possible to decrypt\nthe signature if c = 1 since the discrete logarithm of H with respect to G\nis unknown.\n\n## Misc Q\u0026A\n\n- Does this require crazy crypto magic? No with the exception of Pedersen\ncommitments it only requires what is being planned to be included in\nlightning anyway i.e. adaptor signatures.\n\n-  Who is receiver and who is sender? In my imagination this works by the\npeer that is opening the connection being the receiver. This seems more\nuseful since users who are likely to not have redundant storage and\ngenerally mess things up and need to recover are often behind NAT or on\nphone networks without a public ip. There are cases where a public node may\nwant to recover by having people connect to them but I don't know what to\ndo about that. It looks like you have to choose one or the other.\n\n- Can't they still steal money? Yes but this is still a strictly better\nthan the current situation. The attacker has to guess precisely which\nconnection you make is after data loss. This is tricky task especially\nbecause if they ever guess wrongly you close your channel with them and\nblock them. Right now you are the one who tells them you've lost data!\n\n- Are these oblivious signatures secure? Yes. Sender security (receiver\nonly gets the signature if c = 0) is based on discrete log assumption.\nHint: if you instantiate the above algorithms with adaptor signatures we\ncan extract the discrete log of H from a receiver who knows an opening of Y\nwhere c = 1 and also successfully decrypts the signature. Receiver security\nis unconditional (Pedersen commitments are unconditionally hiding).\n\n- Does this work for multiple signatures? Yes you can choose to receive N\nsignatures to close N channels or nothing.  The signer just sends multiple\ne_1, e_2 produced the same way and the receiver can decrypt them all if c =\n0.\n\n- Does it work for key aggregated signatures i.e. MuSig2? -- Yes\n`encrypted_sign` just becomes a two round protocol to produce `e`.\n\n- What do you do if the channel state has HTLCs in flight? I don't know --\nI guess you can just put them onto the settlement tx? That way it's\npossible the payment could still go through. Alternatively you could just\ngift the money to the party offering the recovery settlement.\n\n[1]\nhttp://www.cs.nccu.edu.tw/~raylin/UndergraduateCourse/ComtenporaryCryptography/Spring2009/TSOINSPET2007.pdf\n[2]\nhttps://telaviv2019.scalingbitcoin.org/files/scriptless-lotteries-on-bitcoin-from-oblivious-transfer.pdf\n\nCheers,\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201211/0179a579/attachment.html\u003e"}