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

Change max_value_in_flight based on channel being public #2851

Open
TheBlueMatt opened this issue Jan 24, 2024 · 9 comments
Open

Change max_value_in_flight based on channel being public #2851

TheBlueMatt opened this issue Jan 24, 2024 · 9 comments
Labels
good first issue Good for newcomers
Milestone

Comments

@TheBlueMatt
Copy link
Collaborator

If a channel isn't public, our "reduce max_value_in_flight to provide routed payments more privacy" thing doesn't make sense...cause the channel isn't routing payments. Thus, our default config should depend on if the channel is public here, IMO.

@TheBlueMatt TheBlueMatt added the good first issue Good for newcomers label Jan 24, 2024
@TheBlueMatt TheBlueMatt added this to the 0.0.122 milestone Feb 2, 2024
@SimonAdameit
Copy link

Hello @TheBlueMatt, I'm looking into this but as I'm just getting started with the code base I lack a bit of information.

My best guess is you are talking about the anti_probing_penalty_msat:

pub anti_probing_penalty_msat: u64,

If so, as far as I can see, that already get's only applied on public channels as channel_penalty_msat returns 0 for non-public hops:

Given that you're aware of how this works much better than I am, I suppose you are talking about something different?

Cheers,
Simon

@tnull
Copy link
Contributor

tnull commented Mar 1, 2024

Hello @TheBlueMatt, I'm looking into this but as I'm just getting started with the code base I lack a bit of information.

My best guess is you are talking about the anti_probing_penalty_msat:

pub anti_probing_penalty_msat: u64,

Close, I think this issue is around the actual htlc_maximum_msat we set, not the anti_probing_penalty_msat we score peers with who set the former lower.

For context: generally, peers provide more privacy if they limit htlc_maximum_msat as this reduces the capability of probing peers to gain information about the actual liquidity, at least if it is above htlc_maximum_msat. E.g., if a peer sets htlc_maximum_msat to 10% of the channel capacity, a probing peer could only test the actual liquidity when it drops below these 10%. So for forwarding ('public') nodes, limiting htlc_maximum_msat is a privacy feature, but for non-forwarding nodes it just unnecessarily restricts our maximum HTLC size.

So, we should only apply the limit if we have any announced ('public') channels, i.e., can be considered a forwarding node.

@jbesraa
Copy link
Contributor

jbesraa commented Mar 8, 2024

hey @SimonAdameit
are you still interested in doing this?

@SimonAdameit
Copy link

@jbesraa Unfortunately I haven't had the time recently and if I find some time to dedicate to the project, I could just pick another issue if this is already done. So if you or someone else wants to work on it, please go ahead!

@Sharmalm
Copy link
Contributor

Hii, @jbesraa I am interested in this issue, I can try this issue if you are not taking it :)

@jbesraa
Copy link
Contributor

jbesraa commented Mar 12, 2024

sure @Sharmalm, feel free to take this

@Sharmalm
Copy link
Contributor

Thanks @jbesraa

@TheBlueMatt TheBlueMatt modified the milestones: 0.0.122, 0.0.123 Mar 18, 2024
@TheBlueMatt
Copy link
Collaborator Author

Don't think we should hold 112 on this.

@Sharmalm
Copy link
Contributor

Sharmalm commented Apr 2, 2024

Hello everyone,
My approach to solve this issue is update the changes in configuration in lightning/src/util/config/ChannelConfig so that inbound_htlc_maximum_msat will only be included in if channel is public.

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

No branches or pull requests

5 participants