aljaz/lightning
1
0
Fork 0
mirror of https://github.com/aljazceru/lightning.git synced 2026-01-09 09:04:25 +01:00
Code Issues Packages Projects Releases Wiki Activity

onion_message: don't use general secret, use per-message secret.

Browse Source 
We had a scheme where lightningd itself would put a per-node secret in
the blinded path, then we'd tell the caller when it was used.  Then it
simply checks the alias to determine if the correct path was used.

But this doesn't work when we start to offer multiple blinded paths.
So go for a far simpler scheme, where the secret is generated (and
stored) by the caller, and hand it back to them.

We keep the split "with secret" or "without secret" API, since I'm
sure callers who don't care about the secret won't check that it
doesn't exist!  And without that, someone can use a blinded path for a
different message and get a response which may reveal the node.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell
2022-11-09 12:00:10 +10:30
committed by Christian Decker
parent 4cfd972407
commit 5becfa6ee1
11 changed files with 51 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
doc/PLUGINS.md
View File

@@ -1650,23 +1650,22 @@ type prefix, since Core Lightning does not know how to parse the message.
Because this is a chained hook, the daemon expects the result to be
`{'result': 'continue'}`. It will fail if something else is returned.
### `onion_message_blinded` and `onion_message_ourpath`
### `onion_message_recv` and `onion_message_recv_secret`
**(WARNING: experimental-offers only)**
These two hooks are almost identical, in that they are called when
an onion message is received.
`onion_message_blinded` is used for unsolicited messages (where the
`onion_message_recv` is used for unsolicited messages (where the
source knows that it is sending to this node), and
`onion_message_ourpath` is used for messages which use a blinded path
we supplied (where the source doesn't know that this node is the
destination). The latter hook will have a `our_alias` field, the
`onion_message_recv_secret` is used for messages which use a blinded path
we supplied. The latter hook will have a `pathsecret` field, the
former never will.
These hooks are separate, because replies MUST be ignored unless they
use the correct path (i.e. `onion_message_ourpath`, with the expected
`our_alias`). This avoids the source trying to probe for responses
use the correct path (i.e. `onion_message_recv_secret`, with the expected
`pathsecret`). This avoids the source trying to probe for responses
without using the designated delivery path.
The payload for a call follows this format:
@@ -1674,7 +1673,7 @@ The payload for a call follows this format:
```json
{
"onion_message": {
"our_alias": "02df5ffe895c778e10f7742a6c5b8a0cefbe9465df58b92fadeb883752c8107c8f",
"pathsecret": "0000000000000000000000000000000000000000000000000000000000000000",
"reply_first_node": "02df5ffe895c778e10f7742a6c5b8a0cefbe9465df58b92fadeb883752c8107c8f",
"reply_blinding": "02df5ffe895c778e10f7742a6c5b8a0cefbe9465df58b92fadeb883752c8107c8f",
"reply_path": [ {"id": "02df5ffe895c778e10f7742a6c5b8a0cefbe9465df58b92fadeb883752c8107c8f",
@@ -1691,7 +1690,6 @@ The payload for a call follows this format:
All fields shown here are optional.
We suggest just returning `{'result': 'continue'}`; any other result
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
will cause the message not to be handed to any other hooks.
## Bitcoin backend