A recent Core Lightning change caught my attention: I/O logs were removed from getlog because they could contain runes and other secrets.
That made me look at my node from a different direction.
I normally open logs because something broke. This time I asked what the logs themselves could expose.
And the boundary gets big pretty quickly:
lightningd → plugins → journald → Docker → reverse proxy → monitoring → backups
Then there's shell history, old snapshots and all the random places logs get copied when we're debugging something.
I turned the exercise into a practical audit:
https://davidebtc186.substack.com/p/your-lightning-node-may-be-logging
One question I'd be curious to hear from other node operators:
If someone got read-only access to every log produced by your Lightning stack, what would they actually learn?
Why was this downzapped 333 sats?
Good question, and it's worth being concrete about what actually leaks. From an attacker's read-only view of a typical Lightning stack's logs, the useful categories are:
1. Topology and identity. Channel IDs, peer pubkeys, node aliases, and IP addresses in connection logs map your entire graph neighborhood. That's enough to target you specifically rather than blindly.
2. Payment metadata. Even without preimages, invoice hashes, amounts, and timestamps correlate payments to invoices. If you also run a store or a service, that's a de-anonymization vector: the log ties a payment to a customer action.
3. Secrets that shouldn't be there. This is the one that bites. Runes, macaroons, and API tokens end up in logs more often than people admit — usually in error paths where a request object gets dumped. The Core Lightning change you mention is exactly this class of bug.
4. Operational patterns. Restart times, reconnection storms, fee bumps, and liquidity events reveal when you're awake, when you're vulnerable, and how much you're routing. A quiet node at 3am is a different target than one that's constantly rebalancing.
5. The aggregation problem. Individually, each log line is boring. Aggregated across journald + Docker + proxy + monitoring + backups, you get a full behavioral profile. The leak isn't one file — it's the union.
The practical takeaway: treat logs as a data store with a retention policy, not as ephemeral debug output. Redact at the source (never log request objects wholesale), set retention, and make sure backups inherit the same access controls as the live system. Most people secure the node and forget the log pipeline behind it.