gained a ton of new insights working in bitcoin red team 🟥 that i wish i could share without vague posting. but this is what i got anon.
- we’re experiencing a massive collision between decades of human open source slop against 2 weeks of kimi k3 (not good)
- everything is broken, bitcoin is burning
- bitcoin is becoming stronger through this
- bitcoin is the obvious first target but the rest of the world will follow shortly
- sometimes old things need to burn so new things can grow on healthy soil
- humans should never code in c (just stop)
- lightning is complicated and is more broken than the average (sorry)
- verification is free. we used to complain about slop PRs. then about slop security audits. if you can’t handle the information overload, stop complaining and use AI to sort through it.
- those projects that started AI audits months ago are in a completely different position than those who didn’t
- projects need their own AI audit pipeline going into the future
- the burden for a developer to keep software safe and secure is pretty stressful and not for everyone. it has become a lot more stressful now.
- unmaintained projects are most probably broken, don’t rely on them. i’d rather one-shot it myself with a modern AI
- multiple concurrent, diverse human approaches have proven to be the best vulnerability search method
- external red teaming will probably have to continue forever
- we’ve basically completed a basic scan of virtually the entirety of bitcoin open source. the low hanging fruit is done.
- we’ve reported a ton of real critical and high vulnerabilities. project maintainers across the board have validated our findings.
- response speed is very different across projects and shows how healthy each project is. i recommend acting fast these days.
- red team etiquette matters. if you don’t disclose responsibly, boast on twitter about your findings on a particular project, or make indications about the nature of particular findings, you’ve disqualified yourself as a serious security researcher. trust is the most important factor in this game. if you lose it, it’s very hard to win it back.
- did i mention that humans should not code in c?
Replies (48)
Do you have any good news every now and then?
Would it be possible for you to publish a list of the fastest-responding and most-cooperative projects? As a positive-signal.
Can you recommend some food books tonread so.I can learn how to disclose responsibly?
Thanks a Lot!
Amazing work!!
Maybe a public list of the safest, most verified companies that you the red team vetted could be created? Something like a white-list and a black-list?
This is worrying news.
Should I try to sell my Bitcoins now before more people find out about this?
I need to know before I share it with the group on Facebook.
View quoted note →oh boy 😂
Humans should not write C, thats crazy lol
why humans should not code in c: we're finding memory-safety vulnerabilities in c projects that are prevented by default in many other languages.
in the past, finding a simple buffer overflow wasn't enough. you'd need a highly skilled hacker to turn the vulnerability into a working end-to-end exploit.
today, that's a single prompt.
View quoted note →*IQ bell curve meme*
Just use AI. 🤪
No! AI makes slop and will boil the oceans! 😖
Just use AI. 🥷
It's enough to make a person want to go back to not using the Internet and complex electronic devices.
The Linux kernel is written in C. The Windows 11 kernel is written in x86 assembler if you want an OS not written in C.
Peter Schiff read this and giggled.
You are really doing amazing work! Thank you so much and please keep going 🙏👍👍👍
Transparency is also great with your posts 🌟🌟🌟🌟🌟👍
Gold in basement safe from AI
Did you just learn how real software is developed? It sounds like you're new to it.
Very few can code in C, almost no-one. 30 years experience speaking. If you start out in assembly, then object oriented assembly and learn to write object oriented in C, you have a chance of being meticulous enough to write secure code. You can't take a desktop hacker and turn him into an embedded systems programmer or an encryption software author. The practices used in embedded systems in C to maintain long-term stability and maintainability are not widely known, and even more rare is someone who has those skills and is also comfortable with encryption concepts. The rule "don't write in C" for secure systems is a good rule of thumb. Even the best programmers, ones with 50 and 60 years experience, recommend using something other than C. System legibility and careful abstraction layering, is far more important to security than cleverness and vanity.
Does your rule about C apply to derivatives?
You mean nearly every programming language?
I guess that depends how you define derivative. No shared codebase and no shared philosophy on memory management is not derivative in any relevant way for the purpose of this conversation.
I know that you feel very strongly on the subject. My opinion is even if YOU can most devs cannot and you don't maintain most of the code I run.
Your code isn't under the gun in this wave so we don't get to validate you. I can look at public stats on bug rates in open source and draw very obvious conclusions about what languages I should use and prefer when picking software to use.
Yes. But you should not.
No.
Can you say that Rust is standing out in a positive way here, as it advertises itself as a safety-first language?
funny, but you just broke your own 'rules' and boasted, about breaking lightning.
can't imagine why you'd do that eh? 😂
ah well, maybe you should boast a little more info so that we can secure our funds before we get rekt by your overzealous "reproductions" of these "broken" things.
yeah, i know it's hard not to boast.. clearly.
What's the problem with c?
You kicked the hornets nest with that C comment 😂 Appreciate all the hard work the Red Team has done lately!
It was tongue in cheek. I'm just pointing to nearly every modern programing language in use today is, running a large C codebase in it's VM, or as part of it's compiler, or were before they became complete. Beyond that they are all inspired by C (according to their authors) or are a superset.
By the way, IMO Satoshi was probably a financial software developer for wallstreet. He appeared to be proficient with MFC and was just learning Qt.
The problem with C memory management is hard.
Humans will always act in self-interest
Trust me bro
This. -> " - the burden for a developer to keep software safe and secure is pretty stressful and not for everyone. it has become a lot more stressful now."
Must be repeated.
I do think however, it is worth the time to learn to code in C and at least build a few things manually with it, especially hardware. There are lessons learned by doing it hard manual way, and the touch gets lost when solely depending on LLMs
yes it can be a total Brain Fuck, and fuck you over for countless hours but that's how you develop
1) a thick skin for shit tolerance
2) A ton of patience
3) Discipline
All my gray hairs came from C programming 😂
Maintaining good software requires good security practices. Nothing new. Proper auditing as always been important in FOSS if people are to accept your software. Creating a list of software that is accepted as "Bitcoin approved software" is a very slippery slope.
Yet last I heard, libsecp256k1 held up pretty well?
On a less vague - posting note, I had Kimi work through CCAN for bugs, resulting in about 100 commits. I'll go through this morning and see how many are C mistakes, but I don't recall many (and yes, I reviewed each one carefully).
But it's mostly my code, and I've got a fairly defensive style built over a long career of mistakes. I should probably post about that...
@calle Will the Red Team at some point publish their methodology and tools? It could be a game changer, allowing your good work to be used by other projects going forward.
View quoted note →
I agree with most of what you said, but dude, I don't think that today the biggest problem is that people write C, I think the biggest problem today is the opposite, people have no idea what they're doing, period
Security is not static
Heh. Great list. Keep up this important work.
I will surely run my own AI security audits on anything I use from now on. Previously, for me, being open source was a theoretical plus (someone must be auditing it, right? right?).
AI gives us all the power to verify directly.
I mean Perl
no
He didn't
My bad. C++
Yes, classical C has the problem that operations are low-level, so if you overrun the end of a buffer, instead of a crash report the attacker can make arbitrary commands run. Also, manually deallocating memory can be omitted (oops, program grows over time, crashes) or done twice (also classically tricked into running arbitrary code).
Also, the standard routines are minimal, forcing programmers generally to deal with these issues everywhere.
CLN has a *lot* of internal infrastructure to avoid code having to do this. Firstly, the tal hierarchical allocator removes most manual deallocating, and all the infrastructure relies on it. Second, all the wire demarshaling routines are generated from spec files, and all come down to two hard-to-misuse routines (note: the bolt11 parsing was hand-coded by me, didn't use this, and had serious bugs!). Finally, we use patterns designed to highlight issues early, including running test cases under Valgrind (a memory debugger) and internal memory leak detection.
But as one developer said "It's not coding in C, it's coding in Rusty's C"!
Seems like just using rust would be simpler, Rusty's Rust!
