#dev #cln
More work on askrene today. The infrastructure basically done, now I'm stealing Eduardo's min cost flow code.
But even that isn't trivial to drive. You get the min cost flow but the resulting path might be too expensive, or too unlikely, or too slow, and you need to tweak parameters (fees vs probability vs delay) then ask again. The current code does a binary search for this over a mu value from 0 to 127, so 7 times. I need to play with this, as I suspect we can shortcut this if we're "good enough".
Once you've got that, you look at htlc_max and htlc_min that had been published on the channels: you might have violated that too! If you hit the min, you remove that route and block the channel from future attempts. If you hit the max,, you reduce the amount you send down that route. Then you have some sats you still need to send, so you ask the min cost flow solver for the solution for just that part. This is actually unusual though: most channels route most payments.
The question is, how much goes inside the pay oracle, and how much can we punt to the caller? I think the caller can only specify the max fee and max delay, and the oracle needs to give the highest probability routes within those constraints.
I hope to have something tomorrow, but it's going to need a lot of tests! Fortunately this should be easier to test than a complete pay plugin.
Rusty Russell
npub179…elz4s
2024-05-27 09:45:14
Author Public Key
npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4sPublished at
2024-05-27 09:45:14Event JSON
{
"id": "4ca70ed59931772986c1697108becc1a39934399f4fed39748db163d9a1c24b5",
"pubkey": "f1725586a402c06aec818d1478a45aaa0dc16c7a9c4869d97c350336d16f8e43",
"created_at": 1716803114,
"kind": 1,
"tags": [
[
"t",
"dev"
],
[
"t",
"cln"
]
],
"content": "#dev #cln\n\nMore work on askrene today. The infrastructure basically done, now I'm stealing Eduardo's min cost flow code. \n\nBut even that isn't trivial to drive. You get the min cost flow but the resulting path might be too expensive, or too unlikely, or too slow, and you need to tweak parameters (fees vs probability vs delay) then ask again. The current code does a binary search for this over a mu value from 0 to 127, so 7 times. I need to play with this, as I suspect we can shortcut this if we're \"good enough\".\n\nOnce you've got that, you look at htlc_max and htlc_min that had been published on the channels: you might have violated that too! If you hit the min, you remove that route and block the channel from future attempts. If you hit the max,, you reduce the amount you send down that route. Then you have some sats you still need to send, so you ask the min cost flow solver for the solution for just that part. This is actually unusual though: most channels route most payments.\n\nThe question is, how much goes inside the pay oracle, and how much can we punt to the caller? I think the caller can only specify the max fee and max delay, and the oracle needs to give the highest probability routes within those constraints. \n\nI hope to have something tomorrow, but it's going to need a lot of tests! Fortunately this should be easier to test than a complete pay plugin.",
"sig": "0dbf16a148088466e263ed13448ce22116bb4693cf5a9ad3568f1c2d1b31df3b7bafae9e07472562a3b5c693d651e6802af58685000f7478ffbe6448ea48dcdc"
}