simln-lib/feat: Surface send_to_route for SimGraph #268
Conversation
| pub async fn send_to_route( | ||
| &mut self, | ||
| sending_node_id: PublicKey, | ||
| hops: &[PublicKey], | ||
| routing_graph: Arc<NetworkGraph<&WrappedLog>>, | ||
| amount_msat: u64, | ||
| ) -> Result<PaymentHash, LightningError> { |
There was a problem hiding this comment.
Still thinking which approach is better -
- Passing in
hops- which is an ordered list of pubkeys of the nodes to be used to build the LDK route. - Passing in the LDK route directly.
Also, for the use-case of simulating channel jamming attacks, I'm thinking it might be a good idea to pass in a value that we could use to delay the removal of htlcs from channels being targeted - perhaps that could be a follow-up for this PR?
There was a problem hiding this comment.
Since this is a pretty advanced API (you want to do custom payments on top of the regular simulation's payments), I think that we can get away with passing the LDK route directly.
This also gives more flexibility. For example, in my channel jamming case I sometimes want to set a really high CLTV delta (that our pathfinding wouldn't sanely pick) as part of an attack.
There was a problem hiding this comment.
This also gives more flexibility. For example, in my channel jamming case I sometimes want to set a really high CLTV delta (that our pathfinding wouldn't sanely pick) as part of an attack.
I agree - passing the LDK route directly makes a lot of sense. I'll sort this out and push the changes asap!
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