Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-11 📝 Original message: Hi list, Currently, if ...
📅 Original date posted:2020-12-11
📝 Original message:
Hi list,
Currently, if your lightning node has data loss there are two ways of
recovering your funds once you have established which channels you had with
which peers:
1. Wait until your peer closes the channel. The downside is that you have
no control over when this happens.
2. Connect to your peer and ask them to close it. The downside is that to a
malicious actor this request reads like "now is a good time to steal my
money or extort me".
What if instead we could somehow covertly get a signed cooperative
settlement transaction for the most recent state without your peer knowing
that you've received it?
Luckily this mystical and almost incoherent requirement is provided by one
of the oldest and well developed cryptographic primitives: the so called
"Oblivious Transfer" (OT).
https://en.wikipedia.org/wiki/Oblivious_transfer
The idea might go something like this: every time you connect to your peer
they present you with an unsigned cooperative settlement transaction for
all channels you have with them. You and your peer then do an oblivious
transfer where they send you their signatures on the transaction or nothing
(whichever you choose). If you want to carry on with the channel you reveal
to the sender that you chose nothing. If you are recovering funds you
choose the signatures and broadcast the transaction.
For this to be useful we have an extra requirement over typical OT which is
that we can verify the contents of the message we didn't choose. i.e. even
if we are not doing a recovery we have to be able to verify that the
signatures we were offered were valid (wihout actually ever being able to
use them!). Otherwise a malicious party could just be sending us invalid
signatures in the OT the whole time. The name for this oblivious signatures.
## Constructing
Oblivious signatures can be created using any verifiable encrypted
signature scheme where the encryption key is a group element (this includes
adaptor signatures).
In [1] they actually use adaptor signatures without calling them that to
create a Schnorr oblivious signature scheme that is similar to what you
would do with BIP340 Schnorr in practice.
I used this in [2] to create scriptless lotteries in Bitcoin.
To start assume that you have three functions (which can be instantiated
with adaptor signatures):
- `encrypted_sign(x, m, Y) -> e`
- `encrypted_signature_verify(X, m, Y) -> true/false`
- `decrypt_signature(e, y) -> s`
Where X is the public signing key Y is the encryption key and (x,y) are
their corresponding secret keys.
In our case x can be thought of as a secret key on a funding output.
First, the party receiving the offer decides whether they want to receive
the settlement tx signature by setting c = 0 or otherwise c = 1 and then
creates a pedersen commitment Y to c by choosing a random y:
Y = y *G + c * H
and sends the commitment Y to its peer.
The peer then sends `e = encrypted_sign(x, settlement_tx, Y)` back.
If c = 0 (i.e. it is doing a covert recovery) it does `s =
decrypt_signature(e, y)` and attaches to the settlement transaction and
broadcasts it. The channel is now successfully closed assuming the
encrypted signature was valid.
If c = 1 (i.e. the node is fine and it wants to continue the channel) then
it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it passes
it sends the commitment blinding y back to prove that it doesn't have the
signature (i.e. prove c = 1). If verification fails then the node is
malicious and it fails the channel. Note that it is not possible to decrypt
the signature if c = 1 since the discrete logarithm of H with respect to G
is unknown.
## Misc Q&A
- Does this require crazy crypto magic? No with the exception of Pedersen
commitments it only requires what is being planned to be included in
lightning anyway i.e. adaptor signatures.
- Who is receiver and who is sender? In my imagination this works by the
peer that is opening the connection being the receiver. This seems more
useful since users who are likely to not have redundant storage and
generally mess things up and need to recover are often behind NAT or on
phone networks without a public ip. There are cases where a public node may
want to recover by having people connect to them but I don't know what to
do about that. It looks like you have to choose one or the other.
- Can't they still steal money? Yes but this is still a strictly better
than the current situation. The attacker has to guess precisely which
connection you make is after data loss. This is tricky task especially
because if they ever guess wrongly you close your channel with them and
block them. Right now you are the one who tells them you've lost data!
- Are these oblivious signatures secure? Yes. Sender security (receiver
only gets the signature if c = 0) is based on discrete log assumption.
Hint: if you instantiate the above algorithms with adaptor signatures we
can extract the discrete log of H from a receiver who knows an opening of Y
where c = 1 and also successfully decrypts the signature. Receiver security
is unconditional (Pedersen commitments are unconditionally hiding).
- Does this work for multiple signatures? Yes you can choose to receive N
signatures to close N channels or nothing. The signer just sends multiple
e_1, e_2 produced the same way and the receiver can decrypt them all if c =
0.
- Does it work for key aggregated signatures i.e. MuSig2? -- Yes
`encrypted_sign` just becomes a two round protocol to produce `e`.
- What do you do if the channel state has HTLCs in flight? I don't know --
I guess you can just put them onto the settlement tx? That way it's
possible the payment could still go through. Alternatively you could just
gift the money to the party offering the recovery settlement.
[1]
http://www.cs.nccu.edu.tw/~raylin/UndergraduateCourse/ComtenporaryCryptography/Spring2009/TSOINSPET2007.pdf
[2]
https://telaviv2019.scalingbitcoin.org/files/scriptless-lotteries-on-bitcoin-from-oblivious-transfer.pdf
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201211/0179a579/attachment.html>;
📝 Original message:
Hi list,
Currently, if your lightning node has data loss there are two ways of
recovering your funds once you have established which channels you had with
which peers:
1. Wait until your peer closes the channel. The downside is that you have
no control over when this happens.
2. Connect to your peer and ask them to close it. The downside is that to a
malicious actor this request reads like "now is a good time to steal my
money or extort me".
What if instead we could somehow covertly get a signed cooperative
settlement transaction for the most recent state without your peer knowing
that you've received it?
Luckily this mystical and almost incoherent requirement is provided by one
of the oldest and well developed cryptographic primitives: the so called
"Oblivious Transfer" (OT).
https://en.wikipedia.org/wiki/Oblivious_transfer
The idea might go something like this: every time you connect to your peer
they present you with an unsigned cooperative settlement transaction for
all channels you have with them. You and your peer then do an oblivious
transfer where they send you their signatures on the transaction or nothing
(whichever you choose). If you want to carry on with the channel you reveal
to the sender that you chose nothing. If you are recovering funds you
choose the signatures and broadcast the transaction.
For this to be useful we have an extra requirement over typical OT which is
that we can verify the contents of the message we didn't choose. i.e. even
if we are not doing a recovery we have to be able to verify that the
signatures we were offered were valid (wihout actually ever being able to
use them!). Otherwise a malicious party could just be sending us invalid
signatures in the OT the whole time. The name for this oblivious signatures.
## Constructing
Oblivious signatures can be created using any verifiable encrypted
signature scheme where the encryption key is a group element (this includes
adaptor signatures).
In [1] they actually use adaptor signatures without calling them that to
create a Schnorr oblivious signature scheme that is similar to what you
would do with BIP340 Schnorr in practice.
I used this in [2] to create scriptless lotteries in Bitcoin.
To start assume that you have three functions (which can be instantiated
with adaptor signatures):
- `encrypted_sign(x, m, Y) -> e`
- `encrypted_signature_verify(X, m, Y) -> true/false`
- `decrypt_signature(e, y) -> s`
Where X is the public signing key Y is the encryption key and (x,y) are
their corresponding secret keys.
In our case x can be thought of as a secret key on a funding output.
First, the party receiving the offer decides whether they want to receive
the settlement tx signature by setting c = 0 or otherwise c = 1 and then
creates a pedersen commitment Y to c by choosing a random y:
Y = y *G + c * H
and sends the commitment Y to its peer.
The peer then sends `e = encrypted_sign(x, settlement_tx, Y)` back.
If c = 0 (i.e. it is doing a covert recovery) it does `s =
decrypt_signature(e, y)` and attaches to the settlement transaction and
broadcasts it. The channel is now successfully closed assuming the
encrypted signature was valid.
If c = 1 (i.e. the node is fine and it wants to continue the channel) then
it checks `encrypted_signature_verify(X, settlement_tx, Y)`. If it passes
it sends the commitment blinding y back to prove that it doesn't have the
signature (i.e. prove c = 1). If verification fails then the node is
malicious and it fails the channel. Note that it is not possible to decrypt
the signature if c = 1 since the discrete logarithm of H with respect to G
is unknown.
## Misc Q&A
- Does this require crazy crypto magic? No with the exception of Pedersen
commitments it only requires what is being planned to be included in
lightning anyway i.e. adaptor signatures.
- Who is receiver and who is sender? In my imagination this works by the
peer that is opening the connection being the receiver. This seems more
useful since users who are likely to not have redundant storage and
generally mess things up and need to recover are often behind NAT or on
phone networks without a public ip. There are cases where a public node may
want to recover by having people connect to them but I don't know what to
do about that. It looks like you have to choose one or the other.
- Can't they still steal money? Yes but this is still a strictly better
than the current situation. The attacker has to guess precisely which
connection you make is after data loss. This is tricky task especially
because if they ever guess wrongly you close your channel with them and
block them. Right now you are the one who tells them you've lost data!
- Are these oblivious signatures secure? Yes. Sender security (receiver
only gets the signature if c = 0) is based on discrete log assumption.
Hint: if you instantiate the above algorithms with adaptor signatures we
can extract the discrete log of H from a receiver who knows an opening of Y
where c = 1 and also successfully decrypts the signature. Receiver security
is unconditional (Pedersen commitments are unconditionally hiding).
- Does this work for multiple signatures? Yes you can choose to receive N
signatures to close N channels or nothing. The signer just sends multiple
e_1, e_2 produced the same way and the receiver can decrypt them all if c =
0.
- Does it work for key aggregated signatures i.e. MuSig2? -- Yes
`encrypted_sign` just becomes a two round protocol to produce `e`.
- What do you do if the channel state has HTLCs in flight? I don't know --
I guess you can just put them onto the settlement tx? That way it's
possible the payment could still go through. Alternatively you could just
gift the money to the party offering the recovery settlement.
[1]
http://www.cs.nccu.edu.tw/~raylin/UndergraduateCourse/ComtenporaryCryptography/Spring2009/TSOINSPET2007.pdf
[2]
https://telaviv2019.scalingbitcoin.org/files/scriptless-lotteries-on-bitcoin-from-oblivious-transfer.pdf
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201211/0179a579/attachment.html>;