Is there any benefit of using more than 100 dice rolls to generate a seed?

[Ambivilance]

Is additional entropy beyond 256 bits discarded or is there any added benefit? I know it would be minimal, but want to know the technicalities.

Also:  the 24th word is a checksum. What would happen if I used a 24th word that was not a valid checksum? Would it not be possible or would addresses not have a valid private key etc...?

[1715112808]

1715112808

[1715112808]

1715112808

[1715112808]

1715112808

[1715112808]

1715112808

[1715112808]

1715112808

[1715112808]

1715112808

[ranochigo]

Is additional entropy beyond 256 bits discarded or is there any added benefit? I know it would be minimal, but want to know the technicalities.

Not discarded. By BIP39, the seed must have an entropy in multiples of 32 so there is no limit to how many you have to use. After all, the mnemonic is passed through a KDF for the actual seed to be used so the length actually isn't limited. Your addresses only has 128 bits of security so people would probably look to compromise the individual addresses instead of seeds, they're much faster to generate.

Also:  the 24th word is a checksum. What would happen if I used a 24th word that was not a valid checksum? Would it not be possible or would addresses not have a valid private key etc...?

Nothing happens. You won't generate any invalid addresses.

As said, it passes through the KDF so the checksum only serves to provide a check for typo.

[BlackHatCoiner]

Is additional entropy beyond 256 bits discarded or is there any added benefit?

A benefit for your security? No, even 256 bits is too much. I believe that most of the people use 128 bits (12 words) for the seed generation. You should feel secure with both of them since the act for someone to guess (or even brute force) your mnemonic would be meaningless.

Also:  the 24th word is a checksum. What would happen if I used a 24th word that was not a valid checksum? Would it not be possible or would addresses not have a valid private key etc...?

No, checksum isn't needed to consider a seed valid. Any seed phrase can be used to derive you addresses. Although, it's not recommended to do that with a seed phrase that doesn't have a checksum. Why:

If you lose 1 of those 24 words that have no checksum by any possible way, then you'll have to brute force 2048 different combinations. By “brute forcing” I mean running through the process of PBKDF2, HMAC-SHA512, etc for each phrase separately.

But, if you lose 1 of those 24 words of a checksum valid seed, then you won't have to go through the entire procedure. The functions I mentioned you would slow down the search, but if your computer simply checked the checksum validation, then it'd skip the invalid ones. On average, the checksum is valid for 8 out of 2048 words for the last word. Can you imagine now how faster you'll end this process?

[NotATether]

Doing a hundred dice rolls is also going to be very tedious and cause a lot of fatigue from the sheer amount of time it takes, which discourages people from rolling dice more often. Plus, there is an involved procedure to turn those 256-bit entropy into a private key. It's not simply just dice rolls to hex number conversion, you also must manually construct the private key WIF.

[BrewMaster]

Plus, there is an involved procedure to turn those 256-bit entropy into a private key. It's not simply just dice rolls to hex number conversion, you also must manually construct the private key WIF.

the point of using dice (or any other similar method) is to produce an entropy that doesn't rely on the computer or the code that was written by some developers. so we just replace the RNG with dice and the rest is straight forward so it can be done with the computer code.

[ranochigo]

Doing a hundred dice rolls is also going to be very tedious and cause a lot of fatigue from the sheer amount of time it takes, which discourages people from rolling dice more often. Plus, there is an involved procedure to turn those 256-bit entropy into a private key. It's not simply just dice rolls to hex number conversion, you also must manually construct the private key WIF.

Since OP says that he wants to generate a seed, you only actually need to obtain an entropy that is sufficiently random (256bits) once, keep it secure and after which just use it to generate your addresses. This is also known as BIP32 and loads of people actually use dice rolling as a source of entropy. BIP39 is just another way to encode it into a string of mnemonics (quite simple actually) and use it for BIP32 derivation afterwards.

It's important to note that due to the many variables associated with this; the way you throw the dice, the kind of dice, etc. The resultant entropy can very well be under 256bits due to some degree of predictability associated with it. If you're paranoid that the RNG isn't working correctly (perfectly valid, happened before), then this can be a way to guarantee "sufficient" entropy.

[Ambivilance]

Doing a hundred dice rolls is also going to be very tedious and cause a lot of fatigue from the sheer amount of time it takes, which discourages people from rolling dice more often. Plus, there is an involved procedure to turn those 256-bit entropy into a private key. It's not simply just dice rolls to hex number conversion, you also must manually construct the private key WIF.

Since OP says that he wants to generate a seed, you only actually need to obtain an entropy that is sufficiently random (256bits) once, keep it secure and after which just use it to generate your addresses. This is also known as BIP32 and loads of people actually use dice rolling as a source of entropy. BIP39 is just another way to encode it into a string of mnemonics (quite simple actually) and use it for BIP32 derivation afterwards.

It's important to note that due to the many variables associated with this; the way you throw the dice, the kind of dice, etc. The resultant entropy can very well be under 256bits due to some degree of predictability associated with it. If you're paranoid that the RNG isn't working correctly (perfectly valid, happened before), then this can be a way to guarantee "sufficient" entropy.

I think if you roll the dice properly and don't just drop them and are consistent in the way that you read them, then there is no loss of entropy.
Even with cheap dice, they seem fair enough   https://youtu.be/mPiUoVeMsEk

[Ambivilance]

Is additional entropy beyond 256 bits discarded or is there any added benefit? I know it would be minimal, but want to know the technicalities.

Not discarded. By BIP39, the seed must have an entropy in multiples of 32 so there is no limit to how many you have to use. After all, the mnemonic is passed through a KDF for the actual seed to be used so the length actually isn't limited. Your addresses only has 128 bits of security so people would probably look to compromise the individual addresses instead of seeds, they're much faster to generate.

Also:  the 24th word is a checksum. What would happen if I used a 24th word that was not a valid checksum? Would it not be possible or would addresses not have a valid private key etc...?

Nothing happens. You won't generate any invalid addresses.

As said, it passes through the KDF so the checksum only serves to provide a check for typo.

you said that the entropy must be multiples of 32 so does that mean for more security you will need 32/log2(6) rolls to make a difference to security. i.e 12 rolls?

[ranochigo]

I think if you roll the dice properly and don't just drop them and are consistent in the way that you read them, then there is no loss of entropy.
Even with cheap dice, they seem fair enough   https://youtu.be/mPiUoVeMsEk

It needs to be perfectly random for the theoretical entropy to be reached. Many cheap dices are biased due to the imbalance in CG or having faces that are not perfectly flat. It is just nitpicking in most cases given it provides 256bits of entropy so there is some redundancy.

you said that the entropy must be multiples of 32 so does that mean for more security you will need 32/log2(6) rolls to make a difference to security. i.e 12 rolls?

It is stated in the BIP actually. The requirement is actually for if you are using the raw entropy to generate a seed, then yeah. If you're using some kind of stretching, ie SHA256, then you don't need it to be in the multiples as the result will always be 256 bits, or 24 words.

[Ambivilance]

I think if you roll the dice properly and don't just drop them and are consistent in the way that you read them, then there is no loss of entropy.
Even with cheap dice, they seem fair enough   https://youtu.be/mPiUoVeMsEk

It needs to be perfectly random for the theoretical entropy to be reached. Many cheap dices are biased due to the imbalance in CG or having faces that are not perfectly flat. It is just nitpicking in most cases given it provides 256bits of entropy so there is some redundancy.

you said that the entropy must be multiples of 32 so does that mean for more security you will need 32/log2(6) rolls to make a difference to security. i.e 12 rolls?

It is stated in the BIP actually. The requirement is actually for if you are using the raw entropy to generate a seed, then yeah. If you're using some kind of stretching, ie SHA256, then you don't need it to be in the multiples as the result will always be 256 bits, or 24 words.

thanks.  How many rolls is recommended? 100 is needed for 256 bits but does it make sense to use more in case of poor dice etc...? is too many rolls ever bad? I don't think so. does it make sense to do 200 rolls?

[ranochigo]

thanks.  How many rolls is recommended? 100 is needed for 256 bits but does it make sense to use more in case of poor dice etc...? is too many rolls ever bad? I don't think so. does it make sense to do 200 rolls?

If represented in 1-6, at least 50 for 12 words.

It's not terrible to get more results but Bitcoin keys are only 128bits in security so 256 bits is already quite a lot and there is some leeway for biasness as well. If you're using SHA256 as a hash function for the entropy, keep in mind that the resultant entropy won't be more than 256 bits, even if you roll it 200 times with a perfectly fair dice.

[HCP]

Also:  the 24th word is a checksum. What would happen if I used a 24th word that was not a valid checksum? Would it not be possible or would addresses not have a valid private key etc...?

Theoretically, you can quite happily use whatever combination of whatever words you like... regardless of the checksum... you'll still be able to convert those words to a "valid" 256 bit seed (following the BIP39 algorithm), which can then be used to generate "valid" addresses.

The issue with not having a valid checksum, is that no "strictly" BIP39 compatible wallet will (or should) accept your 24 words... as it will be "invalid". Having said that, I know of at least one wallet^[1] that will indeed allow you to input and use a set of 24 words that fail the BIP39 checksum test.

Additionally, without a valid checksum, you have no way of knowing/testing that you have actually recorded the correct words in the correct order. This could lead to numerous issues in the future should you need to attempt wallet recovery.

TLDR; not having a valid checksum is a "bad idea"™



[1] Electrum

[Ambivilance]

thanks.  How many rolls is recommended? 100 is needed for 256 bits but does it make sense to use more in case of poor dice etc...? is too many rolls ever bad? I don't think so. does it make sense to do 200 rolls?

If represented in 1-6, at least 50 for 12 words.

It's not terrible to get more results but Bitcoin keys are only 128bits in security so 256 bits is already quite a lot and there is some leeway for biasness as well. If you're using SHA256 as a hash function for the entropy, keep in mind that the resultant entropy won't be more than 256 bits, even if you roll it 200 times with a perfectly fair dice.

ah so if this is used with a coldcard, there is no point in doing more than 100 rolls since it uses sha256?

[ranochigo]

ah so if this is used with a coldcard, there is no point in doing more than 100 rolls since it uses sha256?

The 100 rolls provides 258 bits of entropy. Anything above 128 bits is secure enough, Bitcoin addresses uses 128bits as well.

It is not that there isn't any point adding more dice rolls. 24 words seed should have 256 bits of entropy but 128 bits is enough as well, a SHA256 hash will stretch it. I'd say anything between 128bits and 256 bits is enough. Hashing using SHA256 will not result in any security over 256 bits for your seeds.

[BlackHatCoiner]

thanks.  How many rolls is recommended? 100 is needed for 256 bits but does it make sense to use more in case of poor dice etc...? is too many rolls ever bad? I don't think so. does it make sense to do 200 rolls?

How do you count each dice result? Iancoleman counts as it follows:

Code:

1 = 01
2 = 10
3 = 11
4 = 0
5 = 1
6 = 00

Every roll would give you 2 out of 6 times, 1 bit and 4 out of 6, 2 bits. That being said, if you want 256 bits then you'll have to roll it from 128 to 256 times. The average roll will give you 1.66 bits (2 - 1/3) and thus, you'll have created your entropy in around 256/1.666 ~= 154 rolls.

If you want 128 bits, which isn't a bad choice, then you'll have to roll it ~77 times.

Take a look on this: [Open Source] Coin Flipped Seed

[btc-room101]

Is additional entropy beyond 256 bits discarded or is there any added benefit? I know it would be minimal, but want to know the technicalities.

Also:  the 24th word is a checksum. What would happen if I used a 24th word that was not a valid checksum? Would it not be possible or would addresses not have a valid private key etc...?

U only need to roll the dice 32 times with pairs, that will give your 64 integers, you input that into 'ku' and you will get back a real nice WIF private-key

All computer generated random numbers are deterministic, so this is really the only way to create a real random number. Of course if you want to get technical you should roll HEX dice (16) sided, or decimal (10 sided 0-9), but I find that 32 rolls of a pair does just fine (0-5, 1-6).

All other things remain skeptical, you use sw to generate a random key you don't know, most trezors have been hacked, most software is deterministic with an original seed, they already know for all time the future random numbers you will be using.

So for the ultimate security hell yes roll those dice.

thanks.  How many rolls is recommended? 100 is needed for 256 bits but does it make sense to use more in case of poor dice etc...? is too many rolls ever bad? I don't think so. does it make sense to do 200 rolls?

How do you count each dice result? Iancoleman counts as it follows:

Code:

1 = 01
2 = 10
3 = 11
4 = 0
5 = 1
6 = 00

Every roll would give you 2 out of 6 times, 1 bit and 4 out of 6, 2 bits. That being said, if you want 256 bits then you'll have to roll it from 128 to 256 times. The average roll will give you 1.66 bits (2 - 1/3) and thus, you'll have created your entropy in around 256/1.666 ~= 154 rolls.

If you want 128 bits, which isn't a bad choice, then you'll have to roll it ~77 times.

Take a look on this: [Open Source] Coin Flipped Seed

You roll pairs, then 2,3, 5,1; becomes 2351, then you run 'ku' part of python pycoin toolset ku automatically assumes that the huge digit ( 10e77 ) is a private-key in integer format, it returns to you all permutations of that key in bitcoin format. You copy&paste the WIF, and call it good. I personally think this is way better than 12/24 stupid words.

If you did 40 rolls of pairs, you would be certain to max (10e77 with 80 digits ), but IMHO 32 rolls is just fine. The counting as integer is way easier than binary, or hex; Keep it Simple.

[moderator's note: consecutive posts merged]

[BlackHatCoiner]

You copy&paste the WIF, and call it good. I personally think this is way better than 12/24 stupid words.

How can you believe that rolling dice for one address is better than a seed phrase that can derive you as many as you want?

The counting as integer is way easier than binary, or hex; Keep it Simple.

The user doesn't have to write it neither in binary or hex. The computer can do that for him after he submits his results decimally of course.

As for your way, it doesn't seem to that it'll return a completely random entropy given that a 6-sides dice can only give 6 values. It may worked properly if the dice had more sides (as you mentioned above). If you want to correct me please do, I may have misunderstood.

[ranochigo]

How do you count each dice result?

If you count the dice values as it is (base 6), it'll have 2.58 entropy per roll. Using SHA256 ensures that the result will be always 256 bits, regardless of how many dice rolls is used. I assume OP is talking about ColdCard's way of generating it, which is what I've mentioned.

I think using the method I've mentioned requires far less effort.

[Ambivilance]

Is additional entropy beyond 256 bits discarded or is there any added benefit? I know it would be minimal, but want to know the technicalities.

All other things remain skeptical, you use sw to generate a random key you don't know, most trezors have been hacked, most software is deterministic with an original seed, they already know for all time the future random numbers you will be using.

So for the ultimate security hell yes roll those dice.

lol that is a load of rubbish

[Ambivilance]

How do you count each dice result?

If you count the dice values as it is (base 6), it'll have 2.58 entropy per roll. Using SHA256 ensures that the result will be always 256 bits, regardless of how many dice rolls is used. I assume OP is talking about ColdCard's way of generating it, which is what I've mentioned.

I think using the method I've mentioned requires far less effort.

yes, that is what I meant