Last three weeks I've been working on improving payments. Critical to this are five things:
1. Better payment routing, a-la min-cost-flow.
2. Better low-level payment injection API
3. Simpler, more reliable implementation.
4. Better simulation and realistic testing.
5. Better gossip maintenance.
For the first, I took the heart off renepay to make "askrene" the payment oracle, which provides "getroutes" for other plugins to use. A primitive version shipped in the current release, but it's already getting better as I start to use it.
Today I finished "injectpaymentonion" which takes incoming payments the same way we deal with incoming HTLCs, unifying things that were previously difficult, like self-pay and bolt12 blinded paths that begin at our own node.
Tying these together is a new plug-in called "xpay". This calls getroutes then injectpaymentonion, then iterates as results come back, feeding back information to askrene as we learn more about the network.
To figure out how well this actually performs, I've got a new format for representing topology, with minimal information (no node names, just channel capacities, details and topology). A simple tool compresses this from a node's gossip store (and decompress back for use). The result is small enough that we can include graph snapshots on our repository for testing.
Then I have written a fake "channeld" which simulates payments through this graph (it knows all the secret keys). This needs to be enhanced with simulating capacity of the channels (deterministically, based on a seed value) and realistic network delays, but it already does MPP timeouts and checks fees and cltv delays.
This should allow me to test this system's performance in a way that mirrors what people actually see, and also measure it against what we have now. It may uncover bugs, but even better it will let me know where to optimize (min cost flow can definitely be a CPU hog!).
And endothermicdev (nprofile…zu7w) is working on ideas for more aggressive gossip gathering: if we're missing part of the map we cannot expect to have reliable payments!
Rusty Russell
npub179…elz4s
2024-09-18 09:38:53
Author Public Key
npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4sPublished at
2024-09-18 09:38:53Event JSON
{
"id": "0c67b42e58780349c88e5eeccfc677e1431ca91dc9b2bf7c31460b25049941d8",
"pubkey": "f1725586a402c06aec818d1478a45aaa0dc16c7a9c4869d97c350336d16f8e43",
"created_at": 1726652333,
"kind": 1,
"tags": [
[
"p",
"6a46242f4d73c14e114d95e1336439f5b91189571dd9c2d4fa418db018cb8ef5",
"",
"mention"
]
],
"content": "Last three weeks I've been working on improving payments. Critical to this are five things: \n1. Better payment routing, a-la min-cost-flow.\n2. Better low-level payment injection API\n3. Simpler, more reliable implementation. \n4. Better simulation and realistic testing. \n5. Better gossip maintenance. \n\nFor the first, I took the heart off renepay to make \"askrene\" the payment oracle, which provides \"getroutes\" for other plugins to use. A primitive version shipped in the current release, but it's already getting better as I start to use it. \n\nToday I finished \"injectpaymentonion\" which takes incoming payments the same way we deal with incoming HTLCs, unifying things that were previously difficult, like self-pay and bolt12 blinded paths that begin at our own node.\n\nTying these together is a new plug-in called \"xpay\". This calls getroutes then injectpaymentonion, then iterates as results come back, feeding back information to askrene as we learn more about the network. \n\nTo figure out how well this actually performs, I've got a new format for representing topology, with minimal information (no node names, just channel capacities, details and topology). A simple tool compresses this from a node's gossip store (and decompress back for use). The result is small enough that we can include graph snapshots on our repository for testing.\n\nThen I have written a fake \"channeld\" which simulates payments through this graph (it knows all the secret keys). This needs to be enhanced with simulating capacity of the channels (deterministically, based on a seed value) and realistic network delays, but it already does MPP timeouts and checks fees and cltv delays. \n\nThis should allow me to test this system's performance in a way that mirrors what people actually see, and also measure it against what we have now. It may uncover bugs, but even better it will let me know where to optimize (min cost flow can definitely be a CPU hog!).\n\nAnd nostr:nprofile1qqsx533y9axh8s2wz9xetcfnvsultwg339t3mkwz6nayrrdsrr9caagpzpmhxue69uhkummnw3ezumt0d5hsdqzu7w is working on ideas for more aggressive gossip gathering: if we're missing part of the map we cannot expect to have reliable payments!",
"sig": "c4dcf4b80ae3e5664456bbc4f7f097ea5a8fb1db6db875247d2db1f4de273162cc1fea5c0c3e9e97f4ca13e7ccbb4ad208d99e28b1b81e8d9a8a0002c06f2bff"
}