My willingness to respond to AI-written exchanges: quota exceeded.

Please try again when human.

Side point: I tire of responding by hand while you post AI-written responses. I view that as rude.

""take a picture, see a picture" does not carry the dark case. "

If the scene is too dim, the resulting image on screen will be similarly indiscernible. That is exactly what the eyeball check is for. If it's too dim to have any useful data, your eye won't see anything (or much of anything) on screen.

I think a human would understand this. Your AI does not.

I'm done talking to your AI.

If you care to respond to me as a human, I'll continue this discussion if there are any further points.

Please dig in deeper to the available resources or ask questions first before declaring something as alarming as "you might have weak entropy" next time.

I mean, I wrote a very clear assurance in the PR description itself!



Everyone in this space understandably has ptsd at this point.

If you have questions, concerns, doubts, etc, absolutely put them out there. But don't declare something as fact unless you're actually sure that's the case. That's irresponsible.

A better way to raise your concerns would be something like, "Hey, I just saw a SeedSigner PR to improve image entropy. Does that mean a seed created before this change is vulnerable?"

I literally already wrote that the new check requires that "each captured frame hashes to a different value".

There is no attempt to score the entropy per frame. Heuristics like Shannon do a poor job of scoring image data for this use case. The pic of the white wall would score very poorly by Shannon but, as my tests show, they yield orders of magnitude more randomness from shot-to-shot than would be necessary to generate a strong seed (it's hundreds of thousands to millions of bits of entropy vs 128 or 256).

AI scans of the image entropy approach always fail to factor in the most important safety check in the entire system: your eyeballs.

What is shown on screen is the same data that is hashed into your seed (both for the preview frames and the final image that the user has to explicitly accept / reject).

If your eyes see on screen what you're pointing your camera at, you're fine, even if you're pointing at what we'd think would be a low entropy scene (e.g. the white wall, even a very dark room but you can still make out a dim image on screen, etc).

It's easy to get sucked into the nerd / AI analysis. But the feature is, I think, beautifully 80 IQ in its own way: Take a picture, see a picture = all good.

I think you need to spend your AI credits scanning my writeup and those PRs and have it answer your questions instead of crafting further responses.

My writeup included tests shooting a blank white wall. Those images scored on par with a more typical shot of a bookshelf.

And the new 50 required preview frames check for pure white, pure black, and require that each captured frame hashes to a different value (i.e. is unique). This is demonstrated in the video in the post I linked.

I should have added: those above improvements will be part of an upcoming v0.8.8 security hardening release.

And just to be super-clear: I view the image entropy process in v0.8.7 and prior to be safe as-is. It's the only method I use to create new seeds.

The improvements just move the process from "safe" to "nearly fool-proof".

Before: No, you're not going to accidentally create a weak seed.
After: No, you can't intentionally create a bad seed.

This was thoroughly analyzed and documented here:
https://kdmukai-bot.github.io/seedsigner-ai-analysis/image-entropy/

You'd have to try pretty hard to intentionally get a potentially bad result:
* HOLD the click to enter the image entropy process.
* KEEP HOLDING to skip the preview frames.
* KEEP HOLDING to skip the final image review.

But even then, you'd ALSO have to block the camera so that it doesn't see anything at all (or shine a bright light directly into the lens).

THEN... there is a chance you'll get a low entropy seed (but still not guaranteed).

I demonstrated this 3 months ago: https://x.com/KeithMukai/status/2086222672896135629

But for a normal user who visually reviews their final image, there is no risk.

---

Since then we've merged my fix to prevent the UX bug caused by holding down the initial button click: https://github.com/SeedSigner/seedsigner/pull/990

PR fix demonstrated here: https://x.com/KeithMukai/status/2086222676088037434

And an additional safety measure to REQUIRE the 50 preview frames to be fully captured AND not be full black nor full white: https://github.com/SeedSigner/seedsigner/pull/991

PR fix demonstrated here: https://x.com/KeithMukai/status/2086648029386334235

Luckily I've never been a baseball fan! But I would have been a Cubs fan.

As far as I can remember, verifying your multisig change/receive addrs has always been possible.



But it requires scanning your "known good" descriptor. We do not have a way to store the decriptor for you. I think eventually we'll support reading from a data-only SD card (i.e. a diff card from the one you boot with).

But having a copy of your descriptor alongside each key in a multisig is a best practice, obv. And scanning it from a pdf printout (the kind Sparrow will auto-generate for you) is easier and faster than swapping SD cards (which will then probably require an additional UI selection step if there are multiple descriptors on the card).

I'd also rather store the paper printout than a tiny SD card. And you'd want a paper backup even if you had it on an SD card since you can't trust digital storage media for long-term storage.

Slight inaccuracy (but not in a way that impacts security, so relax!):

The code has support already in place for coin flip entropy but there is no UI flow for it yet.

Users are limited to:
* Picking bip39 words out of a bowl and using the Calc Final Word feature.
* Dice rolls (50 or 99, strictly enforced)
* Image entropy

There IS a PR for coin flips, but it went stale at the end of last year. I very much want to revive it now, but there are some UI tweaks it's going to need.

It's basically fully functioning on the esp32-P4. But on hold for a bit while we focus on an update to close some vulnerabilities (nothing house-on-fire level but worth addressing).

I've been estimating that full code review on the esp32 work will take 6-12mo. We've always been very cautious and have moved slowly on purpose. But even moreso now.

That being said, everything is FOSS so some people have begun buying the hardware and running the experimental code.

https://github.com/kdmukai/seedsigner-micropython-builder