Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
Is this new Amboss feature as dangerous as it looks? The analytics company unveiled “Reported Channel Balances” and the bitcoin world immediately reacted with severe criticism. Were they overreacting or did they have a point? Is bitcoin’s Lightning Network at risk? Let’s study exactly what happened and find out. It all starts with the notion that a node’s capacity is not the same as a node’s liquidity.
We've also given node operators the ability to share and analyze their node status, including channel balances. This will allow us to deliver better insights, notifications, and valuations for purchased channels. pic.twitter.com/YgJmxFokS8
— AMBOSS (@ambosstech) October 26, 2022
In the medium post announcing the “Reported Channel Balances” feature, Amboss expands on the idea:
“One major piece of information that has been missing since the beginning of the lightning network is the difference between lightning’s capacity and its liquidity. To find the difference, we need a piece of information that (thankfully) is private by default: channel balances.”
Since that’s still a key piece of information, many actors find out channel balances by using the probing technique, “which is an attempted payment designed to fail, reveals private information about channel balances without consent. It is, in a way, an attack on the privacy of nodes.” So, Amboss knows that the Lightning Network’s privacy is at stake. The sender’s funds are also a stake, since they “may get locked, temporarily.” And it’s even worst for the target.
Amboss’ Idea: Reported Channel Balances
So, to phase out probing, Amboss enabled a way for nodes to voluntarily report their balances. “we’ve created a single endpoint that users can send this data to and it will be displayed on the node’s Amboss page.” There’s the possibility of sharing the data just with Amboss, but nodes can go public with their information if they want. “The settings span from Private (shared only to Amboss), Range (balance shown publicly as 25%, 50%, or 75%), or Public (the specific percentage is shown to Amboss visitors).”
In general, the idea behind the feature seems a little naive, and nowhere is that more evident than in the way they’ll treat lying nodes. “In truth, anyone can write a script to lie about their balances. Instead of trying to rout out the liars from our data set, we’ll try a different approach: deliver services based solely on the information we’re told.” The Amboss people took “kill them with kindness” to a new level.
“We’re building tools to help node operators whether it be through providing notifications and alerts or through providing insights that help users make good decisions with their nodes. The best way that we can help is if users are sharing their balances honestly.”
So, the incentive to be honest is the valuable info that Amboss will give you? Sounds frail.
BTC price chart for 10/28/2022 on Kraken | Source: BTC/USD on TradingView.com
The Case Against Reporting Channel Balances
Lightning developer Openoms, whose twitter bio says “Building nodes for Security, Privacy and Freedom,” lead the charge against Amboss’ new self-policing feature. “If this data sharing and aggregation by Amboss gets widespread and accurate we’ll have a huge problem with Lightning privacy.” He also offered alternatives, possible rules, and a clear course of action. “Good it is open-source, let’s make it not possible to share more than 2 bits of data.”
Some mitigations for now:can't really tell if someone is sharing privately, still:* don't peer with sharing nodes* avoid paying through sharing nodes* look out for CLN peers who can't run Thunderhub* feed it random data if anything* use aggressive MPP and longer routes
— openoms (@openoms) October 27, 2022
Openoms also breaks the already frail logic behind the feature and poses that instead of making “data sharing the norm because probing is already possible” we should “make probing more difficult, expensive and inconclusive.” As for the actionable items, Openoms offers “some mitigations for now:”
- “Don’t peer with sharing nodes”
- “Avoid paying through sharing nodes”
- “Look out for CLN peers who can’t run Thunderhub”
- “Feed it random data if anything”
- “Use aggressive MPP and longer routes”
How did Amboss react to the criticism?
Amboss’ Quick Response
Say what you will about the analytics company, but their response was cool, calm, and collected. “We sincerely appreciate all of the feedback (even if it’s negative) with respect to our channel balance sharing feature,” Amboss tweeted. Then, they gave credit where credit was due. “Special shout out to Tony Giorgio & Openoms who’ve provided valuable insight on serving our users while preserving network-level transaction privacy.” Amboss also clarified that the feature is opt-in and comes disabled by default.
One important fact to get right amidst the controversy: The @thunderhubio design is OPT-IN only and private by default. Thunderhub is a user-friendly MIT-Licensed node manager that respects the user's choices.
— AMBOSS (@ambosstech) October 27, 2022
Before we go, we have to find out what did Tony Giorgio say that was so insightful. He led the discussion in the phenomenal Stacker News, and started the fire by writing:
“We do so much to try to protect the privacy of the lightning network but always going to be constantly fighting the tendencies for society to give away information for convenience. I can’t begin to tell you how aggregating this information to a single party is an attack on Lightning and the privacy of all individuals as a whole.”
Sweet, old convenience. How much trouble have you led humanity into?
Featured Image: The platform's dashboard, from this tweet | Charts by TradingView
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.