pull down to refresh

With the release of Core Lightning 26.06.79, the CLN team asked operators to trust & run closed, embargoed binaries or go offline.

As @fanquake noted, without open source and reproducible builds, you lose the code-to-binary mapping and rely on a single trusted machine.

What should node runners do during critical zero-days?

Run the embargoed binary21.4%
Stay offline until source drops50.0%
Immediate full disclosure28.6%
Don't know (view results)0.0%
14 votes \ poll ended

No solutions, only tradeoffs...

Don't mistake 'theoretical audibility' for an actual audit

The benefit of Opensource was always based in statistics: more eyes, more stakeholders, more audits, and more fixes produces better software (probably)

Alternatively, apply statistics through AI to vibe-slop fork your own node implementation with off-the-shelf library like LDK and watch it very closely

reply
Alternatively, apply statistics through AI to vibe-slop fork your own node implementation with off-the-shelf library like LDK and watch it very closely

Before you do that, instruct your LLM to:

  1. Read lightning/bolts beginning to end, write down every "rule"
  2. Cross-check every rule against every other rule
  3. Make a list of odd shit

And then decide if you really think it is a good idea to do this.

reply
And then decide if you really think it is a good idea to do this.

... only tradeoffs

a few benefits of writing/running your own LN node implementation:

  1. You control the feature priority

No need to wait for LND to add splicing or BOLT12. No need to wait for CLN to add AMP. Your implementation can support all or none if you want it to. The vast majority nodes can only collaborate using certain features with a subset of nodes that run the same implementation.

You can add all the features (or none), making your node easier to collaborate with if you can support more protocols, or more secure/hardened if you only support the bare minimum.

  1. You can "hack" the protocol

The existing lightning protocol leaves lots of room for creativity that no current implementation is currently using.

The mainstream implementations are open source so you know exactly how those nodes will behave in response to a custom message your implementation sends them. This let's you fingerprint and exploit (somewhat) the implementation a node on the network is likely running.

  1. You can keep the source hidden (if you want)

Nobody needs to know what source your node is running! So you're harder to hack (in theory). Security using obscurity is real (with tradeoffs).

Or maybe you publish it and hope to get some expert review before someone with better LLMs exploit it :)

reply

In general, I'm a big fan of vibing one's own tooling. It's a good idea, though if it involves money, make sure you know what you're getting into!

The existing lightning protocol leaves lots of room for creativity that no current implementation is currently using.

Yeah that is the bug, not feature I was covertly hinting at above. It's not completely terrible everywhere but boy oh boy are there headaches in the bolts repo.

Or maybe you publish it

Please don't!!! No one is going to review slop unless they have to. The world is better off not knowing what you made a bot do. If you want to share something, share your prompts.

reply
  • For a public business node with only CLN with tons of channels: no choice really. Use the time to hedge and start integrating LND on the side so that you can survive --offline next time around.
  • If you also run LND and can lose the liquidity, --offline
  • If you have a lot at stake AND you actually review source code normally, and patch shit you don't like --offline
  • If you just run CLN and you don't know how to read the code, not much changed. Just run the embargoed binary.

this means: most should just run the embargoed binary because they have no idea what software they are running anyway.

reply
this means: most should just run the embargoed binary because they have no idea what software they are running anyway.

There is also the option of "You don't understand the code, but rely on there being (enough) others who have checked it."

reply

Relying on their reports, or assuming that there are people that look? Do you have a report from someone that went over CLN and says: "I went through it all and found a few bugs which I reported but otherwise this is awesome"? Didn't we recently have some findings in the field on the assumed level of review Bitcoin software is getting?

Last night I found and verified a nasty asymmetric state bug in the latest release of a software I and 200M others run (released this Tuesday) that survives process termination and leads to permanent crash cycles - I verified that in a VM that was running over Car's face on SNL last night and after all that, I was exhausted so I went into snore mode. Before I opened SN this morning I looked at their repo and turns out that while I slept, a fix was pushed (but not yet formally released.) So there, it works, as clearly I wasn't the only one that found it. Noting that I was slow with my review this time because I'm busy - as normally I frontrun any fixes and I send them an email. It gives hope though, I like it when I'm not the only one looking, though arguably, due to the 90h day gap between release and commit, this could have come from someone actually sitting in a crash loop instead of running through the code.

This is at 200M deployments, centralized, fully subsidized FOSS. In comparison, Phoenix has 200k installs or so. How many more people besides myself do source review on that? Is anyone even looking at the iOS branch? Ethan sounded surprised someone was looking at Zeus source code at all[1] the other day when I made a little note about the liveness check.

The only software where I more often have a duplicate finding than not is Bitcoin Core (almost always there, I'm slow). I don't remember any instance of Bitcoin software other than that in the past 5 years where my finding was a dupe.

  1. and due to the size/complexity I can't even review that as fully as I want to - my backlog of code and, perhaps most importantly deps, on that grows faster than my progress on doing the reviews, so I mostly look at diffs and some hot path dep diffs only, and I focus on features I'd use (but I can't really use it for production still after 6 months of effort now.)

reply
127 sats \ 1 reply \ @unboiled 29 Aug

No need to shoot the messenger.

But then again, I rely on that myself. I certainly haven't checked every single line of code running on my machine.
I'd be astonished if I even got a reviewed-in-person-rate of as high as 1%.

reply

Not shooting at all really, just questioning if what you assert makes any effective difference to reality.

How do you rely on it?

PS: Of course you cannot review everything, even on Android you have to make choices because you cannot 100% end-to-end review ACK or AOSP's platform/*, that's more than a dayjob, also with unlimited bots.

reply

Difficult situation.

I think expecting people to run a non-verifiable binary, or else stay offline, doesn't help anyone.

Even if you trust Blockstream, any subtle behavior changes could cause apps built on CLN to lose funds in other ways. By looking at the diff, you can better test for this.

People have been given a few days to get offline, those that haven't are at increased risk once the source is released.

Does more time before the source is released really protect them? If they aren't down already why assume they'll update immediately?

At what point do you say fuckem? You'll have to eventually, so its just a matter of how long you're going to hold current operators in limbo.

I'm more surprised they didn't handle this the way Core and LND do, stealth fixes.

reply