Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
So theoretically we have base58 what means we can have 58 letter and number to choose, means the probability of each letter is 1/58, so 1.7241379%
Not really, you started off from a wrong premise.RIPEMD: 160 bits. 2**160 choices.
2**160 does not divide by 58 so your probability doesn't take into account the bias for the last remainder (only 52 choices out of 58, hence fewer z w x... was this your secret information to keep for yourself lol?), and neither the implicit "1" characters found at the beginning, when the address is shorter than the maximum length (explaining fewer "1"s). Those leading zeros are actually the character "1" in base58. The leading "1" in the address is discardable since it's just a hint that the first byte of the number is 0, which is always true.
Not really, I discarded the first number one because is a testnet, so basically I didnt screw my statistics.
But basically you are wrong because you can run by yourself and see the average of all probabilitiess and nail at 1.7241379% in all decimals, means IT IS 1/58 regardless.
Furthermore, I didn't found any explanation why has this preferential for some letter if is a "random math base equation" even if you use other hexadecimals. Is this not defeat the entire propose of been random?
I mean, run the same statistics for range for 100k between 89f183007d3ce24269a66fb7fe4bc132a0ec877a0b145f6dbb5058f36921cfe3 to 89f1830088a1ec1b926f4b894b4e7b2c6b66dea05bd76434ab5058f36921cfe3 give the same 20 letters above the average of 0000000000000000000000000000000000000000000000020000000000000000 to 000000000000000000000000000000000000000000000003ffffffffffffffff... is very odd to say at least.
IDK but I believe is worth it to try, with more time and effort, and a better computer...
Anaconda is literally make my laptop give me 3 degree burn ngl because of the simulations i need to use a ice pack... that's how F up is my set up
was this your secret information to keep for yourself lol?
Lol.... if is secret is a secret...just a hint, is not that...
Has way more mathematical ways to explore this problem.
But I need to pay my rent first, otherwise I will sleep on the streets lol
Maybe run the stats on the base2 160 bits instead?
Not bad idea...
I ran per letter/hexadecimal and the results were very, very, very wild
base58 strings don't map 1:1 with any bitstring, since there is no power of 2 to divide 58, so their space lengths don't fill each other exactly, e.g. I can give you base58 "addresses" with a length identical to a correct one, but that will require more than 160 bits.
[LE] It's actually worse than this. Because there's 4 bytes of checksum added to the RIPEMD, and THEN it goes into the base58 encoder, we have 2**192 % 58 = 38 as a remainder. So this might explain your findings better. Last symbol is heavily biased, it only covers 2/3 of the possible choices.
That's a possibility, but when you have a bias, you have a weakness [LE] It's actually worse than this. Because there's 4 bytes of checksum added to the RIPEMD, and THEN it goes into the base58 encoder, we have 2**192 % 58 = 38 as a remainder. So this might explain your findings better. Last symbol is heavily biased, it only covers 2/3 of the possible choices.
It is a known theorem that if two numbers do not divide each other, then bias occurs when using one of them to produce ranges in the other one. Take for example the hidden issues when (naively) doing something like this:
A histogram on r will reveal pretty fast that (assuming random() is uniform) you will have a big bias between the range [0, n) and the range [n, 7}, where n = MAX_RAND % 7. Because there's more possibilities to choose from one range than the other one, due to the remainder.
Code:
int r = random() % 7
A histogram on r will reveal pretty fast that (assuming random() is uniform) you will have a big bias between the range [0, n) and the range [n, 7}, where n = MAX_RAND % 7. Because there's more possibilities to choose from one range than the other one, due to the remainder.
That's something I commented way before: using the idea we are using pseudo-random number + a bias operation, this can, theoretically, reversible... at least for a range
But I need to check montecarlo first.... when I have time
If you have more ideas, I will love to listen