Whenever monetary incentives are involved, you HAVE to assume the worst. Anything that can be attacked, and money gotten, WILL be. It is outright relentless that way. This is something over the years, I may have just taken for granted as common knowledge but I see that it is not. The reason I went on a "witch hunt" the other day, is I saw a lot of scurrying going on, a lot of "pardon'ing" and calls to not be so harsh with this. I saw people making claims that it may not be their fault, shifting blame tactics and I decided to be loud about it. Did that do anything productive? Probably not, it probably hurt some of my relationships on here, but it was better than silence. I do not think, that this was an isolated mistake. The same systems that promoted NVK into a position to rug people this easily, are still there. Still functioning business as usual. If we don't relentlessly focus on this, the other side of the equation is the bad actors in combination will relentlessly continue. They took some hits, but they will not change unless it is made clear that we will not tolerate it. I hope that I'm wrong, I hope that this does not go all the way to bitcoin core itself. But the reality is, it probably does. I've been hearing lots of things, about the shitty parts of this whole ecosystem lately. Then, when something like this happens, I would have to be STUPID not to assume this is just scratching the surface. So again. Assume the worst. Assume that everything that can be compromised (people included) will be. Assume that people will be involved that may just be a patsy. Assume that as bitcoin grows in market-cap, the odds go up and up. Conspiracy yesterday, reality today. This is just simple logic, "it's just business, not personal" some would say. Follow the logic to it's conclusions and yes, it is looking VERY scary out there. Don't let anyone shame you about asking questions/speaking your mind or shining a flashlight around to see what you can see. Notice who pops up to try to silence you. Notice the patterns, apply simple monetary logic game scenarios. Stay frosty. View quoted note →

The commit that disabled RNG had a simple commit message: "runs" Wow. Good1. View quoted note →

On X This would get burried. Use it or loose it what are we even here for. 🕵❤ Tag or just add a comment. With EVERYONE you ever saw shill coldcard. I'll start @ODELL @gsovereignty ...

clock's ticking @ODELL View quoted note →

Marked safe from X. I was going to go on there and talk shit, but they wanted me to install the mobile app and I said no. If you post links to twitter, I'm just gonna judge you harshly now. I hope your influencoor points are gonna do some good in the world, but we all know they won't. Fuck the fuckers. Y'all scam artists now by association.

Linux RNG drivers power the entire cryptographic internet (SSL, PGP, verified as best as open source humankind can do, because moneys are at stake). Coldcard dice roll scripts, power nothing of value that hasn't already been stole. That's how you know.

Anyway, yeah I'm still in a bit of shock watching everyone get ripped off like this.

This RNG path is the first thing you would audit in a hardware wallet, that this wasn't found, by what I would assume would be multiple paid 3rd party auditors.. For this many years. This wreaks of an inside job. Mark kerpaples level status incoming.

I asked Fable5 to audit seedsigner's entropy paths. I don't use seedsigner *yet* but I probably will try it out at some point. This did produce one good recommendation in hardening the code to prevent future 'mistakes' in the UI entropy gate, but, other than that, no flaws found. Seems like a decent way to accompany dice rolling or etc. Fable5: I'll audit SeedSigner's entropy generation and key derivation paths. Let me start by mapping out where entropy enters the system — dice rolls, coin flips, camera-based entropy, and any use of RNGs — then closely review each path. The audit is complete. Here's my full report. Verdict I found no flaws that could lead to a low-entropy key in normal use. SeedSigner's design deliberately avoids trusting any onboard RNG — every seed-generation path is driven by external entropy (camera image, dice, coin flips), hashed through SHA-256, and fed to a well-reviewed BIP-39 implementation (embit 0.8.0, pinned in requirements.txt). The things I'd normally hunt for in this kind of audit — random module use in key paths, reused/aliased entropy buffers, early-exit paths that accept short input, silent truncation — all check out clean. What I verified, path by path Camera image entropy (tools_views.py:120-198): The final entropy is SHA256(chain) where the chain folds in the CPU serial number, time.time(), up to 50 live preview frames, and a final full-resolution photo (at ≥2× screen dimensions). Two things I specifically confirmed: - Each preview frame is an independent copy — camera.read_video_stream(as_image=True) does frame.astype('uint8') + Image.fromarray(...) (camera.py:52), so the 50 frames aren't 50 references to one reused buffer. - The weak inputs (serial number, wall time) are only ever added to the hash chain; hashing extra low-entropy data can't reduce the entropy contributed by the image itself. Dice rolls (mnemonic_generation.py:64-81): 50 rolls for 12 words (~129 bits, ≥128 ✓) or 99 rolls for 24 words (~256 bits ✓), hashed as an ASCII string via SHA-256 — the iancoleman.io "Base 10" approach. The entry keyboard only offers digits 1–6, backspace is handled correctly, and the screen returns only when exactly return_after_n_chars characters are entered (screen.py:1289). I checked the one early-return path in KeyboardScreen (the save button at screen.py:1237) — it's gated behind show_save_button, which the dice and coin-flip screens never enable, so you cannot submit fewer rolls than required. Coin flips: Same structure, exactly 128/256 flips enforced, charset limited to "0"/"1". Sound. Final-word calculation: Contributes only 7 bits (12-word) or 3 bits (24-word) plus checksum — but that's the correct math for this feature, and the UI states it explicitly. The "finalize with zeros" option is a deliberate, labeled choice. Key derivation (models/seed.py): Straight bip39.mnemonic_to_seed (PBKDF2-HMAC-SHA512, standard) with NFKD normalization. The Electrum variant uses the spec's 2048 rounds. No custom crypto. PRNG usage: The only uses of Python's non-cryptographic random are the screensaver animation, the backup-quiz decoy words (seed_views.py:1284-1289 — doesn't touch key material; the random.seed() call there is screenshot-generator-only), and the CLI tool's demo mode, which prints "This is a demo seed. Do not use it to store funds!!!". No os.urandom or PRNG anywhere in a key-generation path. Test coverage: tests/test_mnemonic_generation.py pins fixed vectors cross-checked against iancoleman.io and Coldcard's published dice-roll verification sample, so any regression in the entropy→mnemonic math would fail CI. Minor findings (none are exploitable in normal use) 1. No length validation in generate_mnemonic_from_dice / generate_mnemonic_from_coin_flips (mnemonic_generation.py:64, 85). Any input that isn't exactly 50 chars silently produces a 24-word mnemonic — e.g. 10 dice rolls would yield a 24-word seed with only ~26 bits of entropy. Today the UI makes this unreachable, but it's a single-layer defense; a future caller or a UI refactor could regress it silently. An assert len(...) in [50, 99] (with an escape hatch for the Coldcard 6-roll verification vector, which currently relies on this leniency) would be cheap defense-in-depth. 2. No degenerate-image check on camera entropy. If the sensor ever returned truly constant frames (fully dead sensor still returning data), the remaining entropy would be roughly just time.time() — guessable. In practice a disconnected camera raises CameraConnectionError, and even a lens-capped sensor produces thermal noise, so this is theoretical — but a cheap "image variance too low, reshoot" warning would close it. 3. Cosmetic off-by-one: bip39.WORDLIST[int(random.random() * 2047)] at seed_views.py:1284-1286 can never pick the last word ("zoo") as a quiz decoy. Should be random.randrange(2048). No security impact. Practical guidance The strongest guarantee this codebase offers is verifiability: for dice or coin-flip generation you can independently reproduce the mnemonic from your recorded rolls via tools/mnemonic.py or iancoleman.io/bip39 ("Base 10"/"Binary" mode), which removes the need to trust the device's code at all. If maximum assurance matters to you, dice generation with external verification is the path I'd use; camera entropy is also sound but is inherently harder to audit after the fact.

funny, image search for "newlay" shows.. it's some kind of concrete. 😂 I only picked that name, for internal reasons then just ended up calling it that. It was kinda like, "this is a new relay, newlay". I welcome name change suggestions, I don't even have an icon yet really..