Onion message forwarding #10089
Onion message forwarding #10089
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @gijswijs, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request introduces the foundational functionality for forwarding onion messages within the Lightning Network. It integrates a new OnionMessage wire protocol message, enables its routing through the existing Sphinx onion processing infrastructure, and provides RPC endpoints for sending and subscribing to these messages. This work lays the groundwork for future application-layer protocols like BOLT12 offers, allowing for privacy-preserving communication beyond just payments.
Highlights
- Onion Message Wire Protocol: Introduces a new
lnwire.OnionMessagetype to the wire protocol, enabling the transmission of onion-encrypted messages between Lightning Network nodes. This message type is distinct from HTLC-carrying onion packets and is designed for application-layer communication. - Sphinx Onion Processing Integration: Extends the existing Sphinx onion processing logic within
htlcswitch/hopto correctly parse and handleOnionMessagepayloads. This includes adapting the hop iterator to recognize onion messages, extracting forwarding information (such as theNextNodeIDfor node-based routing), and performing message-specific TLV validations. - New RPC Endpoints for Onion Messages: Adds
SendOnionMessageandSubscribeOnionMessagesto the LND RPC API. These new endpoints allow external applications and users to programmatically send onion messages to peers and subscribe to a stream of incoming onion messages, facilitating the development of new privacy-preserving communication features. - Dedicated Message Endpoint and Forwarding Logic: Implements a new
onion_message.OnionEndpointthat integrates with themsgmuxto process incominglnwire.OnionMessages. This endpoint is responsible for decrypting the onion blob, determining if the message is for the local node or needs forwarding, and then either dispatching it to subscribers or relaying it to the next hop in the blinded path. - Enhanced Blinded Path Handling: Introduces specific logic for blinded paths within onion messages, including the addition of
NextNodeIDtoForwardingInfo. This ensures that onion messages, which do not carry payment-related information like CLTV deltas or amounts, are correctly processed and forwarded along their intended blinded routes.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request introduces onion message forwarding, a significant feature that touches multiple parts of the codebase. The changes are generally well-structured, with new functionality encapsulated in the onion_message package and corresponding updates to lnwire, htlcswitch, and the RPC layer. The inclusion of integration tests for both direct and forwarded onion messages is a great addition. I've identified a few issues that need attention: a critical bug in handling dummy hops for onion messages, a high-severity issue with TLV decoding that could lead to panics, and a medium-severity issue regarding message routing logic that could cause confusion and potential bugs. Addressing these will improve the correctness and maintainability of the new functionality.
gijswijs
force-pushed
the
onion-messaging-1
branch
5 times, most recently
from
9157266 to
83a36aa
Compare
gijswijs
force-pushed
the
onion-messaging-1
branch
from
83a36aa to
4de5d9e
Compare
gijswijs
force-pushed
the
onion-messaging-1
branch
2 times, most recently
from
953b2d8 to
3f475ce
Compare
gijswijs
force-pushed
the
onion-messaging-1
branch
from
3f475ce to
606d9e5
Compare
| // NextNodeID is the public key of the next node in the route. This is | ||
| // used by onion messages that do not necessarily care about the channel | ||
| // ID. | ||
| NextNodeID *btcec.PublicKey |
There was a problem hiding this comment.
I don't think we need to add this to the existing HTLC forwarding fabric at all. The only thing we care about for now is that we have a channel between the target peer (see my proposal on how we can lift this requirement).
In other words, we can make this a competely stand alone sub-system, using the actor package.
I described this in another PR, but we'd have two actors:
- the processor:
- In the
readHandler, we read each onion message off the wire, then send it to the proecssor. - The processor takes the onion message, and transform it to figure out where to send it next. It sends it to an onion endpoint for each peer.
- In the
- The onion endpoint:
- When a peer connects, we make an instance of this actor, but only if it has the feature bit.
- It just takes in the incoming message, and sends the onion message to the direct peer, via an interface.
There was a problem hiding this comment.
You know that I love the actor package. But that PR (#9820) hasn't been reviewed yet. Adding yet another PR dependency to the onion messaging epic will make it unlikely that this will be merged anytime soon...
There was a problem hiding this comment.
I think we should really aim for not building on top of this logic, because the onion messages shouldn't be piped through the switch, let's push for the actor package
|
|
||
| // isOnionMessage is a flag that indicates whether the iterator is for | ||
| // an onion message. | ||
| isOnionMessage bool |
There was a problem hiding this comment.
Same here, generally I think we can reduce the invasiveness of this diff, and make it much easier to review with my suggestion above.
| return nil, routeRole, err | ||
| } | ||
| if !isOnionMessage { | ||
| relayInfo, err := routeData.RelayInfo.UnwrapOrErr( |
There was a problem hiding this comment.
Yep, we wouldn't need to tangle with this code at all, just slightly duplicating the existing blinded paths processing code.
| }, | ||
| } | ||
|
|
||
| resps, err := o.onionProcessor.DecodeHopIterators( |
There was a problem hiding this comment.
IIUC, this'll also actually cause us to hit disk for replay protection. Thinking about it a bit more: is any replay protection even defined for onion messaging?
There was a problem hiding this comment.
Yes, it does. I just piggy-backed on the replay protection that's already in place in lightning-onion: https://github.com/gijswijs/lightning-onion/blob/8c58f1d4431b8d95b7c93d30d97809849d5491e1/sphinx.go#L640-L641
AFAIK there's nothing spec-wise that defines replay protection for onion messaging. I've been struggling with this a bit, but chose to keep the protection we already have.
There was a problem hiding this comment.
yeah no need for reply protection.
| // forwarding information for an onion message. It contains either | ||
| // next_node_id or short_channel_id for each non-final node. It MAY contain | ||
| // the path_id for the final node. | ||
| bytes encrypted_recipient_data = 5; |
There was a problem hiding this comment.
If this is intended for users to consume, shouldn't this be decrypted?
There was a problem hiding this comment.
I'm not sure we even need this OnionMessageUpdate to be honest.
I needed it so that I could have itests that allowed me to test e2e onion messaging: Use SendOnionMessage to kick things of at Alice's end, and use SubscribeOnionMessages at Dave's end to see if everything comes through as expected.
That being said, if somebody would like to build something on top of onion message support (like LNDK is built on top of SubscribeCustomMessages), you would need SubscribeOnionMessages and you would want this to be decrypted.
peer/brontide.go
Outdated
| OnionMessageServer *subscribe.Server | ||
|
|
||
| // OnionMsgSender is a function that sends an onion message to any peer. | ||
| OnionMsgSender func([33]byte, *btcec.PublicKey, []byte) error |
There was a problem hiding this comment.
Why do we need this vs just the existing SendMessage method we have? It can submit just the dest and the wire message.
There was a problem hiding this comment.
Because we need to send it to a different peer. We receive the message from a peer, but we need to forward it to another peer, so we need the brontide instance of that peer. So that's why we drop in the SendOnionMessage from server.go. There we use FindPeerByPubStr and use the SendMessageLazy of that peer. I've never liked it as well, and maybe I've overlooked something, so I'm happy to improve.
|
Since #9868 has been merged, I think this needs to be updated, wanna take a look. |
|
@gijswijs, remember to re-request review from reviewers when ready |
gijswijs
force-pushed
the
onion-messaging-1
branch
2 times, most recently
from
5a7e61d to
dbb64f4
Compare
In this commit, we add two new fundamental data structures: Future[T] and Promise[T]. A future is a response that might be ready at some point in the future. This is already a common pattern in Go, we just make a type safe wrapper around the typical operations: block w/ a timeout, add a call back for execution, pipeline the response to a new future. A promise is an intent to complete a future. Typically the caller receives the future, and the callee is able to complete the future using a promise.
This message type is a message that carries an onion-encrypted payload used for BOLT12 messages.
This commit creates the necessary endpoints for onion messages. Specifically, it adds the following: - `SendOnionMessage` endpoint to send onion messages. - `SubscribeOnionMessages` endpoint to subscribe to incoming onion messages. It uses the `msgmux` package to handle the onion messages.
The only way to unblock SendCustomMessage is if the peer activates, disconnects or the server shuts down. This means that if the context is cancelled, we will still wait until one of those other events happen. With this commit we thread the context through to SendCustomMessage, so that if the context is cancelled, we can return early. This improves the cancellation semantics.
Simplify the struct by removing un-used methods and outdated comments.
Remove the 2 sources of truth here. If we have a signature for the node, then we have the announcement.
Add a version field to models.Node and a V1 constructor for it.
Remove various unused fields and methods.
yyforyongyu
force-pushed
the
0-21-0-staging
branch
from
57eb251 to
6fcdbbb
Compare
This tests was a temporary helper to let devs test the graph SQL migration before it was plugged in to LND. But that migration has now shipped and so we can remove this.
Copy over all the code that the graph SQL migration needs to a separate folder. This will let us advance the main graph SQL CRUD code without worrying about changing the sql migration code. It will also let us change the SQL queries without changing the migration. In this commit, only the migration logic is "frozen" but in an upcoming commit, the sqlc queries & models will be frozen too.
There was a problem hiding this comment.
Nice to finally being able to forward onionmessages.
My main points are:
- I agree with Laolu here, we should definitly not move this logic into the switch.
- You mention in this PR that its all about forwarding onion_message, however in your code logic you add all the decoding and encoding of the finalHopPayload TLVs (including the replyPath) from my understanding this is all not needed. We only want to support forwarding, which means we only care about the Encrypted_Recipient_Data in this PR and treat all the other TLV types as not known. This helps to keep the PR way smaller and we would only introduce the other types when needed.
|
|
||
| const ( | ||
| // finalHopPayloadStart is the inclusive beginning of the tlv type | ||
| // range that is reserved for payloads for the final hop. |
There was a problem hiding this comment.
the spec however says in case they are odd intermediate nodes don't need to fail it how are we planning to do it:
Field numbers 64 and above are reserved for payloads for the final hop, though these are not explicitly refused by non-final hops (unless even, of course!).
| return &OnionMessagePayload{} | ||
| } | ||
|
|
||
| // Encode encodes an onion message's final payload. |
There was a problem hiding this comment.
I think the comment is off it encodes thee whole OnionMessagePacket ?
There was a problem hiding this comment.
Nit: Moreover I think we should add a comment to funcions which are part of an interface something like:
// This is part of the lnwire.Message interface
| // NextNodeID is the public key of the next node in the route. This is | ||
| // used by onion messages that do not necessarily care about the channel | ||
| // ID. | ||
| NextNodeID *btcec.PublicKey |
There was a problem hiding this comment.
I think we should really aim for not building on top of this logic, because the onion messages shouldn't be piped through the switch, let's push for the actor package
| }, | ||
| } | ||
|
|
||
| resps, err := o.onionProcessor.DecodeHopIterators( |
There was a problem hiding this comment.
yeah no need for reply protection.
| EncryptedData []byte | ||
|
|
||
| // FinalHopPayloads contains any tlvs with type > 64 that | ||
| FinalHopPayloads []*FinalHopPayload |
There was a problem hiding this comment.
I think we should add ExtraOpaqueData in this struct
| } | ||
|
|
||
| // Decode decodes an onion message's payload. | ||
| func (o *OnionMessagePayload) Decode(r io.Reader) (*OnionMessagePayload, |
There was a problem hiding this comment.
I do not understand this function signature, you change the pointer receiver and then you return it, that looks awkward ?
| } | ||
|
|
||
| // Create a primitive record that just writes the final hop | ||
| // payload's bytes directly. The creating function should have |
There was a problem hiding this comment.
Nit: what do you mean by "directly" here ?
| finalHopPayloadStart tlv.Type = 64 | ||
|
|
||
| // replyPathType is a record for onion messaging reply paths. | ||
| replyPathType tlv.Type = 2 |
There was a problem hiding this comment.
So accroding to he spec the reply path does only make sense for the final hop, however it is not in the range of the final hp tlv type. Wonder what the design design here was ?
| } | ||
|
|
||
| // ReplyPath is a blinded path used to respond to onion messages. | ||
| type ReplyPath struct { |
There was a problem hiding this comment.
why not just use:
type ReplyPath sphinx.BlindedPath ?
| */ | ||
| rpc SubscribeOnionMessages (SubscribeOnionMessagesRequest) | ||
| returns (stream OnionMessage); | ||
| returns (stream OnionMessageUpdate); |
There was a problem hiding this comment.
could you explain to me why you changed this to Update ?
…Freeze graph/db: freeze the SQL migration code
gijswijs
force-pushed
the
onion-messaging-1
branch
from
e1738ce to
6b32c24
Compare
The new wire message defines the OnionMessagePayload, FinalHopPayload, ReplyPath, and related TLV encoding/decoding logic.
Use fork github.com/gijswijs/lightning-onion at commit fac332540872 to include onion-messaging support before the upstream PR is merged. This temporary replace in go.mod ensures compatibility with the current module path while allowing local development and CI to build with the new functionality.
With this commit we implement the logic to parse, decrypt, and forward onion messages. It contains a refactor to its constructor to accept dependencies like the onionProcessor and a message sender function. In brontide.go and server.go it adds the plumbing to for passing through the onionProcessor from the hop iterator and the SendOnionMessage function to the OnionEndpoint's constructor.
Adds the NewNonFinalBlindedRouteDataOnionMessage function to create blinded route data specifically for onion messages.
With this Update we change the SubscribeOnionMessages RPC to return a stream of OnionMessageUpdate messages instead of OnionMessage. This way we also send back the decrypted payload if any, so we can inspect that in itests.
Adds the new integration test file to test forwarding of onion messages through a multi-hop path.
gijswijs
force-pushed
the
onion-messaging-1
branch
from
6b32c24 to
64828aa
Compare
* actor-mailbox-v2: actor: refactor Actor to use Mailbox interface actor: add tests for mailbox implementation actor: introduce generic Mailbox interface with iter.Seq support actor: add README.md actor: add example files actor: add the actor system and router actor: add fundamental interfaces and concrete Actor impl actor: add Future[T] and Promise[T] w/ concrete impls actor: add new actor package as distinct sub-module
yyforyongyu
force-pushed
the
0-21-0-staging
branch
from
706b22a to
95b84a8
Compare
7 participants
With this PR we add basic forwarding functionality for onion messages. It builds on PR #9868.
It adds
OnionMessagePayloadstruct to thelnwirepackage.It also depends on the not yet merged (PR 68)[https://github.com/lightningnetwork/lightning-onion/pull/68] in the
lightning-onionpackage. For now it uses that package from a forked version.The
msgmuxendpoint for onion messages is updated to parse the onion message packet, and forward the onion based on the acquired information.The
SubscribeOnionMessagesendpoint is updated to pass along any decrypted information. This endpoint is currently solely meant for itests, although it could have practical use in the future.