Topic: Are dices for generating seed words fair? - page 10. (Read 3465 times)

But it wasn't. It doesn't matter if a number looks random or not if you're sure that it wasn't generated in a predictable way. In this case, the number might seem random, but all of us can verify that it was the hash of a non-random number. Anyway, I'm still not sure how's this incident related to dice rolls. The bitcoin may have been deposited and withdrawn by the same person who was testing the ecosystem back then. It's highly likely that there are bots that scan for this known keys to immediately spend in case someone sends money, though.

Would you like to share a link?

0.9 bitcoin got lifted off the uncompressed address 20 minutes after they deposited it. i'm assuming whoever sent the money had no idea what they were doing. i guess "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855" looked random enough to them so they went with it...that will never happen with dice rolls no matter how bad the dice are biased.


flaws in random number generator algorithms i think i heard about how someone exploited that to hack some private keys once. the algo was using the time as a seed or something.

Either flipping a coin or using Bitcoin Core on a clean, airgapped Linux machine.

True, but even if they do, such a bias will be eliminated by using von Neumann's algorithm as above.

Theoretically, given a function that produces cryptographically secure pseudo-random numbers, computers would need no RNGs. Generation of the entropy could be done once outside the machine, and be submitted during the installation of the operating system. Every time a program requested a random number, the computer could feed the function with the entropy with a nonce.

Well, I don't know how does this enriches the discussion, but SHA256 of an empty value is "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855". The (compressed) WIF of this is "L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1", with a P2PKH address "1F3sAm6ZtwLAUnj7d38pGFxtP3RVEvtsbV" that has totally received 1.19592036 BTC.

It is a little paranoid, because I've never heard of anyone losing bitcoin because of flawed CSPRNGs, and probably most valuable private keys have been generated using CSPRNGs. On the other hand, very few roll dices to generate their entropy, and is therefore less clear what's more prone to human error.

i mean you outlined one safer method which is flipping the coin twice and eliminating rolls where you had a duplicate. i guess that's "safer simpler and quicker" than rolling a dice with unknown bias. not sure what other methods you had in mind though. i'm not yet convinced that other factors don't play a greater role in flipping a coin though like the way the coin is flipped. without any control over that process, someone could maybe affect the outcome slightly (introduce a bias).


yeah that's what i thought but when i think about it again, i realize if it lands on one number too often then the number on the opposite side is less often so there's 2 clues it might be generated using a biased dice. but i don't know if that is exploitable.

i guess. wasn't aware of exactly what steps were involved in that but that would be better so you don't have to spend hours every so often rolling dice.

I don't think that's paranoid at all. It's probably smart. Ever heard of someone that sent 1 bitcoin to the sha hash of "" ? i bet their computer did that to them.

so then the way you figured out your dice was fair is you put it in saltwater if not then not sure how you could know it is fair. and even then, i'm not sure that's a 100% guarantee. does a dice need to be retested for bias every so often?

I'm still having a hard time comprehending your point. That if I give you a number you can't know if it has a certain bias?

First of all, it's not for a single private key; it can work as a seed, which can be later used to derive nearly infinite private keys. Secondly, you should absolutely force nobody do nothing; especially regarding this matter. It's a process that concerns you, individually. Same as with using bitcoin.

While paranoid, I still prefer tossing a coin, or rolling a fair dice, than using an RNG from a computer I don't trust. In my case that I have two computers, one that I'm currently typing, and another I don't trust with all that software I've installed over time. (I say paranoid, because I've never heard anything of "RNG exploitation")

Exactly. Which is part of the reason I am arguing against using dice. If you instead want to test whether a single die has no bias and be reasonably confident in your conclusions, then it would require even more rolls than the ~16,000 coin flips I gave above to test for a coin. Why take the risk, when there are safer, simpler, and quicker methods available?

That wouldn't work. You need to decide in advance which die will be your first number, which will be the second, and which will be the third, as if you wait until after you have rolled to pick the order then you introduce bias. In such a scenario, if die 1 has a bias towards 1 and die 2 has a bias towards 2, then ending up with HHH will be more likely than any other combination.

The method only works on a single die because each individual roll has the exact same chance to be biased as every other roll.

that's exactly the point I was trying to make. along with the fact that if I give you some 32 character HEX string where one HEX symbol appears more than 2 times, you don't have anyway of knowing what caused that to come about - be it just a random happening or something that was caused by a bias towards that particular hex digit.

Interesting but it seems like that would basically multiply the number of rolls required by at least a factor of 6. that's a bit unrealistic to force someone to roll a dice around 600 times just to generate a single bitcoin private key. the chances they make a mistake at some point are high. maybe a way to shortcut that process would be to take 3 dice and roll them all at the same time.

That is undoubtedly a terrible idea, but that doesn't mean we should be promoting other risky ideas in its place.

It can, but it is significantly more complicated. Essentially you would roll the dice three times, and make a note of all three numbers. If any number is repeated, you discard the rolls and start a new set of three. You then note if the second number is higher (H) or lower (L) than the first number, and then if the third number is higher than both the first and second numbers (HH), lower than both the first and second numbers (LL), or between the first and second numbers (B). This allows you to generate 6 possibilities from your three dice rolls:

HHH
HLL
HB
LHH
LLL
LB

You map each of these six possibilities to a number from 1 to 6, and repeat until you have as many numbers as you need.

This works because rolling 1,3,5 is equally as likely as rolling 1,5,3 or 3,1,5 or 3,5,1 or 5,1,3 or 5,3,1, regardless of the bias towards any individual face of the dice.

There are obviously worse habits when generating a wallet. We're trying to minimize the risks.

That definitely inherits some risks. But, if you've verified the authenticity of bitaddress on a transparent operating system, which works air-gapped, you've minimized the risks.

What does this have to do with anything? A private key in which one character appears more than once doesn't make it less secure than one which doesn't.

maybe it is. but i think there's worse things someone could do to generate a private key than rolling a dice. like using a computer connected to the internet and generating it right off a live website such as bitaddress. how many people have been hacked that used a private key generated by rolling some dice? haven't heard of that happening...

not every bitcoin private key has exactly 2 hex characters of each digit...so for most private keys there is going to be one hex character at least one that appears more than the others. whether that came about through a biased dice or a random number generator on a computer, you would have no way of knowing.




never heard of that method but after analyzing it, I guess it does work since the probability of TH and HT are equal. Which is all you're counting. When you get HH or TT, you ignore it. maybe that same method could be applied to rolling a single die but it's not clear how.

That's a 64 digit number. Did you perhaps mean 32 bytes?

There's no more or less security, given that the bits of the string are (about six time) more than the bits of the number. Whether you chose the bytes of string "123456" or the bytes of number (123456)₆ as your entropy, it would be of the exact same security, but the bits would not be equal. Specifically, the string is 6 bytes, but the number is about 1 byte, so you should be careful when comparing bits' security. 128 bits of a string are going to be less secure than 128 bits of a base 6 number.

@o_e_l_e_o, I've started a question at stackexchange: https://crypto.stackexchange.com/questions/102227. Let's see how this goes. Also, I read this: https://nitter.net/raw_avocado/status/1497110041131769856. Basically, while exceeding my knowledge, it says that entropy loss is logarithmic, and even a very biased coin can create a secure seed if tossed enough times.

Exactly the point. If you have no idea how biased your dice are, then why would you feel comfortable using them to generate something as sensitive as a bitcoin private key or seed phrase? That's just irresponsible.

Depends how certain you want to be that your coin is fair. You can never be 100% sure your coin is fair, but you can asymptotically approach 100% with increasing confidence of ruling out ever smaller biases. For example, to exclude a 55/45 bias with 99% confidence, you would need to flip the coin 664 times. However, to exclude a 51/49 bias with 99% confidence, you would need to flip the coin 16,589 times.

A more practical approach would be to simply use the von Neumann approach I alluded to above. Take any coin and flip it in twice. If the first flip is heads and the second flip is tails, write down 0. If the first flip is tails and the second flip is heads, write down 1. If the two flips are both heads or both tails, don't write down anything. Repeat until you have 128 zeros or ones written down. This method completely eliminates any bias in the coin and produces a uniformly distributed output. It will require a lot less flips than any method to test whether or not your coin is actually fair.

There is a difference between using a different encoding and actually padding the bits you have with arbitrary values, and you are confusing these two.
Padding is when you add extra bits to for example if we are only producing 3 bits 1 with padding is 0b00000001 and the next value 2 with the same padding is 0b00000010. If we add these two we get 0b0000000100000010. But actually encoding the bits you have produced without padding will give you this: 001+010=0b001010

The hex you posted from a private key was produced by generating all bits in each byte without needing any pads. To do the same padding in this base means producing something like this: 0x008100470078...

i don't know if i follow the logic about the "false sense of security" thing. in typical applications like say converting a bitcoin hex private key into a wif format, you are dealing with a 32 digit long hex number. like this one: 8147786C4D15106333BF278D71DADAF1079EF2D2440A4DDE37D747DED5403592

now the point is that you treat it however you want to but just because you assign more bits to each character doesn't mean it has more security. there are only the same number of such 32-length objects no matter what naming convention you use thus it doesn't matter how you represent them with regards to how many bytes they use for storage purposes.


that's irrelevant though.


I think it is pointless to try and use a randomness extractor from any type of process like dice rolls or coin tosses. You're not going to improve the randomness by doing that. I think it's harder to model the physics of a dice roll than a coin toss though. It's much more complicated thus harder to predict the outcome. I'm not sure how biased an average die is and if that really has any significant affect that can be exploited on a very small sample size because no one is going to use a single die to generate more than a few bitcoin addresses most likely. Not all coins are fair either. How do you test that?