Prefer direct routes when paying - alternate solution - #2168
Conversation
a3e3155 to
d89191d
Compare
cdecker
left a comment
cdecker
left a comment
There was a problem hiding this comment.
This is much nicer than the other PR, but wouldn't just skipping the last fee computation have the same effect?
| * @param from - the node that is the ultimate source of the | ||
| * payment. | ||
| * @param chan - the channel to consider. | ||
| * @param idx - which half of the channel to consider. 0 or 1. |
There was a problem hiding this comment.
We commonly call this direction.
There was a problem hiding this comment.
The data structure is called half_chan and the field is half[2], but I suppose direction (half_chan) would be okay.
| hops[i].amount = total_amount; | ||
| hops[i].delay = total_delay; | ||
| total_amount += connection_fee(c, total_amount); | ||
| total_amount += connection_fee(sourcenode, route[i], idx, total_amount); |
There was a problem hiding this comment.
I'm wondering if we should simply skip this addition if i==0 since that'd be the hop that we are in control over anyway. That'd avoid having to thread an additional argument in and do the check in another function.
There was a problem hiding this comment.
connection_fee is used in both this and bfg_one_edge.
We could argue for moving the check to bfg_one_edge, but properly, the source node charges no fee to itself for forwarding, so I thought, more appropriate at connection_fee.
No, as that is done, once a route has been chosen. |
…rging 0 fees. Aside from being accurate, this strongly biases us towards direct channels.
d89191d to
b9c64c3
Compare
|
In the initial implementation I decided to keep the weighting because I figured it reflected our own desires for usage (e.g. we dropped fee on one channel because we wanted more traffic there). What I don't understand is why this would change anything? I suppose now the cost comparison is X vs 0, whereas it was 2X vs X? |
Yes. Further, route randomization fuzz is a random multiplier, so 0 removes the effect of random fuzz. |
Interesting. I forgot to ask about randomization, but a 0 here seems to solve this issue :-) Any major objections @rustyrussell ? |
|
I think we're addressing the symptoms; this is just the most obvious bad decision we make with routing. By default we use riskfactor of 1, and fuzz of 5% (75% for getroute, though I have a patch pending for that). That means a 6-block delay is calculated to cost us about 0.01%, which is lost in the noise of typical fees on the network. In effect, if someone is offering a free route, we'll not bias against it. Increasing the default riskfactor to a more-realistic 10 will change this to be comparable with the 0.1% people are charging in practice. |
|
I wish this was merged. I created direct channel in the expectation of having higher latency for payments to a specific party. I was bit sad to see it was not working that way. :( |
|
would be nice to get in 0.6.3 |
@ZmnSCPxj pointed out that we sometimes select indirect routes when a direct route is available. This is because the riskfactor is so small that it gets overwhelmed in practice by our fuzzing of fees. There were several proposed fixes, but it does imply in general that a riskfactor of 1 is too low for the network. This patch changes the default and updates the recommendation in the getroute man page. Closes: ElementsProject#2168 Closes: ElementsProject#2144 Fixes: ElementsProject#2119 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
4 participants
Fixes: #2119
Closes: #2144
Alternate solution that tweaks
connection_feeso it gives 0 fees for direct channels.