simln-lib/feat: Surface send_to_route for SimGraph #268
Conversation
simln-lib/src/sim_node.rs
Outdated
| /// Uses the provided `hops` and `amount_msat` to build an LDK route. | ||
| /// This is a helper function to build a route easily. | ||
| /// The route built using this function can be passed into `SimGraph::send_to_route`. | ||
| pub fn build_payment_route( |
There was a problem hiding this comment.
Hm, not sure that we need this helper for an advanced user?
Perhaps we an just point to build_route_from_hops on the docs for send_to_route?
simln-lib/src/sim_node.rs
Outdated
| }) | ||
| } | ||
|
|
||
| pub async fn send_to_route( |
There was a problem hiding this comment.
I'm not sure about adding this in SimGraph - feels like a layering violation. I can see how the discussion on the issue was a bit ambiguous - should have pointed out that it should still go on the node even though we don't need to implement it on the other types.
I think that this should live on SimNode so that we can re-use the infrastructure that's already there (eg, we wouldn't need another track payment function, we already have it).
I think it's reasonable to expect the end user to look up the dispatching node that they want and then call SimNode.send_to_route.
chuksys
force-pushed
the
surface-send-to-route
branch
from
bd09d2b to
b1db235
Compare
|
I didn't add any test cases this time around since |
chuksys
force-pushed
the
surface-send-to-route
branch
from
e7684ad to
f7f511a
Compare
| let preimage = PaymentPreimage(rand::random()); | ||
| let payment_hash = preimage.into(); |
There was a problem hiding this comment.
Hm I wonder whether there's any use for people to pass in their own payment hash?
WDYT, I'm on the fence...
There was a problem hiding this comment.
I think this could be helpful if the user wants to simulate payments in an application that relies on a custom payment flow - for example the user could have a payment flow that requires generating the preimage and hash much earlier in their process, perhaps for coordination with other parts of their application, well before the send_to_route method is called.
I think allowing users to pass in their own payment hash would give them the flexibility to accurately model such scenarios.
| let payment_hash = preimage.into(); | ||
|
|
||
| // Check for payment hash collision, failing the payment if we happen to repeat one. | ||
| match self.in_flight.entry(payment_hash) { |
There was a problem hiding this comment.
Let's just add one test case that covers sending / tracking a payment with this API - good to have the coverage.
| @@ -527,6 +527,33 @@ impl<'a, T: SimNetwork> SimNode<'a, T> { | |||
| scorer, | |||
| } | |||
| } | |||
|
|
|||
| /// The [`lightning::routing::router::build_route_from_hops`] function can be used to build the route to be passed here. | |||
There was a problem hiding this comment.
Nit: also note what this function does in the public doc, specifically that it dispatches the payment but it still needs to be tracked for a payment outcome.
Description
This PR makes it possible for a user of simln-lib (in sim-node mode) to send payments to a predetermined route. This addresses the need for end-users to send custom payments, crucial for scenarios like channel jamming attacks or pathfinding experiments, which the current activity paradigm doesn't support.
Changes
send_to_routemethod was added toSimGraph.track_payment_to_routemethod was added toSimGraph.build_payment_routehelper function was added.This PR closes #257