-
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
routing: inbound fees send support #6934
routing: inbound fees send support #6934
Conversation
f121e4b
to
7beb44a
Compare
859464c
to
f940c83
Compare
f940c83
to
73e5422
Compare
73e5422
to
99ed58f
Compare
cbcde71
to
cdac2e4
Compare
Removed exit hop inbound fees. Previous code saved in master...bottlepay:lnd:inbound-fees-send-support-exit-hop |
cdac2e4
to
5c4d210
Compare
fc549fa
to
f9894dc
Compare
f9894dc
to
3fc276e
Compare
signedFee := inboundFee + outboundFee | ||
fee := lnwire.MilliSatoshi(0) | ||
if signedFee > 0 { | ||
fee = lnwire.MilliSatoshi(signedFee) |
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.
@halseth you expressed concerns about negative fees being able to cancel out probability penalties for unreliable nodes. I've addressed the issue here by always rounding the fee that is used for the edge weight up to zero.
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.
👍
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.
Perhaps this check must be removed now that the node total fee is guarded against negative. Otherwise pathfinding may return suboptimal 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.
I am actually quite sure of this. Suppose a node has an in fee of -100000 and an out fee of 100000. Those cancel out perfectly and shouldn't lead to pathfinding that is any different from a zero fee?
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.
But... we still need to do this because dijkstra can't handle negative weights 🤷
It is a possibility though to floor at zero the actual edge weight calculated below rather than the fee.
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 am actually quite sure of this. Suppose a node has an in fee of -100000 and an out fee of 100000. Those cancel out perfectly and shouldn't lead to pathfinding that is any different from a zero fee?
Do you mean that those fees are on a single channel or on a node with incoming and outgoing channels?
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 on a node with incoming and outgoing channels. The fee paid to that particular node would be 0, so you'd expect it to be treated no different from a node that actually charges zero fee.
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.
This could still be a problem, looking into that. edit: left a main comment #6934 (review)
3fc276e
to
e662c77
Compare
I am in favour of the non-optimal cutoff solution for now. I think it is sufficiently good to gather feedback on the inbound fees concept, and - as you say - we can revisit node pair search at a later stage. I've archived the relevant commit on a different branch https://github.com/joostjager/lnd/tree/inbound-fees-node-pair-search. |
54c4988
to
2fb0965
Compare
Important Auto Review SkippedAuto reviews are limited to the following labels: llm-review. Please add one of these labels to enable auto reviews. Please check the settings in the CodeRabbit UI or the To trigger a single review, invoke the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
96903da
to
ca5dd90
Compare
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.
LGTM 🎉 (tested pathfinding in a small network as well).
ca5dd90
to
6370bc1
Compare
Rebased |
@joostjager, remember to re-request review from reviewers when ready |
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.
LGTM 🪞
Considering if we should actually also have a hard reject on the RPC level if users try to set a positive inbound fee. In the future we could lift it given sufficient uptake within the core routing network. We can also add more telemetry using the HTLC interceptor (I think we're missing the field there actually?), which'll allow node operators to log the %
of incoming payments that are able to observe their negative inbound fees.
|
||
fee = int64(outboundFee) + inboundFee | ||
if fee < 0 { | ||
fee = 0 |
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.
Perhaps we should log these occurrences on the Tracef
log level?
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 am not sure. The zero-floor has now become a feature of inbound fees both on the receiver and sender side. Nodes might use that and it doesn't necessary indicate a configuration mistake - if that was the reason you had in mind for logging?
Needs rebase + conflicts addressed. |
dbdd97c
to
49478a6
Compare
Preparation so that we can have the inbound fee available in addition to the outgoing policy.
Add sender-side support for inbound fees in pathfinding and route building.
49478a6
to
0bae781
Compare
Will be possible to set the default inbound fees on |
@twofaktor that makes a lot of sense, I've made a tracking issue for your request here: #8610. Thanks! |
Implements send support for inbound routing fees. The receiver side is implemented in #6703 and this PR is based off of that.
Implementation details
channel_update
extra opaque data isn't validated before it was stored in the database. This means that everywhere we read this data, a tlv error might be encountered. In this PR, this case is handled in a mostly defensive way, skipping over the channel policy.Based on #6703. Review first commits there.
Support for inbound fees in
BuildRoute
is explored in #7060.