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