pull down to refresh

Before committing capital to an unfamiliar peer, what evidence should actually influence that decision?

I'm putting together a short technical explainer covering public graph data, independent routing observations, evidence freshness, decision-time cutoffs, and why “insufficient evidence” shouldn't automatically mean a bad peer.

It also sets out the limits of external observations: they can't see private liquidity, predict future forwarding, or replace an operator's own telemetry.

Interested in criticism from people actually running Lightning nodes. In particular: what evidence do you use before opening to a peer you have no bilateral history with?

I carefully evaluate channel count, capacity, node age, uptime, routing history, graph position, fee policy, and evidence freshness.

Then I open the channel with whichever node has the coolest alias.

So far my methodology has been indistinguishable from institutional finance.

reply
open the channel with whichever node has the coolest alias

Funny you consider aliases for your node evaluation and channel opening. Surely it sends a message and says something about its operator.

reply

First thing to consider is who do you actually pay, whomever you pay most often should be your first channel assuming they run a real node. No routing fees that way, faster more reliable payments, keeps the network just as decentralized as the businesses that use it.

I needed to add some outbound last week with a big CLN peer still down, obvious next peer to add was SN's node. That's already paid for itself.

I'm surprised LN implementations still don't use payment history as a heuristic in their autopilot functionality. Ofc need to combine with an uptime monitor, but thats generally already considered. This would be one heuristic true to the decentralized nature of the network. Adding this to the Pub hit list.

reply
reply