Dynamic max_htlc_msat: Leaking Liquidity and Flow
2200 sats \ 4 comments \ @zapomatic 29 Dec 2023 lightning
In running my lightning node Zap-O-Matic, I have been examining failed HTLCs and trying to reduce failures. One thing I've noticed other nodes doing is using tools like charge-lnd to dynamically update max HTLC size to prevent an attempt to route a message that exceeds the liquidity available.
This seems like a great idea to remove failures, but I've also been writing an app to allow me to scope out and score possible future connections and it occurred to me that I could observe nodes that are dynamically updating their max_htlc_msat value for changes, record those flow changes, and then know how much traffic is flowing through that node. Additionally, if enough other nodes in the route path are also dynamically updating their max_htlc_msat, I could follow the route of the message. This is a case where if everyone does it, it's bad for the privacy of the network. I see several nodes that advertise auto-adjusting the max_htlc so I could make a list to follow, or simply examine their node information in the graph and see who is changing their htlc values on a regular basis...
Is anyone concerned about this? I would think that the NSA/CIA/etc would be recording this data.
I really want anonymous traffic info into the network so that I can see where to plugin for maximum effect but I'm also concerned about harming the privacy of the network.
The Diamond Hands ranking page is an excellent example of just enough info to help a node operator without exposing end user traffic: https://diamondhands.shinyapps.io/ranking/ (more of these types of pages would be great).
write
preview
related posts
57 sats \ 1 reply \ @0207a984de 30 Dec 2023
It seems like a fairly trivial exercise to determine the exact balances of channels. I haven't written the script yet, but it would consist of attempting a bunch of different size payments with the final destination back to my node which I forcefully always fail as the last hop. I can figure out which hops said "yes, I have enough balance for that" and incur no cost or risk to getting that information.
So given this, I have decided on my node to just update max_htlc_msat to a figure generally just below my current local balance.
In fact, I have been pondering as a non-dev whether we can add another optional node operator flag to LND which signals "public channel balance broadcasts" and other nodes can use this information as they wish.
Some routing would become immediately much more efficient, especially if people choose "only use known balances" in a route. For greater privacy, people could choose "all channels" of course. It's kind of like we have the option to use TOR or not.
I don't know how much more efficient payments would be if we knew all the balances of channels, but I suspect it will be a lot more efficient. And fee discovery would also be improved, since we know that "0 ppm" on a zero balance channel isn't a relevant or competitive fee.
Would people use this flag?
The second feature I was thinking of was the ability to set fee rate formula based on that balance. If not public, at least a server-side formula. What happens sometimes is that my fee updating script isn't fast enough to catch a sudden drain event. Maybe I can run it after each TX, but we know gossip is a pain. So it might be interesting to tell other nodes that I have a dynamic fee on this channel which changes based on the broadcasted balance, so if they want to drain the channel, it's going to cost a lot more sats. I don't know, haven't fleshed out the details, but the point is to have dynamically changing fees without spamming gossip channel updates to the whole network.
reply
1 sat \ 0 replies \ @zapomatic OP 31 Dec 2023
This is a great point. You can get much more accurate data by just running test transactions... I really like the routing efficiency so I'm going to go ahead and dynamically updating my max_htlc_msat settings to just under my side liquidity every hour (if the balance changes).
reply
0 sats \ 1 reply \ @bartoli 30 Dec 2023
People are not updating max_htlc_msat to exactly the channel balance. And they are not doing it after every route on all channels. They could have router 0 or 1000 payments between updates. You can get 'some insights', but not really know what they route
reply
0 sats \ 0 replies \ @notgeld 30 Dec 2023
Yes, but we could consider heuristics that the htlc_max update happens around the channel balance point (half of the capacity on the single side).
reply