Open ellemouton opened 1 month ago
Would this be incoming last hop peer or incoming channel?
Would this be incoming last hop peer or incoming channel?
good point. So on an instruction level, we tell the peer the next channel to send on. But due to non-strict forwarding, nothing stops them from choosing a diff channel that the one instructed I guess.
Interesting! Maybe it is a good chalange to me!
Feel free to give it a go @MPins :)
Thanks! Starting from the blinded paths proposal, then the code ;-)
Might make more sense to make this more general: Allow user to specify the whole path or parts of the path (cc @alexbosworth )
Hi @MPins assigned the issue to you
Hello all, to do some tests before coding I've just created a network with some 0.18.2 nodes on Polar Lightning and it seems that those nodes do not know blinded paths, but it is available since 0.18.0!!!
Hi @MPins I don't think you'll be able to test blinded paths with 18.2, you'd need 18.3
Release 18 had all the code changes to enable blinded paths, but the implementation and inclusion with the rpcs on LND has been done with 18.3
specify the whole path or parts of the path
To do that we could work with a json object, where the user choose the introduction node (optional), blinded nodes (at least one) and channels (optional). Example:
{
"blinded_path": {
"introduction_node": "node_id",
"blinded_hops": [
{
"blinded_node": "node_id",
"channel": "channel_id"
},
{
"blinded_node": "node_id",
"channel": "channel_id"
},
{
"blinded_node": "node_id",
"channel": ""
}
]
}
}
But particularly I think it is too much flexibility. From the node runner point of view I think that choosing the last hop node or/and channel would be enough. What do you think?
When creating a blinded payment path for an invoice, we should allow the caller to select the channel they want to receive on. This will allow them to force a sender to pay over a specific channel and so gives them an extra liquidity control lever.