matt
Matt Corallo

https://bluematt.bitcoin.ninja

10th known contributor to Bitcoin Core. Now Full-Time Open-Source Bitcoin+Lightning Projects at Spiral (Part of Block).

Public Key

npub185h9z5yxn8uc7retm0n6gkm88358lejzparxms5kmy9epr236k2qcswrdp

NIP-05 Address

Profile Code

nprofile1qqsr6tj32zrfn7v0pu4aheaytdnnc6rluepq73ndc2tdjzus34gat9qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds2ehyh5

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub185h9z5yxn8uc7retm0n6gkm88358lejzparxms5kmy9epr236k2qcswrdp

Show more details

Last Notes

2026-08-05 22:59:44 CEST

- reply

Actual issue on the wrong hardware wallet…they’re just banking on “you heard about the hardware wallet hack…”

2026-08-05 22:35:30 CEST

Yet more phishing attempts.
https://image.nostr.build/4394a9b3862a04693ffde9c7e1e76087a3692a88c4478d27dc111ac72096f8d8.jpg

2026-08-05 13:38:43 CEST

- reply

It definitely is, but I’ve seen some people reproduce the issue without that and the agent automatically fetched the submodules.

2026-08-03 16:37:22 CEST

- reply

Only if you put each word back in the bag after you pull and shake the bag really, really, really well (probably means the bag needs to be very oversized, if I had to guess).

2026-08-03 16:36:26 CEST

- reply

That’s what suggestions 1,3, and 4 are meant to address.

2026-08-03 13:26:20 CEST

- reply

I dunno about that. If you have a source that’s just 32 bits (eg device ID) it’s not clear to me it’s worth including. Yes, if you screw everything else up it might save you, but in nearly every instance of weak entropy wallets a defining feature was some low entropy 32 bit counter that hid the bug. It seems like it’s worth banning this.

2026-08-03 13:06:49 CEST

- reply

Sure, that’s a reasonable approach. Even just two HWRNGs (they’re cheap!) is better than one.

2026-08-03 13:01:36 CEST

- reply

> I think I'm misunderstanding the mechanics. I said 'inputs' to mean exactly 'pre-whitening'. But i have no idea exactly how it would work on Linux. Claude told me yesterday that it's deliberately made almost impossible to do, which makes a lot of sense, if true.
Right, the suggestion doesn’t work on the Linux RNG, it was more targeting embedded devices.
> Re: 'at least one validated', yep, that seems to be the right general idea.
Right, this part does work on Linux - use the OS RNG but also use mouse movements or whatever and check that you get enough entropy there. Maybe check for a TPM and pull bits from that, etc. Probably at least one source you can either fetch pre-whitening or you can access a success/fail result because the device checks for you.

2026-08-03 03:28:32 CEST

- reply

#nevent1q…d2vw

2026-08-03 03:28:07 CEST

- reply

Not really. Once the weak entropy has been hashed you’re likely to miss issues. A million might give you a collision with only 32 bits of entropy, sure, but 60? Still brute forceable, but you won’t see it with such a test. Might be useful, but not as useful as the manual process I suggested in (4).

2026-08-03 03:26:36 CEST

- reply

Anyone can do an LLM scan! Before buying your next hardware wallet, ask a frontier LLM to review their firmware!

2026-08-03 02:40:19 CEST

- reply

Oh that’s definitely been happening. Lots of people have been *busy* this weekend.

2026-08-03 02:23:13 CEST

It’s still early, but it’s not at all the case that we cant learn anything from this and do better. If I were a hardware wallet manufacturer, I think my takeaways/changes I’d make are:
1) insecure fallbacks or hashing in weak entropy should be explicitly verboten. Unless it’s 96 bits or higher, do not include it!
2) Anything generating keys on an embedded device should have at least two random inputs and should check them with even basic randomness tests. This requires pulling lots of extra bits in before they’ve been whitened which isn’t possible on all hardware, but hardware that does whitening usually will do tests for you so make sure you’re checking it! #nevent1q…9vun
3. (Obviously) Everyone should be doing regular LLM reviews of software and firmware.
4. HWWs should have an explicit QA step where each input to the RNG is logged and the result of adding those inputs together to build a seed is done on a separate device with a reimplementation and compared against the device's seed. This should be done for each firmware release.
I doubt almost any HWWs today do 2&4.

2026-08-03 02:11:23 CEST

- reply

> Test before hashed/ whitened: yes. That was my original thought. But as others pointed out, that's not the same thing as what the whole process outputs.
Sure, but screwing up XORing three validated chunks together is harder than screwing up one. It wouldn’t have saved this case (which was ultimately a failure of having an insecure fallback in the code at all, which shouldn’t be allowed!), but it should be common practice.
> Also as per your comment with HWW, isn't it super-hard/impossible to check the *input* to dev/urandom's CSPRNG, in practice?
On Linux? Sure, that’s ultimately because it’s post-whitened/hashed which makes it hard to validate. That doesn’t mean it couldn’t be XOR’d with more but probably we should be requiring at least one “validated” input to any RNG for key generation.

2026-08-02 18:18:59 CEST

- reply

The closed-source stuff is more complicated, of course, but I’d expect any HWW to have at least two streams of actually random values and going forward I’d expect them to be (if at all possible within reasonable bounds) pulling a few KiB of output from each and doing at least basic statistics tests on them.

2026-08-02 17:34:43 CEST

- reply

All the more reason for defensive coding in RNGs. Sadly this isn’t the norm (does anyone do it?) but hopefully it can become it…
#nevent1q…9vun

2026-08-02 17:25:55 CEST

- reply

That’s definitely not true. If you can run a test on the bits (and can extract a few orders of magnitude more bits than you need) before you use them and before they’re hashed/whitened/etc, you can absolutely test for quality. You then take a few sources that you’ve tested and xor/hash it all together and you’d be fairly confident in your robustness.
Sadly, many HW RNGs do whiten the output before you get it so it may not work everywhere, but some HWRNGs do test their data before they provide it!

2026-08-02 12:12:45 CEST

- reply

Sure, my only point was that it’s possible to take a conservative approach to RNG with additional checks in place that could catch bugs. It’s not the case that RNG bugs are only possible to catch in review.

2026-08-02 02:59:31 CEST

- reply

It’s not entirely hopeless. Running hardware RNG output through basic entropy tests prior to hashing/use could have saved everyone a lot of headache. I don’t know that people do this today but probably we should all start!

2026-08-02 00:34:03 CEST

- reply

Doesn’t mean any of us should feel good that so many people lost their real money.

2026-08-02 00:09:01 CEST

I’m gonna be honest, as much as I think bitcoin is important for freedom in the long term, it really doesn’t feel great working in bitcoin this weekend.

2026-08-01 12:29:02 CEST

- reply

Hell yea.

2026-08-01 02:32:19 CEST

- reply

💯

2026-08-01 00:31:29 CEST

- reply

And, again, this was well before anything was public and they weren’t searching, they were analyzing the code. One of them was even skeptical cause it seemed too broken!

2026-08-01 00:30:44 CEST

- reply

I think you drastically underestimate how much people have scanned things with LLMs! Also they might have tried six months ago but the models are much better today than at the beginning of the year!

2026-07-31 23:54:51 CEST

- reply

I can only go on my experience from yesterday and testing on LDK. Yesterday I know at least three people who asked three different LLMs to find the coldcard issue before any details were public and all three successfully found the issue. On LDK we’ve been doing code scanning and they have found many issues (most not critical security ones, but real problems with fixing, and some important security fixes as well!)

2026-07-31 23:26:59 CEST

- reply

Well, I’m not sure if a model from a year ago would have found it, but, yes, absolutely no one asked the question in the past three to six months…. Until this week.

2026-07-31 23:22:00 CEST

- reply

Anyone with a Claude or OpenAI subscription absolutely had no problem finding the ColdCard bug a week ago, if they looked.

2026-07-31 23:21:16 CEST

- reply

No, I mean people who reproduced the issue before it was public. The only prompts were things like “there appear to be funds getting drained from coldcards, let’s look at the firmware and find the bug”.

2026-07-31 23:04:10 CEST

- reply

Now, maybe they promoted it with “there’s an issue leading to drains!” Rather than “do a review”, but could always start with that.

2026-07-31 23:02:52 CEST

- reply

Of coldcard? I know several people who asked different LLMs yesterday and each immediately found the issue.

2026-07-31 22:58:17 CEST

LLMs are very two-sided for security.
On the one hand, long-latent bugs are finally surfacing.
On the other hand, before you choose to use a product, you can get your own code review done for incredibly low cost*!
In the short term it’s incredibly bad, in the long-term it democratizes code review greatly. “Don’t trust, verify” finally becomes an actual possibility for normal people!
* of course LLMs do still make up issues when asked, push any such review to write PoCs to check their analysis!

2026-07-31 19:25:46 CEST

- reply

The selective sweep was a bug/lazy implementation on the part of the attacker’s LLM.

2026-07-31 18:33:34 CEST

- reply

I mean look at coldcard’s blog too…

2026-07-31 13:07:41 CEST

- reply

Doing so at this juncture would allow attackers to steal additional coins faster.

2026-07-31 13:07:04 CEST

- reply

As long as you did at least 40-50 dice rolls you’re okay. Consider migrating out of an abundance of caution, but no rush.

2026-07-31 13:06:02 CEST

- reply

Correct. If you have N-of-M multisig and N is greater than the number of coldcards you’re in no rush.

2026-07-31 13:04:48 CEST

- reply

We know how to generate good randomness, they just had bugs. Best bet is multisig across different wallets if you’re worried.

2026-07-31 13:03:27 CEST

- reply

Everything true up to the end. Other coldcards also have bugs, not quite as severe but still bad.

2026-07-31 03:58:23 CEST

- reply

I haven’t dug into the specific implementation. My understanding is the dice is combined with the very limited existing entropy (something like 32 bits). Generally if you’re in the 90+ bit range brute force isn’t likely. 64 brute force is still reasonably doable. Obviously variable in between.

2026-07-31 03:52:48 CEST

- reply

If you have an old phone, reset/wipe it, install a good wallet and use that temporarily. If you either don’t know or don’t have confidence in any single wallet product for the amount you’re talking about, your best bet may be an exchange (just be prepared to get hassled for proof of origin of funds…).

2026-07-31 03:49:54 CEST

- reply

6^50 is > 2^128. 50 rolls is basically equivalent to a perfect seed. Fewer of course less so.

2026-07-31 03:48:29 CEST

- reply

Depends on how many. A few rolls? Migrate ASAP. 50 rolls? Don’t ever think about it. Somewhere in between? Depends on how many…

2026-07-31 03:47:23 CEST

- reply

Yes, later devices had a similar but slightly different (and somewhat less bad, though still loose-your-coins bad) bug.

2026-07-31 03:46:31 CEST

- reply

Apologies, the 100 number came from listening to randos lol. The number of required (fair) dice rolls for basically perfect seeds is 50. It’s not a clear line though.

2026-07-31 03:28:14 CEST

- reply

Ha, just 100

2026-07-31 03:19:51 CEST

- reply

Dice rolls provided additional entropy. If you used enough of them (like 100!) then you had perfectly fine entropy from just that. Fewer dice rolls means less good entropy, It’s a sliding scale though, not a cutoff of what is enough.

2026-07-31 03:11:26 CEST

- reply

Migrate them funds!

2026-07-31 03:07:43 CEST

- reply

Worth pointing out, multisig is only fine in an N-of-M where N is greater than the number of cold cards! 2-of-2 with two cold cards is not safe!

2026-07-31 02:50:42 CEST

- reply

I would recommend moving your funds as soon as possible. I’m not 100% sure but I believe you may be vulnerable. Take a deep breath and be smart about where you’re moving to.

2026-07-31 02:40:13 CEST

There are related vulnerabilities in later hardware as well.
At this juncture I would migrate funds off of any single-sig (or multi-sig of only) colcard wallets that were generated on-device without dice or passphrase.
#nevent1q…mzz6

2026-07-23 15:38:41 CEST

- reply

There’s about ten accounts on X promoting BIP 110 that I was even vaguely aware of existing a year ago or am sure they’re a real person as I’ve met them/seen them on podcasts/etc….

2026-07-23 03:48:43 CEST

- reply

Sadly it really wants to over-tune for nodes that send a lot of probes, which isn’t really ideal, but may be able to push it towards having options for everyone.

2026-07-23 03:32:04 CEST

- reply

After I land some updates maybe I’ll put up a website and let people submit their results and throw their agents at the problem.

2026-07-23 03:31:29 CEST

- reply

The same old probing dataset we used to optimize the scoring analysis last time, but with a year and a half more data, a bugfix in the harness, and LLMs trying several totally different approaches to investigate potential directions.

2026-07-23 01:33:19 CEST

- reply

Not directly, no. But if you have a large dataset to build an algorithm from…..

2026-07-23 00:53:59 CEST

LLMs are so well tuned for optimizing the lighting pathfinding problem. Give them a dataset and tell them to optimize a parameter and they go ham.
Big things ahead for the LDK pathfinder and lighting payment success rates.

2026-07-20 02:53:17 CEST

- reply

They all just had fun.

2026-07-19 23:12:16 CEST

- reply

Hell yea. Congrats.

2026-07-18 03:01:55 CEST

- reply

It seems a better answer is to probe some (or download results from others). That way you can discover these channels have capacity before you need to use them.

2026-07-18 03:00:21 CEST

- reply

Huh? No of course you should store a history of received payments, but that’s very different from DoSing yourself by storing generated invoices.

2026-07-17 18:44:49 CEST

- reply

LDK Server…

2026-07-17 18:39:37 CEST

- reply

Payment metadata is more than sufficiently deployed to use it in production today.

2026-07-17 13:42:10 CEST

This idea that lightning nodes, by default, store every single invoice or offer you generate over RPC is insane. There’s no reason to bloat the DB and expose users to DoS risk if they generate invoices automatically, the damn things can be stateless and additional metadata you need can be stored in the invoice and retrieved on payment, rather than stored.

2026-07-12 22:51:41 CEST

- reply

Worst. “Professional” is code for “something a business would buy”, which also means “you’re not the one using this”.

2026-07-08 23:25:33 CEST

- reply

Also heuristic-based replacements please. Strict diagram comparison is nuts and enables pinning attacks!

2026-07-08 21:35:28 CEST

- reply

Honestly why bother? No one uses Spark on the assumption that they can exit or that it’s somehow trustless, the point is that it’s better than custodial and Lightspark is taking on the legal risk instead of someone else.
If you actually care about trustless something you’ve gotta do a graduated wallet or LN+Ark.

2026-07-08 21:33:41 CEST

- reply

Yes…

2026-07-08 19:19:18 CEST

- reply

@npub1vad…nuu7 and @npub1ke4…8jfm since damus doesn’t carry over RT tags.

2026-07-08 19:18:27 CEST

- reply

Problem is any time you transact (and sometimes other times!) the “recovery bundle” changes. So you can’t back it up/download it, your wallet needs to support this natively (and I don’t believe any do).

2026-07-08 14:09:19 CEST

- reply

Zero spark clients today implement unilateral exit without asking a server for their list of coins to exit. Makes it…. Not very unilateral.

2026-07-07 23:15:31 CEST

- reply

Or on top of. L-ARK seems like kinda the best of both worlds if you’re worried about low-balance user onboarding.

2026-07-07 22:08:03 CEST

- reply

I disagree, you could do a graduated wallet, or you could have an LSP that locks up less liquidity and charges comparatively higher fees. Of course in that case the LSP would never need to charge more than on-chain - you still get *some* “compression”.

2026-07-07 20:41:12 CEST

- reply

None of the constraints you raise are required for lighting, they’re just things people did to make simplified versions of the economics of an LSP work out. An LSP putting in a bit more effort, or conjoining the wallet with a graduated wallet design, makes it way more doable.

2026-07-07 17:19:35 CEST

- reply

lol no I mean a mobile app with lightning built in.

2026-07-07 16:59:12 CEST

- reply

Who said anything about hosting a routing node? That’s not what I was talking about at all…

2026-07-07 16:44:30 CEST

- reply

Yea, I think this is the common experience these days. It’s certainly not evenly distributed - there’s lots of terrible lightning experiences out there. But the fact is it’s very clearly possible to make better, so it’s time to put pressure on the developers shipping bad experiences, understand where their applications are going wrong, and help them get to where we know they can be.

2026-07-07 16:42:04 CEST

- reply

Not with halfway competent self-custodial either. I agree there is lots of incompetent self-custodial tho.

2026-07-07 16:41:01 CEST

I fully do not understand the desire of lightning people to build protocols to “buy a channel”. No one has ever wanted to “buy a channel”, they want to buy reliable HTLC delivery. That might imply multiple channels, splicing, and probably implies just-in-time channels, but it definitely doesn’t imply just buying a channel and calling it a day.

2026-07-07 13:11:49 CEST

- reply

> Lightning fails in about 30% of the time
Holy shit what? Let’s debug this. Which issues have you opened to the Lightning implementations and providers you’re using? This is not the experience most have.

2026-07-07 13:10:00 CEST

- reply

Yes, *lighting* has good sender privacy. Some people prefer to use custodial services which don’t. Not entirely sure you can blame LN for that? Though even for such services you can do client-side pathfinding, which admittedly isn’t all *that* common but is very doable and some protocols support.

2026-07-01 00:06:42 CEST

- reply

For now, for the most part, the explicit censorship is done at the hosting provider level and model devs are focused on quality not manipulating output. I imagine that won’t last forever.

2026-06-27 18:30:30 CEST

- reply

Now do inflation-adjusted.

2026-06-25 00:18:41 CEST

- reply

Learn to read.

2026-06-24 13:50:07 CEST

- reply

*on our forge. If someone wants to make a bot that streams moderation decisions onto X or nostr-social-media and people want to discuss those decisions, great! They should! But distracting people trying to focus and work with harassment and brigading on the platform where people work isn’t an option.

2026-06-24 13:44:15 CEST

- reply

Obviously it’s just a question of thresholds. In your specific scenario obviously that’s fine. I may be missing something but AFAIU there’s some kind of nostr standard for how to do git forge on nostr, with multiple clients implementing it. Today, none of those clients support moderation (or, equivalently, restricting events to specific relays per repo). In the future, if all the common clients support that, I don’t see why that wouldn’t suffice. Given the narratives in nostr I assume that won’t be the case, but I could be wrong!

2026-06-24 12:52:22 CEST

- reply

I’m not sure, there’s plenty of bitcoiners with a following who choose to spend their time shitting on open-source devs without any factual basis…

2026-06-24 12:46:50 CEST

- reply

#nevent1q…56ha

2026-06-24 12:46:16 CEST

- reply

I imagine most clients will pull from multiple (public) relays, but I could be wrong.

2026-06-23 15:25:52 CEST

- reply

No I think you misunderstood the requirement. A client-selected moderation option isn’t sufficient, nor is a client-software-specific one. A repo forge is our place of work. People will (and have) taken the fact that allow anyone to comment as a free pass to harass people, throw baseless accusations, and generally be disruptive. They can of course go do that on social media but we can’t have our place of work disrupted by people using it as a bulletin board to shit on us. Having the ability to hide it for ourselves doesn’t suffice - when anyone else looks at our work and sees a stream of “pedos!” and “compromised!” conspiracy theory nonsense that makes it our problem. A nostr-based solution where every client hides crap that we removed would be fine, but I assume it’s quite likely clients would be built that would ignore such moderation and we’d be back to square one.

2026-06-23 01:03:44 CEST

- reply

For now we’re moving to self-hosted forgejo. The current nostr solutions aren’t an option for us as they lack moderation features.

2026-06-20 14:39:19 CEST

- reply

If they’re polarized the right direction, use sunglasses - 50% less brightness from the rest of the world, no chance to the laptop brightness.

2026-06-18 03:12:53 CEST

The thing I love most about Bitcoiners is everyone has their own view of what the most urgent issue for Bitcoin is and they’re all trying to solve it.

2026-06-17 20:23:30 CEST

If you can’t kill it by regulation, kill it by taxation.
#nevent1q…h0ey

2026-06-13 15:34:36 CEST

- reply

Yea, props to Nvidia for investing in remote attestation. The high cost of compute still sucks for everyone, though, even remotely.
3N billion parameter models have gotten much better and most can run them, but the intermediary sizes where hardware is expensive but practical for some ($5k, ish) have seen a drop off in investment as more compute goes into the frontier sizes.

2026-06-13 15:23:27 CEST

- reply

(btw Sparks are way overpriced for what they offer, really shouldn’t buy those at this point!)

2026-06-13 15:22:59 CEST

- reply

I’ve got local GPUs with almost as much memory as a Spark (but way more BW). I was mostly tongue-in-cheek referring to the annoying reduction in 120B-class models lately and the increasing reality that not many can afford to access frontier models lately.

2026-06-13 15:02:48 CEST

- reply

Will HRF give me a grant for $50k so I can buy the GPUs I’d need to run them? :)

2026-06-10 18:58:53 CEST

Two weeks of crazy travel and suddenly I can barely walk out of the gym after my workout. Blood sugar is rough.

2026-06-08 23:17:05 CEST

- reply

Usually when you hear about a custodian storing money with another custodian it’s in the context of fraction reserve or a custodian-failure :)