multi: add BuildOnion, SendOnion, and TrackOnion RPCs #9489
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The SwitchRPC server will be hidden behind a build tag.
Add RPC for dispatching payments via onions. The payment route and onion are computed by the caller and the onion is delivered to the server for forwarding. NOTE: The server does NOT process or peel the onion so it assumed that the onion will be constructed such that the first hop is encrypted to one of the server's channel partners.
Allow the switch to defer error handling when callers of GetAttemptResult do not provide an error decrypter.
Add RPC to lookup the status of a previously forwarded onion. Allow callers of the TrackOnion rpc to indicate whether they would like to handle errors themselves or delegate error decryption to the server. We take care to return ErrPaymentIDNotFound across RPC boundary to the RPC caller. This will allow the caller of TrackOnion to explicitly confirm that there is no HTLC in-flight for the supplied attempt ID, so it is free to safely re-attempt the payment.
Add RPC which constructs a sphinx onion packet for the given payment route. NOTE: This is added primarily to aid with the itests added later.
This demonstrates how the Switch and SendOnion rpc behave when asked to dispatch duplicate onions. Notably, the Switch circuit map detects this - but only if the matching onion is still in flight. Once the circuit is torn down, the duplicate is permitted by the Switch. It is likely that we will add a layer of protection to the SendOnion call itself to prevent duplicates even after the first HTLC is no longer in-flight. TODO: Determine whether this SendOnion duplication protection should presist across restarts.
Add a memory optimized store for SendOnion/TrackOnion duplication/safe ordering protection. This ensures that if TrackOnion returns PAYMENT_ID_NOT_FOUND or SendOnion initiates HTLC creation for a given attempt ID, SendOnion cannot subsequently succeed with the same attempt ID. This mechanism safeguards against overpayment in scenarios where network requests are reordered. If an attempt ID has already been used by either SendOnion or TrackOnion, SendOnion will return DUPLICATE_HTLC for that attempt ID. Used https://github.com/RoaringBitmap/roaring as a store for attemp IDs.
We can now assert that making multiple calls to SendOnion for the same attempt ID is prevented.
We prevent the rpc server from allowing onion dispatches for attempt IDs which have already been tracked by rpc clients. This helps protect the client from leaking a duplicate onion attempt. NOTE: This is not the only method for solving this issue! The issue could be addressed via careful client side programming which accounts for the uncertainty and async nature of dispatching onions to a remote process via RPC. This would require some lnd ChannelRouter changes for how we intend to use these RPCs though.
|
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Change Description
We add a new
switchrpcRPC sub-system with SendOnion, BuildOnion, and TrackOnion RPCs. This allows the daemon to offload path-finding, onion construction and payment life-cycle management to an external entity (such as a remotely instantiated ChannelRouter type) and instead accept onion payments for direct delivery to the network.switchrpc.Avoiding Duplicate Payment Attempts
We are making send/track(onion) requests which traverse an async and unreliable network. Clients which use these RPCs to make decisions about whether to make additional payment attempts run the risk of a race/re-ordering of request processing misleading them into making a re-attempt when such a re-attempt is not safe to make. We'd like to prevent duplicate payment attempts and unintentional loss of funds by RPC clients.
Consider the following scenario:
DeadlineExceededor serviceUnavailableerror and is unable to distinguish between the request never reaching the server (eg: the server is offline --> safe to re-attempt via different server) and the server receiving the request and being unable to respond in time.Future
InitAttemptstyle method on the Switch store. All duplicates with same attempt ID would be rejected until the result for that attempt ID has been read and cleaned from the result store. Then the attempt ID can be freed for re-use.