Bitcoin Forum

Hi

I am testing a 6 dice to generate a 12 word seed. I was testing both sites, the iancoleman and bitcoin.guider and i found out that both give diferent seed phrases for the same input when i choose dice 6. I want to know whats wrong here.
I also noticed that  iancoleman  says that it generates just 1.67 bits per event, meanwhile on bitcoin.guiders its 2.58 bits per event.

 Can someone help me ?

There is not a standardized translation of the dice's output.

Entropy is X bits (0 or 1).

What you want to do is translate the 6 possible outcomes into 0s or 1s.

So, when rolling dice, you can have 6 possible outputs, correct? 1, 2, 3, 4, 5, 6.

One could say that if the number is small (1, 2 or 3), it should be assigned to a 0 and when the number is big (4, 5, 6), it should be assigned to a 1. Notice that this would give 1 bit per roll.

Another could say that if the number is odd, then it would be assigned to a 0 and if it's even it should be assigned to a 1. Notice that this would give 1 bit per roll.

A third one could just say that 1 = 0, 2 = 1, 3 = 00, 4 = 01, 5 = 10, 6 = 11. Notice that this would give on average 1.66 bits per roll. There are 6 outputs of which 4 give 2 bits and 2 give 1 bit. So it's 10/6 bits.

I am certain that bitcoiner.guide use a system that produces 2.58 bits per roll that I am not able to understand right out of my head. On the other hand Ian Coleman's website must be using the 3rd system of the ones that I mentioned above, since it gives on average 1.67 bits. But, of course, the translations that I used in this example are random. So, Ian Coleman's website could translate 1 as 01, 2 as 11 etc, but the average entropy remains the same.

Thus, if you wanted 256 bits of entropy, you would need to roll the dice and do the translations with any system you wanted.

So, I am assuming it could be as simple as that.

i tested on both and both give me same results

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

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

I don't understand. Your posts are somewhat contradictory.

when i said that gave me same results i am talking about the option 3 that you gave me. its the same on both. both have 4 numbers that generate 2 bits and 2 numbers that generate 1 bit.

you can see for yourself if you dont mind :

https://iancoleman.io/bip39/
https://bitcoiner.guide/seed/

But wait... If the translations are the ones that you provided, then it's obvious why the same dice-rolls produce different seed phrases. Isn't it?

Let's go by example.

Let's say you want to roll the dice 5 times and collect the entropy

Let's say we rolled: 5, 6, 2, 2, 3

Ian coleman would give 1 00 10 10 11
Bitcoiner.guide would give 0 1 01 01 10

So the translations are totally different.

yes thats correct now i understand.
but for exemple, ian coleman says thats 1.67 bit per event meanwhile the other site says its 2.58. so can i assume its an error?

Yes, the average entropy is 1.67 and that's because you have:
1 bit x 2 outcomes + 2 bits x 4 outcomes = 10 bits / 6 outcomes = 1.67 bits on average.

The 2.58 is curious.
The only thing I can think of is that log2(6) = 2.58.
When thinking in bits, the maximum entropy you can get is log2(n) where n is the number of possible outcomes.
Log2 (base 2) is because you basically transform the inputs into 2 outputs (0 or 1).
But, 2.58 can't happen because actually the maximum entropy you get by the dice rolls is 2 (for 4 out of the 6 outcomes).
Sorry but I am not strong in math, but I think we 've covered your questions.

This is my understanding, and please take it with a grain of salt. I have only taken just one class in probabilities, certainly not my field of expertise.

---

The entropy generated by rolling a dice is, indeed, 2.58. Specifically, the Shannon entropy (https://en.wikipedia.org/wiki/Entropy_(information_theory)), which is defined by the following formula:

https://wikimedia.org/api/rest_v1/media/math/render/svg/ff26f81edc1f4bb204793a52b2430c77f6633203

where X the random variable defined by the experiment of rolling a dice, x each possible value from that experiment (1, 2, 3, 4, 5, 6), and p(x) the probability of coming x (1/6 for all). It can be simplified to -1 * (1/6) * 6 * log2(1/6) = -1 * (-2.58) = 2.58.

However, when encoding your dice result into bits, you lose entropy, because you define that certain outcomes, while equally uncertain, produce less bits. For results 1, 2, 3, 4, you get 2 bits, whereas for 5, 6 only 1 bit. Therefore, 2/3 of the time, it's 2 bits, and 1/3 of the time, 1 bit, average is 2/3 * 2 + 1/3 * 1 = 1.66.

You could have retained the entropy if, instead of converting them to binary, you concatenated all the results into one string (e.g., "131246...") and passed that into SHA256. This is what SeedSigner does: https://github.com/SeedSigner/seedsigner/blob/739ea824f27fa41a7e6cd7d10ba2badc144c256e/src/seedsigner/helpers/mnemonic_generation.py#L43-L51.

My last question on this topic.

When using iancoleman if i give it this dice 6 result : 1236212615165132315133131313123121561312313215615315313212132123132123123135653 21123132151311231231

And then choose 12 words i get this seed :

over spot rate two junior rice maze people animal swap model wet

Meanwhile i also see the raw binary is : 01101100100 11000011010 01011110110 11011111011 10111011101 10110110011 00011101101 10111100110 00111101111 01111001100 11110011011 01111001101 10110110111 10011110010 11011011110 01101110101 10110110110 1


And if i try to find by myself just the first seed word from the raw binary (01101100100 )from the word list i found that the word is "hold" and not "over".

What am i doing wrong ? Maybe the list word that i am seeing is wrong ? maybe the raw binary is not the seed?

(this is not my wallet)

The raw binary is not the seed, and you can verify that by simply changing the mnemonic length; raw binary remains the same, but BIP39 seed changes.

Raw binary is represented by the mnemonic in a human readable format. The seed is derived from the mnemonic, not the opposite. This is probably what confuses you. When you have the mnemonic sentence, you pass it through 2048 PBKDF2 rounds, and you get the seed. This explains why increasing the words (12 -> 15) does not change the sentence (only adds new words), while the seed is completely different.

Why pass it through 2048 PBKDF2 rounds to get the seed if from raw binary we can get a seed?

From Mastering Bitcoin (chapter 5) (https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05_wallets.adoc#fig_5_7) by Andreas Antonopoulos:


The recovery code represents entropy with a length of 128 to 256 bits. The entropy is then used to derive a longer (512-bit) seed through the use of the key-stretching function PBKDF2. The seed produced is then used to build a deterministic wallet and derive its keys.

The key-stretching function takes two parameters: the entropy and a salt. The purpose of a salt in a key-stretching function is to make it difficult to build a lookup table enabling a brute-force attack. In the BIP39 standard, the salt has another purpose—​it allows the introduction of a passphrase that serves as an additional security factor protecting the seed, as we will describe in more detail in Optional passphrase in BIP39.
Tip
   
The key-stretching function, with its 2,048 rounds of hashing, makes it slightly harder to brute-force attack the recovery code using software. Special-purpose hardware is not significantly affected. For an attacker who needs to guess a user’s entire recovery code, the length of the code (128 bits at a minimum) provides more than sufficient security. But for cases where an attacker might learn a small part of the user’s code, key-stretching adds some security by slowing down how fast an attacker can check different recovery code combinations. BIP39’s parameters were considered weak by modern standards even when it was first published almost a decade ago, although that’s likely a consequence of being designed for compatibility with hardware signing devices with low-powered CPUs. Some alternatives to BIP39 use stronger key-stretching parameters, such as Aezeed’s 32,768 rounds of hashing using the more complex Scrypt algorithm, although they may not be as convenient to run on hardware signing devices.

https://www.talkimg.com/images/2024/10/06/i1SWd.png

Examples:

128-bit entropy BIP39 recovery code, no passphrase, resulting seed
Entropy input (128 bits): 0c1e24e5917779d297e14d45f14e1a1a
Recovery Code (12 words): army van defense carry jealous true garbage claim echo media make crunch
Seed (512 bits): 5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4 c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570

256-bit entropy BIP39 recovery code, no passphrase, resulting seed
Entropy input (256 bits): 2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c
Recovery Code (24 words): cake apple borrow silk endorse fitness top denial coil riot stay wolf luggage oxygen faint major edit measure invite love trap field dilemma oblige
Seed (512 bits): 3269bce2674acbd188d4f120072b13b088a0ecf87c6e4cae41657a0bb78f5315b33b3 a04356e53d062e55f1e0deaa082df8d487381379df848a6ad7e98798404

That's because BIP39 wants multiple of 32bits only and your entropy string gives 188bits to the script. 188 Mod 32 = 28
As it's written, the Ian Coleman script generates "3 words per 32 bits".

https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

https://www.talkimg.com/images/2024/10/06/ih2i8.png

If you complete your entropy string with (32 - 28 = 4) bits of padding to reach the next 32 bits multiplier between 128 and 256, ie 192 bits, you will get the right Word Indexes and the right words. That is to say 868 and "hold" for the first 11bits word of your given entropy "01101100100".

https://www.talkimg.com/images/2024/10/06/ih65C.png



The PBKDF2 stretching function is used after this step actually, in order to get what is called the "BIP39 Seed" on the Ian Coleman page, from the mnemonic sentence in alphanumeric characters and the passphrase.