How do I identify the valid checksums for bip39 if I generate 11/12 of the word?

[LoyceV]

I don't trust the RNG in any signing device (HW) and in general I think it's bad security practice for anyone to either.

As much as I appreciate a good level of paranoia when it comes to Bitcoin security, I don't think this is practically necessary. If you use dice to create a seed phrase, how do you sign a transaction with your hardware wallet? I'm thinking about for instance Reused R values: how do you use dice rolls to avoid this?

I use 100 dice throws ~ to generate a key.

I'd say you're a few bits short this way. I was thinking of 100 coin tosses. With 100 dice throws, you'll have enough entropy.

Since standard practice should always be to test recovery using seed words then the checksum isn't necessary.

The checksum is part of user friendliness: if a user makes a mistake in entering his seed words without a built-in checksum, he restores a different wallet. That will leave the average user puzzled (and panicked), and can easily be avoided by a simple: "wrong seed, try again" message.

[BlackHatCoiner]

I'm thinking about for instance Reused R values: how do you use dice rolls to avoid this?

You don't need an RNG to generate an R value for your signature. If your private key is securely generated, you can use it to hash it, along with your message, to generate an R value. This is RFC 6979, and it is supported by every bitcoin wallet, IIRC.

So, as long as you use a dice to generate the 128 bits for your seed phrase, you no longer need an RNG. You can just take advantage of that entropy and extend it everywhere else. This could be applied beyond bitcoin. You could just roll a dice enough times, and store the results during OS setup, and then your Linux would need not to ever call an RNG. It's just not user friendly the reason why it isn't implemented.

I'd say you're a few bits short this way.

100 dice rolls are more than enough.

[LoyceV]

You don't need an RNG to generate an R value for your signature. If your private key is securely generated, you can use it to hash it, along with your message, to generate an R value. This is RFC 6979, and it is supported by every bitcoin wallet, IIRC.

Your link goes above my technical understanding (and I don't have time to read it all), but it looks like R is still based on a random component (page 9). It has to be, to avoid generating the same R twice if it's generated from the same seed.
But again: this goes over my head It's also the reason I don't mess with encryption on this level, and just trust my wallet to take care of it.

[BlackHatCoiner]

Your link goes above my technical understanding (and I don't have time to read it all)

This is all you need to know: https://chatgpt.com/share/69d7a896-31dc-8327-b6de-531b35bb8fa2

It has to be, to avoid generating the same R twice if it's generated from the same seed.

The seed is used to derive master public keys, which are then used to derive Bitcoin private keys. k value (which R is computed from) is derived deterministically from the Bitcoin private key and the hash of the message (i.e., the transaction). Therefore, no random number generation is needed. For each pair of private key and message hash, there is a unique R value, derived deterministically.

[nc50lc]

Without the checksum, I wouldn't need to do that second step. As stated above, as long as my dice aren't loaded and I complete enough rolls, I can map throws directly to the word list without a hash or a checksum. Since standard practice should always be to test recovery using seed words then the checksum isn't necessary.

Interesting take.
If only the entropy's size is exactly divisible by the number of bits per word, a client may be able to accept partial words for recovery without a checksum.
Unfortunately, the standard is 11-bits per word so it's not possible to map without a checksum that'll fill those remaining bits. (yes, it's not just for error-checking)

I think it's more viable to develop or "feature request" a new advanced feature for advanced users that accepts raw entropy that'll be used as the "binary seed" when restoring a wallet.
That way, it wont have to follow any mnemonic standards and wont have to calculate a checksum, but it'll require more dice rolls.
Users who rely on dice rolls can just feed it with their true-RNG entropy.

[LoyceV]

I think it's more viable to develop or "feature request" a new advanced feature for advanced users that accepts raw entropy that'll be used as the "binary seed" when restoring a wallet.

I'm fully confident some people will use this as a brain wallet with weak entropy

[Cricktor]

...

Such a "feature request" is in my opinion bad to dangerous for obvious reasons, not only what LoyceV mentions. The smallest typo in what an "advanced" user might use as "something raw" for the binary seed will yield an empty wallet.

It would be too easy to screw up and there would be nothing to indicate you've done something wrong. Seriously, who wants that? For sure, I don't!

I don't judge if someone doesn't trust a hardware RNG and rather feels more comfortable to generate their own random entropy. I just hope for them, they do it right and don't mess up, because it's quite easy to mess up and commonly a little bit more challenging to do it right (if you aim that your own generated entropy is of similar quality compared to RNG circuits of reputable vendors of hardware wallets).

Am I sure that hardware RNGs are fine? Heck no, I can't easily prove that but my paranoia has limits for sake of sanity.

The majority of wallet operate with BIP-39 and this pads one bit of SHA-256 partial checksum for every 32 bits of entropy. Like it or not, it's the defined standard. It's probably not the best solution, but it's what stuck and what is widespread implemented and used.

[nc50lc]

...

Such a "feature request" is in my opinion bad to dangerous for obvious reasons, not only what LoyceV mentions. The smallest typo in what an "advanced" user might use as "something raw" for the binary seed will yield an empty wallet.

If that happens, there's obviously a typo and the user has to do it again.
If it's just during restore, there's not much issue in having a wallet accept raw entropy.
The issue here is during backup, but Bobby already mentioned that it's SOP to test the backup before depositing anything to it.
Since it's an "Advanced Feature", that should be hidden by default, either only accessible though command or inside a toggleable option with warnings.

And it's not something non-standard.
It simply skip the BIP39-related parts, everything follows BIP32 standard.

Besides, the full context is: I simply implying that what he wants isn't possible without changing BIP39's spec.
So, I showed him what is the possible alternative way of achieving that.