Commit Graph

10 Commits

Author SHA1 Message Date
e47024b790 routing: Use NUMS point for blinded paths
To be able to do MPP payment to multiple blinded routes we need
to add a constant dummy hop as a final hop to every blined path.
This is used when sending or querying a blinded path, to let the
pathfinder be able to send MPP payments over different blinded
routes. For this dummy final hop we use a NUMS key so that we
are sure no other node can use this blinded pubkey either in a
normal or blinded route.
Moreover this helps us handling the mission control data for
blinded paths correctly because we always consider the blinded
pubkey pairs which are registered with mission control when
a payment to a blinded path fails.
2024-12-10 19:05:49 +01:00
ed2989ae33 multi: update to fn v2 2024-12-04 13:19:00 -07:00
9f54ec90aa multi+refactor: move models package to graph/db
All the structs defined in the `channeldb/models` package are graph
related. So once we move all the graph CRUD code to the graph package,
it makes sense to have the schema structs there too. So this just moves
the `models` package over to `graph/db/models`.
2024-11-28 13:34:33 +02:00
8df03de3e9 routing: swap out final hop blinded route pub keys
If multiple blinded paths are provided, they will each have a different
pub key for the destination node. This makes using our existing
pathfinding logic tricky since it depends on having a single destination
node (characterised by a single pub key). We want to re-use this logic.
So what we do is swap out the pub keys of the destinaion hop with a
pseudo target pub key. This will then be used during pathfinding. Later
on once a path is found, we will swap the real destination keys back in
so that onion creation can be done.
2024-07-31 09:14:31 +02:00
f7a9aa875e routing+refactor: let BlindedEdge carry BlindedPayment
This commit is purely a refactor. In it, we let the `BlindedEdge` struct
carry a pointer to the `BlindedPayment` that it was derived from. This
is done now because later on in the PR series, we will need more
information about the `BlindedPayment` that an edge was derived from.

Since we now pass in the whole BlindedPayment, we swap out the
`cipherText` member for a `hopIndex` member so that we dont carry around
two sources of truth in the same struct.
2024-07-10 09:12:39 +02:00
738253f5e1 routing: assume TLV onion during path finding 2024-06-24 10:01:21 -07:00
0aeb7c4ba2 multi/refactor: clarify blinded payment fee rate field name 2024-03-27 09:39:00 -04:00
c1b91fff14 multi: use new AdditionalEdge interface.
In the previous commit the AdditionalEdge interface was introduced
with both of its implementations `BlindedEdge` and `PrivateEdge`.
In both cases where we append a route either by a blinded route
section or private route hints we now use these new types. In
addition the `PayloadSizeFunc` type is introduced in the
`unifiedEdge` struct. This is necessary to have the payload size
function at hand when searching for a route hence not overshooting
the max sphinx package size of 1300 bytes.
2024-02-03 12:10:46 +00:00
c9609b8214 multi: add blinded route to route requests expressed as hints
Add the option to include a blinded route in a route request (exclusive
to including hop hints, because it's incongruous to include both), and
express the route as a chain of hop hints.

Using a chain of hints over a single hint to represent the whole path
allows us to re-use our route construction to fill in a lot of the
path on our behalf.
2023-10-06 16:38:33 -07:00
539a275faa routing: add representation of blinded payments
This commit adds a representation of blinded payments, which include a
blinded path and aggregate routing parameters to be used in payment to
the path.
2023-10-06 16:38:33 -07:00