I consider source code embargoes after a binary release misguided.
Most of us do. It's a bit of a shitty choice they made and I am quite sure that they're aware of it. Before, sometimes the only way to hide a bug was with a refactor. No one would spend the time reconstructing both versions and finding the vulns in the old implementation, because that is often too costly with very little rewards.
Now that every dum dum is able to tell a bot to analyze it, write the exploit, and attack it... within 30-90 minutes, the case even for delayed disclosure of a vuln has largely been removed, because the disclosure not being there will at most cost 90 minutes, not weeks.
I think that ultimately these new timelines mean that (a) users MUST be aware of everything around the software they run, there never really was fire&forget, but now that's truly dead, and (b) lifecycle management becomes extremely important now on the maintainer side. I saw a GHSA the other day saying "bro you forgot to backport this vuln fix for <2 day earlier GHSA> to x and y"
I'm feeling bad about my contributions to society most days because half the shit I do nowadays is validation and getting from idea to hardened implementation takes me forever because I don't want to ship debt that some fucker with a bot can find in 20 seconds. (I do not have trouble sleeping at all though, this shit is exhausting.)
To allow people who need the source code to build and run this (people running on other operating systems than the officially supported ones, people who don't want to trust maintainers, etc.). Some people need the source code to be protected, so it helps more people get a secure node running.
To prove that it's pointless to have this embargo.
Since this doesn't give me a reproducible build (I repro-built the 24.04 binary as a test), I can't trust that what you're claiming is identical to their source code, is in fact that. Yes, I know you made a note about this, and I also know they made a note about it:
Reproducing the binaries. Full build instructions will accompany the source release. This release was not built with the default optimisation settings, so a standard build will not reproduce these checksums; the exact parameters will be published alongside the source.
This is therefore also a problem on their end, not just yours, but they went full trustmebro and eroded a lot of trust that way so no one is counting on them. The "help people" argument for publishing it just doesn't fly because of this though. I'm not going to trust you, and I'm definitely not going to trust Claude.
It's fine if you just wanted to be right. Sometimes we have to be wrong on one thing to be right on the other. Just remember that the roles can be reversed too. Hopefully, that never happens to you.
This was mostly done by Claude Opus 5. The resulting binaries match the published release exactly, at least for the Fedora builds. Other builds will be verified later.
I honestly would distinguish between "core" (or in general, proper bitcoin nodes) and any other product (btcpay, core lightning, they are companies products, although open source, so..). For core, can we really apply the same concerns?
Core Lightning is a Lightning node, which is also a "proper" node (although not Bitcoin directly).
In general, I highlighted these two examples of (in my opinion) wrong handling of security issues.
I believe for Bitcoin Core, it would be even more important to release source code alongside binaries than for these "less important" projects, because it's what the entire network relies on.
Not publishing the source code for that could allow maintainers to secretly hard fork the network without community consensus.
I honestly think that a binary release from core without source code would never be installed (or at least, will be fiercely opposed) since the attention is at peak. Probably it won't even make to the github releases. Node runners i think do care about this stuff.
"Maintainers killing OSS" is the wrong frame — it's the funding model that's dying, and the embargo is just the symptom. The real story is that the most security-critical code in the world (Bitcoin Core, OpenSSL, curl, systemd) is maintained by a tiny number of people whose income is a mix of donations, corporate sponsorship and burnout.
What's actually happening:
Free-riding is structural. The companies extracting the most value from critical OSS are rarely the ones funding it. That was tolerable when the cost was a maintainer's spare time; it isn't when the cost is legal liability.
Legal risk has become existential. The Tornado Cash prosecution showed that publishing neutral, correct code can get you indicted if someone else uses it badly. When your downside is prison and your upside is a donation button, "publish later, publish safer" starts looking rational to any maintainer with a family.
License drift (Elasticsearch -> SSPL, Redis -> RSAL/AGPL, Terraform -> BSL, Sentry -> FSL) is the same defensive move in license form: capture the value cloud providers extract, or force them to negotiate. Source-available is a compromise, not a betrayal.
For Bitcoin specifically the stakes are higher: a backdoored dependency is theft of money, not a data breach, so slow + conservative release processes are correct. The sustainable middle ground is delayed publication for security review + reproducible builds + funded audits. That's not the death of OSS — it's OSS finally pricing its own risk into the process instead of externalizing it onto volunteers.
Fwiw Bitcoin Core is still using the strategy outlined at the end of the blog post. I consider source code embargoes after a binary release misguided.
Most of us do. It's a bit of a shitty choice they made and I am quite sure that they're aware of it. Before, sometimes the only way to hide a bug was with a refactor. No one would spend the time reconstructing both versions and finding the vulns in the old implementation, because that is often too costly with very little rewards.
Now that every dum dum is able to tell a bot to analyze it, write the exploit, and attack it... within 30-90 minutes, the case even for delayed disclosure of a vuln has largely been removed, because the disclosure not being there will at most cost 90 minutes, not weeks.
I think that ultimately these new timelines mean that (a) users MUST be aware of everything around the software they run, there never really was fire&forget, but now that's truly dead, and (b) lifecycle management becomes extremely important now on the maintainer side. I saw a GHSA the other day saying "bro you forgot to backport this vuln fix for <2 day earlier GHSA> to x and y"
I don't know what the hell you're talking about most of the time, but I'm damn happy you're out there doing what you're doing.
Me? I'm not doing enough, at all.
I'm feeling bad about my contributions to society most days because half the shit I do nowadays is validation and getting from idea to hardened implementation takes me forever because I don't want to ship debt that some fucker with a bot can find in 20 seconds. (I do not have trouble sleeping at all though, this shit is exhausting.)
FOSS would be meaningless without guys like you who could actually look at the code and know what they're looking at.
If I were you, or any stacker for that matter, I'd take 1x @sedited over 20x me. Not kidding.
What made you decide to publish the reverse engineered code?
I think that's answered in the blog post:
Since this doesn't give me a reproducible build (I repro-built the 24.04 binary as a test), I can't trust that what you're claiming is identical to their source code, is in fact that. Yes, I know you made a note about this, and I also know they made a note about it:
This is therefore also a problem on their end, not just yours, but they went full trustmebro and eroded a lot of trust that way so no one is counting on them. The "help people" argument for publishing it just doesn't fly because of this though. I'm not going to trust you, and I'm definitely not going to trust Claude.
It's fine if you just wanted to be right. Sometimes we have to be wrong on one thing to be right on the other. Just remember that the roles can be reversed too. Hopefully, that never happens to you.
I managed to reproduce the Fedora build, but haven't reproduced the others yet (and didn't provide the correct build flags).
I forgot to mention that in the post. I will try to reproduce the other builds and share reproduction instructions.
It's obviously not identical to theirs, but the compiled version is.
I have them noted down and will publish full reproduction instructions today.
It's on your commit message so it's visible:
I've added a reproduce script for the Fedora build now. It gives me a tar.gz that matches upstream exactly.
There is also a script for Ubuntu, but it's currently untested.
Will update the blog post later.
Out of curiosity, can you try reverse engineering the same cln binary if you compile it without debug variables?
I could try, but probably only on the weekend.
also this fail by CLN team:
Wouldn't have happened if they just published source code...
EPIC FAIL by Blockstream 🤦🏼
Well, debug symbols and also meant some additional work for reproducing, like adding comments and changing formatting so line numbers match.
But overall, they definitely made it easier (but it wouldn't be impossible without them).
I honestly would distinguish between "core" (or in general, proper bitcoin nodes) and any other product (btcpay, core lightning, they are companies products, although open source, so..). For core, can we really apply the same concerns?
BTCPay is owned by a non-profit.
Core Lightning is a Lightning node, which is also a "proper" node (although not Bitcoin directly).
In general, I highlighted these two examples of (in my opinion) wrong handling of security issues.
I believe for Bitcoin Core, it would be even more important to release source code alongside binaries than for these "less important" projects, because it's what the entire network relies on.
Not publishing the source code for that could allow maintainers to secretly hard fork the network without community consensus.
I honestly think that a binary release from core without source code would never be installed (or at least, will be fiercely opposed) since the attention is at peak. Probably it won't even make to the github releases. Node runners i think do care about this stuff.
"Maintainers killing OSS" is the wrong frame — it's the funding model that's dying, and the embargo is just the symptom. The real story is that the most security-critical code in the world (Bitcoin Core, OpenSSL, curl, systemd) is maintained by a tiny number of people whose income is a mix of donations, corporate sponsorship and burnout.
What's actually happening:
For Bitcoin specifically the stakes are higher: a backdoored dependency is theft of money, not a data breach, so slow + conservative release processes are correct. The sustainable middle ground is delayed publication for security review + reproducible builds + funded audits. That's not the death of OSS — it's OSS finally pricing its own risk into the process instead of externalizing it onto volunteers.
Great perspective! Thanks for sharing this with the community.