When Anthony and I first started working together, we experimented with all sorts of names and business models until settling on “Amboss”, which is a German word meaning “anvil” to complement all the hammer and Thor imagery within the lightning network ecosystem. We had Bitko Yinowsky design a logo for us, which we reduced to a simple “A” to fit into the browser tab favicon. After scrapping our initial plans to build a multiple node manager, we settled on building a fresh lightning network explorer that’s both social and easy-to-use. It was around this time that we noticed that there was something special about our Amboss A logo: it had a small letter “i” embedded within the negative space, just like an information symbol. With a strong reception after our launch, we learned that the information that we provided and organized was critical for users to coordinate.
An encircled “i” — the symbol for information.
Our information helped operators associate, visualize their activities amongst their peers and create something really special: an orderly market around lightning network liquidity. Routing node operators are providing a supply of saved bitcoin to connect and make efficient payment rails across the lightning network. The demand for this liquidity is coming from merchants, boot-strapping routing node operators, and wallet service providers.
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.
Channel balance is a critical component when it comes to valuing a node’s liquidity. A node that has no inbound capacity will provide no value to another node when they open a new channel. This is a problem that isn’t thoroughly addressed by any liquidity marketplace, monetized or not, including Pool, Magma, Liquidity Ads, or Lightning Network Plus. Since channel balances are important pieces of information, the network has used the tools it has available to get an answer, namely probing.
Probing, 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. It is at once risky for the sender (funds may get locked, temporarily) and violating for the target. And yet, it is used extensively across the network to provide critical network functions e.g. rebalancing, payments, and monitoring.
Since the start of the lightning network, we haven’t had an easy way to enhance transparency and functionality across the lightning network that operates on consent. That changes today.
Report Channel Balances
Using Thunderhub (v0.13.16), an open source node manager, we’ve enabled balance reporting. We’ve created a single endpoint that users can send this data to and it will be displayed on the node’s Amboss page. This method can be replicated on any node manager or service.
💡 Since Thunderhub is open source and MIT licensed, feel free to integrate this code into other services so that users can opt-in to reporting balances.
Alongside channel balances, users can use the same method to report on-chain balances or uptime.
While the controls for pushing balances are on Thunderhub, Amboss.Space contains controls for the level of privacy desired. 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).
Truth and Transparency: Playing Node Doctor
Now that balances are shown, the temptation is to use these balances to rank nodes to find out the best ones to connect to and find the nodes with the best liquidity. There’s a problem with this, though. What’s to stop users from simply lying about their balances to get a higher ranking? 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.
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. If we can provide great insights, the network data should be more truthful and therefore more valuable for diagnosing and solving network problems.
A dashboard for your node
The first feature you’ll notice when uploading balance information is a new section of your node page, called Balance Report. This contains basic information showing the Last Update time, the number of channels, your total Channel (Off-chain) Balance, and your On-chain Balance. This balance report information is shown only to the node owner, regardless of the balance sharing setting.
While this report is handy, the in-depth information is shown when clicking on the balance report to show the Node Balance Summary. Here, you’ll find a breakdown of on-chain, remote capacity, and local capacity.
The local and remote balances can further be analyzed in the channel balances display. Each vertical bar represents a channel with its local balance shown in magenta and remote balance in purple. This provides a simple visual to get a sense of how balanced channels are and whether any additional remote balance is needed (for lightning payment recipients).
Looking Back at the Past
At the top right of the node balance summary are tabs for both Current and Historical. The historical balances give a view of how your node balance has decreased or, better yet, increased. You can select from the dropdown for On-chain Balance, Channel Balance, and Channel Count as well as select the timeframe from 1 hour up to 3 months. The scale can also be changed from Absolute (y-axis starts at zero) to Relative (y-axis starts at the lowest value in the time period) for easier viewing.
We’ve got a lot more features planned for this dashboard, so stay tuned. We hope you find it useful. For specific feedback or requests, please join our Telegram Chat!
Network Stats & Analysis
The beauty of the lightning network can’t be found on any one node, just like the beauty of a mosaic can’t be found on any one piece of porcelain. We’ve been developing tools to show how the lightning network fits together and what insights can be derived from a network-level analysis.
Investigating the effects of the recent LND bug
We’ve been fascinated by the network’s growth even amidst tough situations like the significant LND bug that appeared following Burak’s epic tapscript transaction. With our new network stats & analysis tools, we can take a closer look at the effects and response of the network for this unique event.
I just did a 998-of-999 tapscript multisig, and it only cost $4.90 in transaction fees. - Burak
The massive multisig transaction wasn’t recognized by the btcd library used by LND, so the offending block was viewed as invalid for most nodes on the lightning network. This meant that new channels following that block weren’t recognized because all the LND nodes were now “out-of-sync”. This also affected lightning network gossip since all nodes filter the new channel information that they pass on, only propagating valid new channels that could be verified.
Snapshot from Amboss Space Statistics Platform
As we can see from Amboss.Space/stats, the number of channels started dropping following the unusual transaction on October 9th. With a new patch in place and a strong effort to push LND node operators to quickly update their nodes to v0.15.3, the channel gossip information is propagating normally once more.
While this decline looks pretty severe when viewed with a relative scale, we can see that the number of channels faltered ever so slightly compared to the rest of the network when viewed with an absolute scale.
Snapshot from Amboss Space Statistics Platform
Lightning Native Arbitrage, visualized (Prime feature)
For Amboss Prime members, we’ve made something really special: a live visualization of the lightning native arbitrage that’s possible between on-chain bitcoin and lightning.
We’ve added a whole host of parameters that users can dive into and view a time series of the data as the market has been developing.
To examine the arbitrages, I’ll look at the Incoming Fee Rates for a given node. This isn’t the fee that a node charges, it’s what all of a node’s peers charge. If I want to make a deposit to Bitfinex via lightning, I should expect to pay ~1000 ppm or 0.1% in fees when I don’t have a direct channel.
Each time I deposit to bitfinex via lightning, my node will get more inbound capacity. Inbound capacity is the most valuable resource in the lightning network; it’s almost like a popularity score, except that people will buy it from you.
In essence, this chart shows me that I can “buy” inbound liquidity by depositing via lightning to bitfinex at 0.1% fee and I can “sell” that inbound liquidity by opening a channel to LOOP at 0.15% fee. This arbitrage is both profitable to the node operator and healthy for the network as it moves liquidity to the highest demand on the network i.e. those that are paying for the LOOP service.
Snapshot from Amboss Space Statistics Platform
We sincerely hope that this statistics explorer is useful to you to identify arbitrage opportunities, improve your node operation, better coordinate with the network, or get inspired by this incredible open financial system.
As always, please send any feedback to us through our Telegram chats or via email.