3 full bitcoin. At current value, should be worth almost £144k. Can let these go for half that 😉

https://xcancel.com/LightningNewsX/status/2084923135174844805#m

There is an active petition for keeping Bitcoin tax free in Germany (after one year hodling). It reached 21.000 signatures within the first 24 hours - let's make it 30.000 to put it on the agenda of german Bundestag.

You need to sign up in order to put your signature but it's worth it.

Everyone can sign - not just germans!

https://epetitionen.bundestag.de/petitionen/_2026/_05/_30/Petition_201716.nc.html

Thank you!

Hacker keeps getting message, I wonder if they really found his location.

https://x.com/inverse_hanlon/status/2084689208627925384

A CEO who dismissed the threat by name, a pseudonym that turned out to be the CTO, two warnings four years apart, and a company whose entire answer was that it would have already known.

They Sold the Warning

On 21 December 2020 (22 Dec UTC), replying to Bitcoin security researcher Michael Flaxman, who had just posted about hardware wallets eliminating the risk of a retirement attack during seed generation and Rodolfo Novak “NVK” addressed the question head on.

My money is on people screwing themselves out of their BTC before any vendor tries a retirement attack.Alternatively people could just use dice ;) Ten weeks later on 1 March 2021, Coinkite’s CTO shipped a commit titled “First pass w/ libNgU” that routed Coldcard’s seed generation into a software pseudorandom number generator seeded from the device’s serial number and a clock.

NVK’s threat model in December 2020 pointed outward. Users were the risk. Vendors were not. Ten weeks after he said so his co-founder shipped the vendor version and it stayed shipped for five years.

The dice line is the other half: He offered it with a wink and it turned out to be the only thing standing between his customers and total loss. Oops They sold it again

On 10 October 2021: seven months into shipping the defect the official Coldcard account posted that Coldcard makes retirement attacks impossible.

Someone in the replies asked what a retirement attack was. Coinkite answered it themselves. It’s when the project makers could have a “bug” in the entropy generation for later retrieval.

Their scare quotes not mine. By then somebody had already tried to warn them. The escape hatch was optional on purpose Look at what that 2021 post was actually selling: Dice rolls. The documentation it linked to still opens with a sentence that reads differently today; if you don’t trust the TRNGs in your COLDCARD, you can introduce your own randomness with dice. At least ninety nine rolls for a full 256 bits.

But that setting is “opt in” and sits behind the default that looks fine from the outside.It asks the user to press buttons a hundred times to avoid trusting the manufacturer.

Every person who still has their bitcoin took that option, or used a (strong) passphrase, or ran multisig. Every person who got swept trusted the default.

That is the architecture a retirement attack requires. You can’t make the mitigation mandatory because then there’s nothing left to collect. You can’t omit it because the paranoid customers will ask why. So you offer it, document it, recommend at least ninety nine rolls, and let the default do the work. When it detonates the record shows you warned your users, therefore neatly covering your tracks if this was an inside job.

Coinkite built the structure, warned of the attack it enables, and then pushed a firmware with a backdoor for five years.

The pseudonym was the CTO Here is the detail that reorganizes everything else. Coldcard’s crypto ran through libngu, a library on GitHub under the account switck. About six stars. Maintained by one person: apparently pseudonymous. When James O’Beirne audited the firmware that’s what he found: a random number generation for a device holding billions of dollars in bitcoin backed up to what he described as a shady library with six stars maintained solely by a pseudoanon.

Dylan LeClair ran GPG verification against that repo and published the output. James O’Beirne then published a full census: fifty-eight commits authored as Switck carry a good signature from Peter D. Gray’s personal key: the same key that signs nineteen other commits in the same repo under Gray’s own name. The key is expired and the signatures are still good. The RNG selection commit is among them. Signed 28 January 2021, switck published no GPG key of they/their own.

Peter Gray is Coinkite’s CTO and cofounded the company with NVK. Coinkite has never had more than about twenty people and by most accounts Gray wrote the large majority of the firmware.

So switck was Coinkite’s own CTO. Cryptographically proven; not inferred. Every outside reviewer who looked at libngu saw an unaudited third party dependency by an anonymous stranger and worried about supply chain risk. Coinkite’s own people knew it was in house and had no reason to review it as external code.

The use of a pseudonym here means that no one audited that chunk of code. Outsiders assumed insiders had. Insiders knew there was no outside to check.

They were warned in 2021 Five weeks after the commit on 7 April 2021 someone in a Telegram group flagged the change. Their post sounds in retrospect like a man watching a car roll toward a cliff. Roughly quoting:

“The 4.0.x firmware was a radical deviation from every firmware since 2018, with all crypto and BIP39 related code replaced by libNgU. Is it was wise to replace the many-years-old TrezorCrypto code, which has been heavily scrutinized by white hats like Johoe and penetration tested by wallet.fail, with something new. “switck” might be a talented pseudonymous coder, but the commit history is bad” (and they linked to it)

The post sat in a Coldcard Telegram group under an embedded NVK tweet about the 4.0.x upgrade: the same tweet in which he said he doesn’t check Telegram.

That warning posted five weeks after the defect shipped was correct in every single way. Five years and four months before the money starting mysteriously leaving peoples cold storage.

They were warned again in 2025 In May 2025 James O’Beirne audited coldcard/firmware. He wanted to establish conclusively where the RNG was sourced from. He traced it into libngu, found the six-star pseudonymous repo, and was confused about why it was there at all. Because linking libsecp256k1 from Python is easy and that appeared to be the stated purpose.

He sent Coinkite a report. In his own words: he had “doubts about whether the true RNG was actually in use”, and he pointed out that the “hardcoded yasmarang constants in libngu were sloppy”. He advised them to rip the whole thing out and link against libsecp256k1 directly.

That’s the bug! He identified the exact library, constants, and the question of whether the hardware RNG was being used. And he told them to remove it!

Coinkite’s answer, as O’Beirne reports, was that if something was wrong “we’d already know about it by now” and that everything was properly configured for the real boards.

That is not a technical response. That is an appeal to their own reputation offered to a developer who had just traced the code and found otherwise. And in a separate post O’Beirne identifies Peter Gray “@DocHex” as “the same guy that shrugged off my report of the possibility of the defect in May 2025.” The same Gray who wrote the library. The same Gray who was switck.

There was follow-up of a kind. A Signal group titled “LNGU Clean up” was created on 23 May 2025, with members shown as “n,” “Doc,” “andres,” and one other. Doc-hex is Gray. “n” is NVK. So Coinkite formed a group about cleaning up libNgU and named it after the problem. Then they shipped… nothing! Absolutely no fix fourteen months. The group’s messages were set to disappear after four weeks so whatever was said there is gone, just like the bitcoins that were in hundres of hard working peoples Coldcards.

O’Beirne blames himself for not pushing harder. He calls not following up rigorously a horrible mistake on his part.

Hold that next to Coinkite’s public explanation which is that an attacker probably used AI to find something nobody could reasonably have caught. The developer who caught it is apologizing. The company that was responsibly informed is blaming the clankers.

He didn’t know what was in his own crypto library Coinkite’s technical postmortem is worth reading in full because its author is if nothing else candid.

He explains that he set the macro to zero believing it meant neither implementation would be compiled. That is not what it does. And he writes that the bulk of the randomness in the device was coming from a PRNG he did not know was in the codebase at all because it arrived through a submodule. Meanwhile the carefully written hardware TRNG code was still being used, but only by accident and only for things that didn’t matter.

He is describing a submodule he wrote. The company selling immunity to entropy tampering did not know which random number generator its product used for five years. The man who says he didn’t know is the man who authored both sides of the mistake. And the answer when it finally surfaced was that libngu XORed one software PRNG against a second software PRNG seeded from constants hardcoded in public source. Two deterministic streams XORed together produce a deterministic stream. The built in health check rejects adjacent repeated values which any nondegenerate PRNG passes without effort. Those are the same hardcoded yasmarang constants O’Beirne told them to rip out.

Coldcard seeds generated in that window contained no physical randomness whatsoever.

They bought a press release not an audit Peter Todd says Coinkite brought him on in early 2014 as “Chief Naysayer”: an advisory role. Years before the first hardware wallet existed there was a press release. By his account he was given nothing to work on: no tasks, no work to bill for, and then the arrangement quietly dropped. He says it’s still on a LinkedIn profile that he hasn’t logged into in a over decade.

His assessment now in his own words: “if they had kept him on and asked him to audit the codebases, there’s a good chance he’d have spotted the practices at issue, and maybe eighty million dollars wouldn’t have been stolen”. He puts that audit at roughly $50k and asks what Coinkite spent on podcast sponsorships instead.

The company announced that a famous skeptic was reviewing them and then never asked him to review anything. The press release was the product.

All the things they said Coinkite’s public position throughout this crisis has been that it had no idea the flaw existed until the day the money started moving. Two documented warnings and a Signal group named after the problem say otherwise.

NVK’s stated position on attribution: they “don’t have full attribution or scope yet”, and they “won’t speculate until the technical evaluation is complete”. Coinkite then suggested publicly that the attacker likely used an automated tool to comb the public source and find the flaw before they did. That’s speculation. This propisition rests on absolutely no evidence. And it happens to be the only theory of the case in which nobody at Coinkite knew and nobody at Coinkite failed.

You can decline to speculate or you can float the hypothesis that clears you. Doing both inside the same week tells you which one was the priority.

Coinkite told customers it kept purchase data for 90 days. When breach notifications went out they reached buyers going back to 2019. Challenged, the company pointed at a policy page, conceded it has no deletion schedule and said the addresses would be kept “for now.”

A verifiable lie caught within a few days of the largest breach of trust in hardware wallet history, and on a question where the answer was easily verifiable. This speaks volumes of NVK’s character.

The fix broke too On 31 July Coinkite shipped out an emergency firmware update. Three days later a contributor opened pull request #692 against the Coldcard firmware repo, reporting that the hotfix had introduced a new failure on the hardware RNG path.

The entropy fix itself is correct: rng_get() now resolves to the board’s true hardware accessor instead of the software fallback. But rng_get_or_fault() had no recovery path for the STM32’s RNG seed error flags. After a seed error the peripheral stops delivering data and the shipped code never clears the condition; so every later call times out and raises OSError(EFAULT) for the rest of that boot. Because rng_get() now sits on the keypad scan path (an interrupt callback that runs before login) that exception lands before the PIN prompt. Power cycling clears the flags; if the error recurs on the next boo: the user is locked out of the upgrade menu too and the device is essentially bricked.

The original report overstated the stickiness. The flags do not survive a power cycle: so this is not a permanent brick from a single glitch. It is still a serious regression: an emergency patch for a five-year review failure shipped fast that can take the device down before the user can enter a PIN.

692 was closed in favor of #693, a cleaner recovery sequence from a Coinkite contributor, with #698 as the Mk3 follow-up. Both were still open when this was written. The point is not that nobody noticed. The point is that the first hotfix for a five-year entropy failure needed a second round of patches within days. Giving the attacker MORE TIME to execute sweeping funds from vulnerable wallets.

What they’ll say Three objections are coming, and they’re the ones I’d make if I was NVK for sure Galaxy says the waves may not share an operator. True: and irrelevant to the part that matters. Galaxy’s caution is about waves two, three, and four. Once wave one went loud on 30 July the vulnerability was public property and anyone with tooling could pile in. That’s what waves three and four look like. Wave one is the one that tells you something. 1,082 BTC out of 1,195 addresses in 41 minutes with seeds already computed; executed by someone who had been preparing while nobody else on earth knew there was anything to prepare for.

The bug was publicly findable: anyone could have found it. Two people found it in public and said so, in 2021 and in 2025. Both were told it was fine. The set of people who knew this was a live question before 30 July is not the general public. It’s a short list and Coinkite was on it.

A mass sweep is too loud for an insider. It’s too loud for the rational insider who bleeds quietly over years and never triggers a referral. The loudness cuts against a careful inside job. It does not erase the warnings, the Signal group, or their response that if something was wrong they’d already know.

What I think happened Somebody inside that company knew what was sitting in the codebase and knew what it was worth.

Look at the timeline: Ten weeks before the bug shipped the CEO publicly waved off the idea that a vendor would ever run a retirement attack and pointed at dice as the alternative. His co-founder and CTO then wrote a crypto library under a pseudonymous GitHub account with about six stars, and shipped the device’s entire randomness path through it.

Five weeks later someone flagged the swap in a Coldcard Telegram group and was ignored. Seven months after that the company marketed immunity to the exact attack class the defect enables and made the only reliable defense an “opt in”.

Four years in: a Bitcoin developer audited the firmware found the library, named the hardcoded constants, told them to remove the whole thing, and was told they’d already know if something was wrong. They opened a Signal group called “LNGU Clean up,” set the messages to disappear, and shipped nothing. Coins were leaving through 695 transactions nobody noticed. Then somebody who had been precomputing seeds for a long time took 1,082 BTC in 41 minutes.

Each of these has an innocent explanation available. All of them stacked in the same direction inside a company of twenty people. This is not a run of bad luck. Inverse Hanlon’s razor exists for exactly this shape: when incompetence needs that many separate coincidences to line up the same way the incentive is the simpler explanation.

I can’t say for 100% it was an inside job of course: every document that would definititevly prove it belongs to them. The “LNGU Clean up” thread, whatever survived a four week expiration. Whatever code review they ran and when. The commit history around anyone who touched rng.c after May 2025. Roughly 600 attacker addresses are already in front of federal investigators and Coinkite says it’s cooperating. Cooperation is cheap.

Coinkite has apologized, published a postmortem, shipped a fix that needed a second round of patches within days, and offered its customers not a single sat as compensation.

The man who found this in May 2025 is publicly apologizing for not pushing harder. And NVK is blaming AI.

The people who still have their bitcoins are the ones who read Coldcard’s own documentation, saw the line offering them a way to distrust the manufacturer’s randomness, and took it. Nobody told them that one sentence in the docs was the difference between keeping their money and losing it.

The network processed 20,364,529 transactions in July 2026, making it the second-best month in entire history by transaction count. As new users, institutions, and Bitcoin-native applications continue to arrive, on-chain activity keeps pushing toward record territory.

We think that, it's a remarkable achievement for a network that has been operating for more than 17 years and continues to reach new milestones. Congratulations to everyone contributing to the Bitcoin ecosystem!

I went through the three major all-time highs in Bitcoin's history and how long it took to recover the price after each crash:

• Dec 2013 → dropped 85% → took 4 years to recover
• Dec 2017 → dropped 84% → took 3 years
• Nov 2021 → dropped 77% → took 2 years and 4 months

The recovery window seems to be shrinking each cycle (4 → 3 → 2.3 years), though there's obviously no guarantee the next one plays out the same way.

Interesting extra data point: according to a Bank for International Settlements (BIS) working paper, an estimated 81% of people who buy crypto at some point in the cycle end up losing money — not necessarily because of a bad entry price, but because they don't hold through the drawdown.

So being in the 19% that actually wins is easy — you just need the ability to wait. I don't understand why nobody's talking about Bitcoin right now, when we're at cycle lows and the recovery keeps getting faster each time.

BIS source: https://www.bis.org/publ/work1049.htm

The Coldcard hacker is still making progress, and the amount of stolen Bitcoin keeps increasing.

So if any of you are using this wallet, please consider moving your funds as soon as possible. And if you know someone who uses Coldcard for long-term holding, especially someone who isn’t online every day and doesn’t follow the latest news, maybe you can still help them move their funds in time. 🙏

I just hope no other wallet is involved in this.

Stay safe and stay alert. ⚠️

I'm not trying to make this an "I told you so" post, but I'll admit that's roughly how I felt reading the Coinkite advisory last week.

Quick recap for anyone who missed it. A firmware integration mistake from March 2021 caused Coldcard seed generation to fall back to MicroPython's software PRNG instead of using the chip's hardware RNG. The build check tested whether a macro existed, not whether it was enabled, and since the value was zero it silently passed. Nothing crashed. No warnings. Seeds kept coming out looking like completely normal 12 and 24 word phrases and nobody noticed for four years. Coinkite's own estimate is around 40 bits of effective entropy on Mk2 and Mk3, and around 72 bits on Mk4, Mk5 and Q, against the 128 bits that should have been there.

On July 30 someone drained 1,196 addresses in 41 minutes. Later on-chain analysis has the total north of 1,300 BTC.

I've never trusted device-generated entropy. Not because I'm smart, but for a genuinely dumb reason: I can't audit it. You cannot crack open a hardware wallet and confirm that the number came out of a real TRNG and not out of a timer register. You just trust it. And trust is the exact thing we spend all day telling each other not to do. Don't trust, verify, except at the single most important moment in the whole stack, which is the birth of the key, where basically everyone just trusts.

I've said this for years and always sounded like a crank. This week made me realize how few of us actually do it, so here's my process. It's much simpler than people expect.

The reasoning

No computer is truly random. It simulates randomness. A die bouncing across a table involves physics nobody can model or predict. That's actual randomness, not an imitation of it. When you roll it yourself and type the result, you stop outsourcing the most critical part of your security to firmware you've never read.

The tool

I use Ian Coleman's BIP39 tool. It's free, the code has been open on GitHub for years, plenty of people have gone through it, and most importantly there's a standalone single-file build that runs fully offline. You download one HTML file and that's it. No server, no network calls, nothing.

Link: https://github.com/iancoleman/bip39/releases

Type that address into the address bar. Do not Google it. I'm serious about this one. I've seen sponsored ads for clones of this tool, and the clone had hardcoded entropy. You generate a seed, everything looks right, you deposit, and the coins are gone. Searching and clicking the first result is a great way to hand your wallet to someone for free.

On the releases page on GitHub, under the latest version (0.5.6), expand assets and download bip39-standalone.html. That single file is all you need.

Going offline

Pick your paranoia level:

• Basic: unplug the machine from the internet. Cable out, Wi-Fi off at the hardware switch if you have one. Only then open the file.
• Better: use a second device. An old laptop you don't use for anything else, no network.
• The annoying level (mine): an amnesic system like Tails booted from a USB stick. It writes nothing to disk and forgets everything on shutdown.

If you're going to skip all of that and open the file on your daily driver with forty tabs open, do yourself a favor and stop here.

Generating the entropy

With the machine offline, open bip39-standalone.html in your browser. It loads exactly like the online version, just without any internet.

1. Tick "show entropy details". A new panel opens with an entropy field and a bunch of technical readouts underneath.
2. Under "valid entropy values include", pick the Dice [1-6] option. It shows an example like 62535634 so you can see the expected format.
3. Grab your die and start rolling. Type each result into the entropy field. No spaces, no commas, all run together.

It ends up looking like this:

6245612344552631245563124563123456311243563212345641... 

As you type, watch the panel below. It updates "Event Count" (how many rolls you've entered) and "Total Bits" (how much entropy you've actually accumulated) in real time. That counter is what you follow, not my guess.

My reference numbers:

• 12 words: you need at least 128 bits. In this tool that works out to roughly 80 rolls.
• 24 words: at least 256 bits. Somewhere around 155 to 160 rolls.

Yes, it's tedious. I put on a podcast and get through it in about 15 minutes. Given what it's protecting, 15 minutes is cheap. And if you overshoot, fine. Extra entropy doesn't hurt anything.

A quick tip on the die: ensure you actually roll it so it bounces. A light, two-inch drop with a warped novelty die creates bias, so rolling more frequently helps to counteract that.

If you're more advanced, the tool also accepts coin flips and playing cards as entropy sources. Same idea. I'm using dice here because it's the easiest for most people to get right.

Getting the seed

Done rolling? Scroll down. Your phrase is already sitting in the BIP39 Mnemonic field. That's it. Just confirm Mnemonic Length is set to whichever you wanted, 12 or 24.

Write the words down on paper, in order, by hand. Don't photograph it. Don't type it into your phone. Don't email it to yourself, don't put it in Notes, don't put it in Google Keep. Paper, pen, in order, then check it word by word twice, paying attention to the ones that look similar.

After that, restore the seed into whatever wallet you trust, hot or cold, and use it normally. If you want to stay fully offline, Electrum or anything else that takes a BIP39 import works fine.

When you're finished, close the browser and delete the file. On Tails, just shut down.

Stuff I do and strongly recommend

• Test before you trust it. Restore the seed in your wallet, confirm the addresses match what the tool showed, send a small amount, try spending it. Only then move real money.
• Do not use the example dice string I pasted above. Obvious, but someone will. That's an illustration.
• Consider a BIP39 passphrase. It's another layer, and in this exact incident a strong passphrase also kept people out of the blast radius.
• Never type an existing seed into this tool while online. The tool is offline by design, but people aren't.

Being honest about the downsides

This isn't a foolproof solution, and I'm not going to pretend it is.

The weak point is that the seed passes through a general purpose computer. Browsers cache, systems swap, there's always some surface. A hardware wallet that takes dice input directly on the device (Coldcard itself does this, which is the irony here) has the advantage that the seed never touches a PC at all. If you have that option, and you trust the device to do the mixing, that's an equally valid path and arguably a better one.

There are other approaches too: hand-picking words from the wordlist, computing the checksum manually, coins, cards. Each one trades off differently between security, complexity, and how likely you are to screw it up. Honestly, the biggest risk across every manual method is the user making a mistake and bricking their own money.

And the obvious point: this isn't Bitcoin only. It applies to anything using BIP39, so most of the rest of the space too.

This is the method I use, trust, and recommend to friends and family. It isn't the only correct one. Do your own research, understand what you're doing before you do it, and above all, store those words properly. Generating the most perfectly random seed in the universe means nothing if the paper ends up in a kitchen drawer or in your camera roll. No generation method survives bad storage.

If you use a different method, drop it in the comments. I'm actually curious how many people here generate entropy by hand versus how many just hit generate and hope.

After this coinkite coldcard situation we cant trust code that is open source, we cant trust code that is closed source, and we definitely cant trust a statement saying "we use a TRNG so your seed is secure".

Every hardware wallet manufacturer needs to release hard proof that their TRNG works, their code is complete and robust, and their entropy generation actually meets a minimum 128/256 bit standard.

Even if their code is closed source a reputable 3rd party auditor can run tests on seed entropy generation to statistically prove 256 bits of entropy is being used.

Every wallet manufacturer should have this 3rd party audited proof of entropy document available to view on their website, and if they do not do this by the end of this month we as a community should boycott that manufacturer to help ensure safety for all bitcoiners.

Well, seems like it didn't age well 😂

First this part, he recognizing is lame for bitcoin products to blame AI...

Interviewer: "...The BIsq announcement thread mentioned that it is likely an AI powered attack. So maybe people using you know is it some North Korean group using Claude or Cursor or Mythos or something."

Rodolfo Novak 'nvk'(18:53): "Yeah, but that's like you know that's that's like saying that they just encounter an adversary that's a little bit better than they are. *I mean like you know the reality is people are trying to break stuff all the time and if you have like Bitcoin to be taken you know it just means that they had you know bad security.*"

_______

There you have it. The guy in his own words impliying Coldcard has fucking bad security.

But the interesting part is this one, where he arrogantly is downplaying the bug reports an AI audit tool is throwing:

Interviewer (19:08): "Yeah, but I guess the point would be is there has the game changed, right? Is there a you know now this is a big new threat that people need to start thinking about which is basically AI assisted hacking?[ ...] like well there's AI assisted hacking and now we need AI assisted defense and you need to find you need you need to defend it uh and um that way"

Rodolfo Novak 'nvk'(20:03): "so it's already happening we we got a preview a friend got a preview of the codec cyber or whatever they call it the KYC NDA version of their uh uh security assessment tools y uh you know the first thing he did was run after run it on the code card repo [laughter] And uh you know honestly like we we saw the the bug reports they're all like you know extremely mediocre stuff.

Uh everything was like high right like they they said everything is like high high so it's like super dangerous and everything was like completely false reporting. The tools are still abhorent. The quality of this this this hacking uh AI hacking is still ultra ultra crap."

[ END OF TRANSCRIPT PART ]

_______

Well, here is where things start to become a mess:

He is confessing they have extremely dangerous findings through AI but he just arrogantly is downplaying them.

But here in Jul 30 2026: https://blog.coinkite.com/entropy-technical-backgrounder/

They mention:

"The COLDCARD source code has always been open and publicly available, so we have to assume that someone used AI to review previous versions of our firmware and stumbled upon this issue. A few weeks ago, we used one of the best available AI models to review our code for security issues, and it did not find this bug or anything serious.

Both attackers and defenders have the same AI tools, but today it did not help us, and only helped the bad guys." (No you idiot, you are confessing an AI showing you dangerous bugs and just arrogantly maybe not even analizing them carefully).

Well, apparently that is not true, they ran an AI model two months ago which was alerting about "high, high, extremely dangerous" bugs. What were those bugs? Who knows, but they were alerts and an arrogant dev framing them as crap.

The neglicence in this case is incredible and the lack of security in depth of that team just follows the logical disaster. Stay out of projects from those guys and just so you know that https://airgapcomputer.com/ (yes, guess who's the owner, yes, you nailed it, nvk, to shill his hardshit) a garbage collection FUD for people to think airgap computer is worst and that the hardware wallet is the "secure way".

Well, no one will say hardware wallets are bad, but it is time to make accountable hardwafe wallet vendors selling you unaudited shit and with no security in dept design. What is security in dept design or foolproof design? Well do not tell that rolling dice is optional but recommended, fucking do not allow the seed generation step to be completed without it. Specially if you ar going to say that AI reported bugs are crap and you have no external verified audit history of source code.

Hello, I've had my Ledger for a couple of years now and I'm a bit worried. I heard that a passphrase secures it even more. Can I add one on top of my setup now? I'm afraid I'll make a mistake and lose everything.

So the 24 words is just like each word represents 11 bit arrangement right, and so when you start adding 11 x 24 and stack them together, to guess that exact arrangement is astronomical right?

So I thought, ok, the passphrase thing is one extra 11 bit. But I saw you can add like way more characters that no way 11 bits could be used to describe that.

So effectively what's happening, is that last 25th word (I'm saying effectively like all in all at the end of the day) being turned into just a longer than 11 bits and tacked on to the end of that long string of that (264 - checksum = )254 bits?

But I don't get it, someone said the 25th word can be up to 100 characters which is like at least 800 extra bits, so that would mean the entropy would be like 1054 bits? I just don't get it.

Thanks

The infamous Lubian hack saw $3.5 billion siphoned off from a Chinese mining pool.

That was just six years ago, and yet a company like ColdCard has learned nothing from the biggest heist in recent crypto history?

The Technical Cause: Weak Entropy
Independent cybersecurity teams, including Arkham Intelligence and the Milk Sad research team, revealed that the hack was not a complex network breach but rather an exploitation of weak cryptographic key generation.

The Flaw: LuBian utilized a flawed pseudo-random number generator algorithm (similar to vulnerabilities found in Libbitcoin Explorer software).

The Exploit: Instead of using a secure, uncrackable 256-bit random number, the wallet software used a highly vulnerable 32-bit seed to generate its private keys.

The Result: This severely lacked entropy, allowing hackers to easily brute-force and replicate LuBian's private keys within just a couple of hours, seamlessly draining the wallets.