Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BOLT 7: Onion message support (features 38/39) #759

Merged
merged 3 commits into from
Jul 31, 2023

Conversation

rustyrussell
Copy link
Collaborator

@rustyrussell rustyrussell commented Mar 20, 2020

These use onion encoding for simple one-way messaging: there are no error returns.

Any reply is done with an enclosed blinded path, a-la @t-bast (in fact, this is based on #765)

Note that this defines the message system, not the contents of messages
(e.g. invoice requests from offers).

rustyrussell added a commit to rustyrussell/lightning that referenced this pull request Mar 20, 2020
This tracks lightning/bolts#759

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
07-routing-gossip.md Outdated Show resolved Hide resolved
07-routing-gossip.md Outdated Show resolved Hide resolved
07-routing-gossip.md Outdated Show resolved Hide resolved
07-routing-gossip.md Outdated Show resolved Hide resolved
04-onion-routing.md Outdated Show resolved Hide resolved
rustyrussell added a commit to rustyrussell/lightning that referenced this pull request Mar 29, 2020
This tracks lightning/bolts#759

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit to rustyrussell/lightning that referenced this pull request Apr 1, 2020
This tracks lightning/bolts#759

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell added a commit to ElementsProject/lightning that referenced this pull request Apr 2, 2020
This tracks lightning/bolts#759

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
04-onion-routing.md Outdated Show resolved Hide resolved
@dr-orlovsky
Copy link
Contributor

Got really confused trying to understand how this proposal and #755 are related: is one a later version of the other?

@rustyrussell
Copy link
Collaborator Author

Got really confused trying to understand how this proposal and #755 are related: is one a later version of the other?

Oops, they were (almost!) identical. I closed the prior one since this one has comments.

I'm rebasing on master now, having applied the typo fixes (thanks!).

My only q is whether we should drop the reply_path and put that inside whatever the payload being delivered is. For invoice requests we already have such a field, so it would be easy, and simplify the onion message proposal markedly.

The downside is that you can't reply with an error if the payload itself is unparsable...

@rustyrussell rustyrussell changed the title WIP: BOLT 7: Onion message support. WIP: BOLT 7: Onion message support (features 102/103) Mar 3, 2021
@rustyrussell rustyrussell changed the title WIP: BOLT 7: Onion message support (features 102/103) BOLT 7: Onion message support (features 102/103) Mar 3, 2021
@rustyrussell
Copy link
Collaborator Author

Trivial squash and rebase on master.

@rustyrussell
Copy link
Collaborator Author

Hmm, should we give this a real feature number?

@rustyrussell
Copy link
Collaborator Author

Since we're now tentatively self-assigning incremental feature numbers, I'm switching this to 38/39.

@rustyrussell rustyrussell changed the title BOLT 7: Onion message support (features 102/103) BOLT 7: Onion message support (features 38/39) Jun 30, 2021
09-features.md Outdated Show resolved Hide resolved
04-onion-routing.md Outdated Show resolved Hide resolved
@rustyrussell
Copy link
Collaborator Author

OK, this is the simplified version, FTW. I'm implementing it now: for the moment c-lightning will accept and send the old version too, to ease transition.

Thanks @TheBlueMatt !

These use onion encoding for simple one-way messaging: there are no error returns.
However, every onion uses route blinding *even if it doesn't need to*.

You can prove what path was used to reach you by including `path_id` in the
encrypted_data_tlv.

Note that this doesn't actually define the payload we're transporting:
that's explictly defined to be payloads in the 64-255 range.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
@rustyrussell
Copy link
Collaborator Author

OK, I squashed into a single commit and fixed some whitespace (and changed a "MUST send an error" to "MUST ignore" for consistency).

This now applies directly onto master now blinded payments are merged!

Copy link
Collaborator

@t-bast t-bast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks mostly good to me, only minor comments.
@thomash-acinq can you do a thorough review and double-check the test vectors against eclair?

04-onion-routing.md Outdated Show resolved Hide resolved
.aspell.en.pws Outdated Show resolved Hide resolved
04-onion-routing.md Outdated Show resolved Hide resolved
04-onion-routing.md Outdated Show resolved Hide resolved
04-onion-routing.md Outdated Show resolved Hide resolved
04-onion-routing.md Outdated Show resolved Hide resolved
bolt04/blinded-onion-message-onion-test.json Show resolved Hide resolved
bolt04/blinded-onion-message-onion-test.json Outdated Show resolved Hide resolved
04-onion-routing.md Outdated Show resolved Hide resolved
04-onion-routing.md Outdated Show resolved Hide resolved
04-onion-routing.md Outdated Show resolved Hide resolved
@thomash-acinq points out:

1. We absolutely can put other fields in `encrypted_data_tlv`, esp. padding, and test vectors do this.
2. Presumably it was supposed to refer to onionmsg_tlv, so fix that.
3. And of course we need to allow payload fields!
Copy link
Collaborator

@t-bast t-bast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 217a99e

@t-bast
Copy link
Collaborator

t-bast commented May 23, 2023

@valentinewallace can you have a look at the latest state of the PR (and ideally the test vectors)? If everything looks good, we can (finally) merge this!

@ProofOfKeags
Copy link
Contributor

I figure that this topic has been raised somewhere, but isn't the Onion Messaging system a potential DOS vector? If that discussion was resolved, is the documentation of that discussion in a different place? I am trying to catch up on the state of this and BOLT12 and IIRC this was an open point of debate for a while.

@bshramin
Copy link

bshramin commented Jul 2, 2023

Should onion messages get added here?
https://github.com/lightning/bolts/blob/master/01-messaging.md?plain=1#L473

as the `hop_payloads` format, except there is no "legacy" length: a 0
`length` would mean an empty `onionmsg_payload`.

Onion messages are unreliable: in particular, they are designed to
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since OMs are unreliable and a sender might have to retry multiple times (maybe even try numerous paths simultaneously to gain more reliability), does it make sense to add an idempotency key to onion messages?

- MUST set the `onion_message_packet` `version` to 0.
- MUST construct the `onion_message_packet` `onionmsg_payloads` as detailed above using Sphinx.
- MUST NOT use any `associated_data` in the Sphinx construcion.
- SHOULD set `onion_message_packet` `len` to 1366 or 32834.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean that an OM can travel far more than 20 hops?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potentially, yes. With varonions the limitation to fixed 20 hops went away anyway, so even the smaller 1366 byte onion could potentially contain more hops. It all deppends on the payload you want to deliver at each hop.

Copy link

@bshramin bshramin Aug 15, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the answer. So if I want to calculate the maximum number of hops I can go through, does this look right?
32768 / 70 =~ 468 hops

@rustyrussell
Copy link
Collaborator Author

Agreed to merge pending @valentinewallace acking test vectors.

@rustyrussell rustyrussell merged commit 803a532 into lightning:master Jul 31, 2023
@rustyrussell
Copy link
Collaborator Author

Merged by agreement at 31-07-2023 meeting.

@niftynei
Copy link
Collaborator

adding link to spec meeting where this was merged #1098

@ProofOfKeags
Copy link
Contributor

I figure that this topic has been raised somewhere, but isn't the Onion Messaging system a potential DOS vector?

Responding to myself here to document the resolution of this. The current assessment is that the bandwidth of onion messages required for "proper usage" with BOLT12 is fairly low, and implementations are advised to implement some basic rate limiting to mitigate this. Rate-limiting strategy is left as an exercise to the implementer.

@vincenzopalazzo
Copy link
Contributor

Responding to myself here to document the resolution of this. The current assessment is that the bandwidth of onion messages required for "proper usage" with BOLT12 is fairly low, and implementations are advised to implement some basic rate limiting to mitigate this. Rate-limiting strategy is left as an exercise to the implementer.

Yeah, when we have several implementation that support it we can also consider to add a line in the spec for people that will go to implement it in th future

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet