-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the option on path creator to specify the incoming channel on blinded path #9127
base: master
Are you sure you want to change the base?
Conversation
Hello @ellemouton if you think I'm on the right way I can add the option to choose a channel also. |
Maybe change the name to "incoming_node" is a better idea! But I'll wait for others opinion also. |
thanks @MPins - in tokyo at the moment for the LN summit so will take a look at this a bit later this week or next week |
I think it makes sense to just specify the incoming channel, I don't see a lot of use cases for the whole blinded route, but maybe we already prepare the code so that it will be easy to just upgrade to the whole blinded path if it has benefits. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your first contribution 🎉
Please squash all commits related to the lnrpc change into one.
Moreover while reviewing this PR I found out that we have a bug in your probabiliy calculation. We basically should have the prob. of full certainty for the last hop however we need to change the logic in our probability estimator which still seems to not account for the blinded usecase see here (only when from == Self
do we set the full local probability, that needs to now be inverted for the last hop as well):
Lines 509 to 526 in 2d33317
func (m *MissionControl) GetProbability(fromNode, toNode route.Vertex, | |
amt lnwire.MilliSatoshi, capacity btcutil.Amount) float64 { | |
m.mu.Lock() | |
defer m.mu.Unlock() | |
now := m.cfg.clock.Now() | |
results, _ := m.state.getLastPairResult(fromNode) | |
// Use a distinct probability estimation function for local channels. | |
if fromNode == m.cfg.selfNode { | |
return m.estimator.LocalPairProbability(now, results, toNode) | |
} | |
return m.estimator.PairProbability( | |
now, results, toNode, amt, capacity, | |
) | |
} |
In most cases it would be sufficient to specify the node, the channel must be specified in cases where there is more than one channel with the same node. Of course, specifying the channel covers both use cases. I'm not sure if we should keep both options for the user, perhaps it would be more intuitive to specify the income node for most users. |
I prefer the channel, because than you have more control rather than the pubkey. But at the end not sure if its really worth it to treat different channels to the same peer differently because we have non-strict forwarding. So probably both options are ok ... |
Thank you for your carefully revision. I'll be working on it some time on the following days. About the probability, I invest some time trying to understanding it, but I didn't get the bug on it! From my understanding, probability is about sending the payment, right? How the payment node would even know that we are choosing the income channel/node? I'm probably missing something, I would appreciate if you give me directions to expand my understanding. |
I think we can move forward with both options, but in my opinion they should be exclusive. I mean, if the channel is chosen, the node cannot be chosen. (just to avoid redundant info) |
So my initial idea was, that we can know the probability of the last channel in a blinded path with very high accuracy because its our own channel and we know the liquidity distribution when creating the blinded path. However looking into the codebase I think we should keep it as is, we do allow MPP payments for blinded paths so the amount can be splitted among the incoming channels in general. Moreover when we specify the incoming channel to receive on (via this PR) we already made the decision that this is the right channel to receive on the full amount, so maybe we can keep the probability estimation of the last hop/channel as is. Given the fact that we include all routes with a minimum route prob. of 1% we are good as is I think. |
Got it ... besides that, as it is blinded I can't think a way of considering that it is our own node without breaking the main reason for using a blinded path, that is not revealing our own node on a invoice. |
Hmm not sure what you mean, but I was just referring to the creator of the blinded path taking the incoming channel distribution directly into account without really relying on the MC data. The path would still be blinded for the sender so the sender would just have a sorted list of blinded paths in the bolt11 invoice. |
Never mind ... I was thinking that the GetProbability func would be called when the payment is being processed by the sender. |
I just saw that it is called by FindBlindedPaths ... Thank you, I have a better understanding of the whole process now. I think you right ... maybe it should be changed ... not sure if it should be included in this PR or maybe on a specific one for that. |
Have a basic question here.
So why are we then giving the user the control of selecting a node in the cli, instead of directly specifying a channel? |
The idea to have the option to specify the node instead of the channel is because in the most cases it would be enough and from the node runner perspective it would be more intuitive specifying just the income node. |
Good question, I also tend to only support the incoming channel id why:
|
Imagine your peer has 2 channels with you and different policies, now when creating the blinded path and using the nodeid, you cannot control the particular channel and the sender will probably use the route with the better constraints. We already have something similar when sending a payment where we can select the outgoing channel. We should prob. stick to this form. |
I think that
When sending payment you can also choose the last hop (penultimate node in the path) to route through for the payment, but it is other use case. So I think you both are right, I'm going to take the node option out. |
Good observation that we also allow the last hop in the payment flow, but LND does unify the edges in the sending flow and selects the most expensive policy that's why it makes sense to have this last hop setting. |
Perfect ... I'm going to take the node option out. Thank you @saubyk for starting this exchange of ideas. |
Thanks. Not to add the confusion, but I do understand the logic of selecting the node from a UX standpoint and especially when you imagine a user doing it in a UI. Selecting a pub key (with an alias) is much easier than selecting a channel ID. But I think that problem can be addressed at the application level, where the UI can establish that node-channel linkage and present a user friendly way for the user to make a selection. |
The problem is that you dont actually every have this control due to non-strict forwarding. At the end of the day, the peer may choose any channel to fwd on as long as the peer on the other end is the same peer. Regarding the impl here and if we only want to specify final hop or list of hops, I think things should be made general enough for both:
|
The way it is done here the user can specify the last hop many times (peers or channels, not both). If I understand you correctly it should be kept this way. Right? |
@ellemouton what's your take on this, we cannot really know whether peers have a universal policy to us?
|
@ziggie1984 - yes that makes sense but my point is that nothing stops the peer from in any case just choosing the channel they want to choose. If you peer has channel X and Y with you, and you tell them to use channel X, nothing stops them from using channel Y |
Correct that's for the perspective of the forwarding node, but let's look at it from the receiving node: You have channel X and Y, both have different Policies, now you create your invoice specifying the last hop via the nodeid, you get 2 blinded paths most likely (or more). The sender will probably select the path with the best constraints, hence the receiver lost a bit of control while specifying the invoice. If he could have specified the channelid he would not put both paths into the invoice. I agree with you statement when policies are equal the sender can choose both channel X or channel Y and specifying the nodeid here makes sense. However when the policies are different it makes sense for the receiver to have more control specifying the channelid not the nodeid. Thats why I proposed only going with the chanid, which is basically valid for both options, rather than going with only nodeid, or both (which increases complexity). |
Do you favour the approach of providing a whole path not just the last channel ? Could not think of a use case where we would like to specify the whole path ? |
Do you mean a list of final hops or all the blinded path? As @ziggie1984 said I can't imagine also a use case for that. 🤔 |
@ziggie1984 - ok gotcha gotcha - thanks for the explanation 🙏 cool yeah then chan-id only makes sense! |
I think things should just be made general enough to specify as many chained channels as you'd like. This can be useful in future where you want to force a payment to go via a specific hop for example. I just think we should build it in a general enough way to cater for this |
good idea let's do that! |
@ziggie1984 and @ellemouton Great ... Let's do it ... What do you think it is the more appropriate way of getting the chained channels? I was thinking of comma separated channel ids! There is something like that on |
maybe also support both chanid formats: the integer but also the blockheightXTxNumberXOutput for example:
|
Maybe it is more appropriated to leave this format |
14a0216
to
b07acbe
Compare
It was made general enough to specify chained channels hops.
It was made general enough to specify chained channels hops.
It was made general enough to specify chained channels hops.
It was made general enough to specify chained channels hops.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks already good 👍, had some questions.
@@ -116,6 +117,11 @@ var AddInvoiceCommand = cli.Command{ | |||
"use on a blinded path. The flag may be " + | |||
"specified multiple times.", | |||
}, | |||
cli.StringSliceFlag{ | |||
Name: "blinded_path_income_channel", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
blinded_path_income_channel
=> blinded_path_incoming_channel_list
Usage: "The chained channels ids to be used in a " + | ||
"blinded path as the income hops.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usage: "The chained channels ids to be used in a " + | |
"blinded path as the income hops.", | |
Chained channels (specified via channel id) starting from the receiver node which shall be used for the blinded path. |
|
||
// channelIncomeSet holds a chained channels that we | ||
// should use as income hops during blinded path selection. | ||
channelIncomeSet []uint64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
channelIncomeSet => incomingChainedChannels
, because its not a set
@@ -1300,6 +1304,16 @@ func processNodeForBlindedPath(g Graph, node route.Vertex, | |||
// node that can be used for blinded paths | |||
err = g.ForEachNodeChannel(node, | |||
func(channel *channeldb.DirectedChannel) error { | |||
// If this channel was included into the chained | |||
// channel route. | |||
chanInSet := restrictions.channelIncomeSet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to me that this logic will actually produce a path with 2 chained channels if the third one is not found or is not a valid one (not existent), I wonder if we should allow this, I think as soon as the Incoming Channels are specified we should just construct this explicit route.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually it will produce any path and it will fail. I've just tested it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you mean no route is created if you specify more channels and the last one is not found ?
can you detail your testcase, minNumberHops
etc ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean no route is created. This is the test I did:
lncli addinvoice --blind --min_real_blinded_hops 3 --num_blinded_hops 3 --blinded_path_income_channel 264982302359552,200111116320768,189116000043009 50000
The first two chained channels exist but the third one does not. No route is created.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ahh makes sense because of -min_real_blinded_hops 3
but should we always force the user to also select the right -min_real_blinded_hops
value ? or should the selection of the incoming channel imply the former, would prefer the latter
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @saubyk ... we are following the @ellemouton idea of making it general and accept chained channels for future purposes
Now we are facing the scenario where the number of chained channels is bigger than --num_blinded_hops . The way it is done, it returns no route. Maybe we can stop here!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In regards of your change, you basically put the check to early, thats why routes where not created because the channel count was not increase this has to be done after:
// Keep track of how many incoming channels this node
// has. We only use a node as an introduction node if it
// has channels other than the one that lead us to it.
chanCount++
otherwise the first node will never have enough channels as an intro node.
Given this fact you will get a route if you do this (after moving the check before your statement):
lncli addinvoice --blind --min_real_blinded_hops 1 --num_blinded_hops 1 --blinded_path_income_channel 694891348819968,694891348819967 500
{
"r_hash": "64fb793c8b77e56fb9f805c24b4d16cfad2df0b5bf61553cbbd6f4c414a41910",
"payment_request": "lnbcrt5u1pn35fpppp5vnahj0ytwljklw0cqhpykngke7kjmu94has4209m6m6vg99yrygqdqqxqyz5vq5d8qqqqgnqqqqqqzq9tqqqqqqqqqqzycqqqqqppxy70sqqqqqsn4k5k7qzkdgh2qkju4l97a4v7azwqc5k7heqc95mqcpsayywylupqxng35sfferrns4kyr5x94763pznrtw5996kjeg4z2wcp2drr30fvgv5z7qjqlf5csg4wt8n867769xtf0gazk2vl442tlu5yqmsu9ph562v3szux3lf6r2uzjcdadywgcjk9npfvfykjrsmt4skhw5dt7frt566w6q3he0j8em0yaxjemsv2uysfsu4wxyuc2nt4f3vdxdpas6z97pv9h3pe4n72uc32a7k4j8g55metcwfy2m6hy76pd7av9a76t2cwu0darnwpxad9w9u247zw5cxt90hcg2xqmpjgxncknygehg8dxsuznztq5s3vrrg9p4yqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqs9qgq3j59psqxgyn2mwlugf2cukwg42fw7l9m2a6k4mpzuldf22rx3x64f3tceru50pwteqg38xh3k5kxwu89q7qz6gsxwhutlkykq6pfsxspahcgz3",
"add_index": "6",
"payment_addr": "9a8fe879211540cb422cc39b45776c507680c08a0d35baa45f11e97715d5ecce"
}
So I propose just going first with 1 incoming channel, because for the UX we definitely need some improvement to support chained routes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I agree with @saubyk here and fist go with the incoming channel and add complexity later if we need it.
Sorry for the back and forth but I did not think of these kind of UX challenges when adding the whole route.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem at all ... I'm learning a lot during the process 👍 Appreciate your careful review of the code.
So, I'll be changing the code and the rpc parameter name to reflect just one income channel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm I dont agree - let me chat to ziggie offline a bit
@@ -6048,6 +6049,12 @@ func (r *rpcServer) AddInvoice(ctx context.Context, | |||
|
|||
blindingRestrictions.NodeOmissionSet.Add(vertex) | |||
} | |||
|
|||
blindingRestrictions.ChannelIncomeSet = append( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it makes sense to check here if the selected channels exist in our graph here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have mixed feelings with this kind of verification 😄 ... it will produce no route ... and will not spend a lot of resources to do that.
Maybe we can add it to the lncli level, but no hard feeling if we only keep the int representation |
I had a discussion with Elle today about the way forward, and we both agreed to proceed with the chained channel feature approach. Additionally, there is no need to rush this feature in an incomplete form. Below is a list of what this PR should include before we can consider it for merging:
Feel free to ask any questions here or on slack, happy to help you out. cc @ellemouton |
It'll be good to understand the justification or the use case for specifying a chain of channels, instead of just one direct channel. What specific problem is getting addressed with the chain? |
For example you want to make sure a payment passes a particular channel along the route so that you proofed this payment happened, when you are interacting with a service provider |
Fixes #8993
Change Description
Add the option on path creator to specify the incoming node setting a list of penultimates nodes
Steps to Test
lncli addinvoice --blind --blinded_path_penultimate_node "node_id" amount
lncli addinvoice --blind --blinded_path_penultimate_node "node_id1" --blinded_path_penultimate_node "node_id2" amount
Pull Request Checklist
Testing
Code Style and Documentation
[skip ci]
in the commit message for small changes.📝 Please see our Contribution Guidelines for further guidance.