Skip to content
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

Positive inbound fees mess with route finding #2901

Open
DerEwige opened this issue Sep 1, 2024 · 6 comments
Open

Positive inbound fees mess with route finding #2901

DerEwige opened this issue Sep 1, 2024 · 6 comments

Comments

@DerEwige
Copy link
Contributor

DerEwige commented Sep 1, 2024

By deactivating a security switch, it is possible to set positive inbound fees on LND nodes.
Channels with positive inbound fees are not backwards compatible and they mess with the route finder in an unexpected way.

If a node (not knowing about inbound fees) tries a route containing a single hop with positive inbound fees, that route will fail.
The failure is “insufficient Fee” at node X. When receiving this error eclair (and all other implementation afaik) will attribute that error to the outbound channel of the node.
But in reality, the error happened on the inbound channel.

By attributing the error to the wrong edge the ability to find routes decreases.
Currently this effect is not very strong, as there are only very few nodes with positive inbound fees.

As eclair currently does not intend to support this version of inbound fees I would suggest to at very least block all channels with positive inbound fees by adding them to the ban list.
Those channels will never work and with this simple trick you will prevent the route finding from slowly falling spiraling into madness.

@t-bast
Copy link
Member

t-bast commented Sep 2, 2024

This is an issue that should be raised to the lnd team. Every implementation was very vocal about the requirement that inbound fee experiments absolutely must not interfere with nodes who don't run that experiment. Positive inbound fees must be negotiated directly with the channel peer exactly to avoid that kind of undesirable behavior.

Can you open an issue on the lnd repository to complain about this behavior? I'll also raise it during the next spec meeting, as this can create large incompatibilities across the network.

@DerEwige
Copy link
Contributor Author

DerEwige commented Sep 2, 2024

done:

lightningnetwork/lnd#9058

@Roasbeef
Copy link

Roasbeef commented Sep 3, 2024

Enabling positive inbound fees is off by default, it's also marked that it's a config field that really shouldn't be used at all outside of testing: https://github.com/lightningnetwork/lnd/blob/master/sample-lnd.conf#L441-L446

@t-bast
Copy link
Member

t-bast commented Sep 4, 2024

Unfortunately we see that some people are activating this on mainnet, which creates issues. Why do you need to allow enabling it on mainnet? The code could allow enabling this only on regtest and testnet to be safer?

@Roasbeef
Copy link

Roasbeef commented Sep 9, 2024

Why do you need to allow enabling it on mainnet? The code could allow enabling this only on regtest and testnet to be safer?

Here's what the help text for this config setting reads: https://github.com/lightningnetwork/lnd/blob/a895b1c6caf00518ec41fe44a84288160f52a264/sample-lnd.conf#L441-L446:

; If true, lnd will also allow setting positive inbound fees. By default, lnd
; only allows to set negative inbound fees (an inbound "discount") to remain
; backwards compatible with senders whose implementations do not yet support
; inbound fees. Therefore, you should ONLY set this setting if you know what you
; are doing. [experimental]
; accept-positive-inbound-fees=false

We can ofc disable this for mainnet only, but if the user was motivated enough to enable it in spite of this clear warning, then it isn't hard to imagine they'd take the extra step and recompile to remove that check.

@rorp
Copy link
Contributor

rorp commented Oct 20, 2024

PR #2933 could help to mitigate this issue: it simply excludes the motivated users from route finding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants