pull down to refresh

Really cool visualisation of the lightning transactions flow, in and out, performed live by @AuthenticityBTC node. Hopefully the code will be open source soon so I can plug it to my nodes.

Payments routing through Authenticity right now, anonymized: unlabeled channel slots and coarse size buckets only — no channel IDs, amounts, peers or failure reasons.

Node health is pretty cool too.

Each node's individual health — scored against its own recent baseline, published as a snapshot every ~15 minutes.

AHahahaha I was just coming here to post this, as I tweaked a few security issues.

Thanks for the shoutout :)

EDIT: Those other images of my node health and stuff are still placeholder. As the warning label on the site says, the data's all fake. Need to find time to finish it up

reply

why did you start closing channels right before the bipcoin fork?
Are you a forker ?

reply
reply

Legend, thank you for putting this together. It's great to observe a live node. We can wait for the node health. Where are you getting the data from? Or are you calculating it with this tool?

reply

I wrote coughClaudecough a custom setup for this, roughly as follows

  1. Go gRPC / HTLC interceptor with a readonly macaroon that grabs all the data and then parses out the things I want the Visualizer to see. It then sanitizes things and pushes it as a feed.json (events) and ring.json (anonymized channels) files to Amazon S3
  2. Amazon S3 holds only the latest copy of this, and versions it out automatically
  3. A web frontend built on HTML/JS and hosted as an S3 Static Website
  4. The actual Visualizer just pulls the updated JSOn files and presents it.

It is on my list to push to Github. Drowning in higher priority life stuff and getting things pushed to OpenSource keeps dropping down the list (my dashboard project/idea, this visualizer, node temperature metrics, network temperature metrics, etc)

reply

is it worth hosting the data in S3? Could the whole process be handled easily with GH actions and perhaps storing the json as gist instead?

reply

Currently I update the feed every 15s. There's a ton of ways to do this, including gist.

I just went what's simplest and easiest to me. I run on AWS to begin with so I keep everything I can there.

reply

When I first opened this visualization of live Lightning Network transactions, I felt like I was watching the nervous system of a sleeping giant — except the giant is made of routers, channels, and a lot of people who are very serious about millisatoshis. As an electrical engineer, I instinctively started looking for Kirchhoff’s laws hiding in the data. Spoiler: they’re there, but with extra steps and occasional on-chain drama.

The Lightning Network is fundamentally a graph of payment channels, and any graph of moving value is just a circuit with extra steps. Instead of electrons moving through copper, you have satoshis moving through multi-hop paths. Instead of voltage drops, you have routing fees. Instead of resistance, you have liquidity constraints. And instead of a simple DC circuit, you have a dynamic mesh network where nodes open and close channels like I toggle bench power supplies — sometimes with less planning.

What I love about visualizations like this one is that they make the invisible visible. In a normal circuit, you can probe a node with an oscilloscope and see the waveform. On Lightning, you can’t just clip a probe onto a channel and see the HTLCs (Hashed Timelock Contracts) fly by. But a live flow visualization gives you that gut feeling: “Ah, this node is the main artery, and this one is barely a capillary.” You can almost hear the electrons — I mean satoshis — humming.

Node health is another thing that tickles my engineering brain. In power systems, a weak bus can cause voltage collapse. In Lightning, a poorly connected or frequently offline node becomes a reliability bottleneck. Watching node health in real time is like monitoring the thermal status of a MOSFET under load. You don’t wait for it to fail; you watch the temperatures rise and plan accordingly. The visualization seems to capture that: which nodes are hot, which are cold, which are about to have a bad day.

Of course, my lighting-engineer side can’t resist commenting on the visual design. If you’re going to visualize a payment network, please, for the love of Planckian locus, don’t use a color palette that looks like a unicorn exploded over a heatmap. The best visualizations use color as a signal, not as decoration. Show me liquidity as luminance, fee rates as hue, and node health as saturation. Then I can glance at the screen and know where to route my payment without reading a legend. The author of this tool seems to get that — or at least they made it pretty enough that I’m willing to pretend it’s informative.

One thing I’d love to see added: an electrical-style “bode plot” for a channel’s reliability over time. Or a “total harmonic distortion” metric for routing failures. Because if Lightning is going to be the Visa of the future, it needs to be more than just fast — it needs to be predictable. And predictability, as any engineer knows, is just a fancy word for “fewer surprises at 3 a.m.”

So to whoever built this: nice work. You’ve made me stare at a screen for five minutes and forget about my dimmer curves. Now, if you’ll excuse me, I need to go open a channel to my coffee machine and see if it routes better than my current node.


نسخه فارسی (برای درک بهتر شما)