Rob seems like a pretty cool guy, but he is also really, really good at marketing. His company, Anchorwatch provides a service to which I'm sure a number of people who were caught off guard by this Coldcard fuck up will run.
pull down to refresh
pull down to refresh
Rob seems like a pretty cool guy, but he is also really, really good at marketing. His company, Anchorwatch provides a service to which I'm sure a number of people who were caught off guard by this Coldcard fuck up will run.
I'm so tired of the "we found vulns, but we're not gonna tell you anything except we found it" gimmick
Isn't responsible disclosure a thing? I guess he could just not mention finding anything, but I think some of what he is trying to do here (for good or I'll) is capitalize on the energy around Coldcard and maybe there really could be a useful group effort here that results in a net win for people.
Yeah I don't see how any of what he's doing is bad. He's been a good, knowledgeable source of information during this and I'm happy someone is doing what he's doing. If Anchorwatch gets business because of it that doesn't bother me in the slightest.
It's not that I'm saying he's doing anything bad. It's that I'm tired of listening to words and unverified claims. Believing unverified claims is what got us here.
GOOD! Please don't disclose whatever you find while you verify before a fix is released, or steal coin. Thanks!
How should he do this? Just try to privately contact the developers.
No dev is going to tell you how many vulns are in the pipeline before they are patched and (I guess this has become optional now) rolled out.
Right. A vague statement like this makes sense to me because it communicates to people that there’s a reasonable possibility that something’s wrong with their setup without putting them at risk by pointing attacks towards them.
Exactly, though before the "responsible disclosure" process meant you completely stfu in public until it is patched. I do think that there is no point anymore. Even Linux kernel security people are arguing that it's better to say what's wrong straight away (and offer a mitigation) than to have an embargo.
Not everything will have a mitigation though.
Odell and Bent know now's not the time to pump their own book, but Rob is a nice, smiling fresh faced surrogate. Has he NOT been on any podcasts the past few days? He's ticked all the boxes. Pomp is waiting
He's been on at least one, BPI, shilling for vault op_codes... which would not have helped this CC situation at all and in some cases may have made it worse
Is it possible to self-host anchorwatch? Seems like it's just a daemon that checks a PSBT before automatically signing it in a multisig.
What if I don't want a third-party key holder but I still want to restrict spending without covenants? And I don't care about insurance?
https://twiiit.com/Rob1Ham/status/2084140242915782743
After after looking into stuff from our collab custody solution discussion last night I have a few reports to make today...
Worth calibrating what this kind of scanning buys, because the Coldcard bug is a useful negative example and the vendor said so themselves.
Their own AI-assisted review, weeks earlier, missed it. That is in Coinkite's technical backgrounder, and they were blunt about it: both sides have the same tools, and this time it helped the attacker and not them. So "AI scanning finds vulns" and "AI scanning would have found this vuln" are different claims, and the second one has already been tested and failed.
Why this particular bug is scanner-resistant. Read the wallet's own source and you see a call to a random-bytes function from a crypto library. It looks correct. It is correct as written. The defect is which implementation that name binds to at build time —
ngu.random.bytes()resolving to MicroPython's software fallback instead of the hardware RNG, inside a submodule. The vendor's phrasing: the PRNG "is from a submodule that I didn't know was actually in the source code base."A scanner pointed at the application repo sees correct code, because the code is correct. The bug lives in the resolution, one layer down, in a dependency nobody listed as security-critical.
And the output gives you nothing. This is what makes RNG bugs a category of their own. Feed well-seeded and badly-seeded CSPRNG output into dieharder, NIST STS, any entropy estimator — both pass. A PRNG's entire job is producing output that looks random. There is no test on the bytes that separates 40 bits of real entropy from 256.
What the $10k does buy, and it is genuinely worth having: memory safety, injection, auth logic, key handling mistakes visible in the code under review. That is a real class and real money saved. I am not dismissing it.
What actually catches the Coldcard class is runtime instrumentation, not review: a boot self-test that asserts the TRNG was read during seed generation and fails loudly if it contributed nothing. That is a different discipline, rarely commissioned, and nobody sells it as a scanning product because it requires the device.
And the user-side version of the same idea, which is why I keep repeating it: dice.
printf '<rolls>' | sha256sumcompared against the entropy hex the device displays proves your rolls were used and nothing else. It does not test the RNG — that is impossible from outside — it removes the RNG from the trust chain. That works whether or not anyone audited anything.On the marketing point in the post: probably fair, and it can be simultaneously true that he is good at promotion and that the scanning is worth doing. The thing to be skeptical of is not the service, it is the inference that this class of tooling would have caught the thing that just happened. The vendor already ran that experiment.