You think very predictably
That was what it was about creating these puzzles
Topic: The Legend of Satoshi Nakamato, FINAL STEP PUBLISHED.... 4.87 BTC GRAND PRIZE! - page 36. (Read 108519 times)
January 04, 2018, 06:17:54 PM
January 04, 2018, 06:14:36 PM
I would like to share some statistics I've made,
the conclusion: It is not possible that the "yellow/red", "green/blue" bits (only) encode a private key
(or at least very unlikely)
(....)
the conclusion: It is not possible that the "yellow/red", "green/blue" bits (only) encode a private key
(or at least very unlikely)
(....)
congrats on your in-depth analysis and profound conclusions, Zbyszek. And thanks for sharing that
EDIT: still, they can be a mapping into more random data (a board has been mentioned)
January 04, 2018, 06:12:04 PM
If we are on the level of terminology, the more accurate statement would be that WIF is a 51 char string with certain chars excluded.
Yep, you're right. WIF as 306 bits doesn't really exist outside my convenient mapping from 6 bits onto base58 space. So my 306 bit definition fails
I take it back.I mean. Isn't that expected? When encoding values using Bacon you use 5 bits but you only have a dictionary of the characters you need.
January 04, 2018, 06:07:22 PM
If we are on the level of terminology, the more accurate statement would be that WIF is a 51 char string with certain chars excluded.
Yep, you're right. WIF as 306 bits doesn't really exist outside my convenient mapping from 6 bits onto base58 space. So my 306 bit definition fails
I take it back. January 04, 2018, 05:56:23 PM
Of course it does leave 51 chars in base58 encoding. It is by no means surprising. As I said above, 152 flames, if you assume a flame codes only 2 bits i. e. two colors, inner and outer (with length bits EXCLUDED, exactly how you did exclude length information but using a different method), code 304 bits which is exactly the WIF length and as I said above, this is exactly the reason this theory was so appealing to many forum members (around page 29 of this thread I think)
Just to clarify terminology, WIF format is not 304 bits (my mistake on a previous post too, BTW).
WIF implies a base58 encoding because it's the format you import into a wallet. In this case, it would be either 306 bits for a non-compressed version and 312 for compressed version assuming 6 bits per char.
"assuming 6 bits per char". And it is a big assumption. In reality WIF IS 304 bits, consult with http://lenschulwitz.com/base58 and try to decode a sample WIF into the HEX and vice versa. If it were 306 bits it wouldn't decode to 38 byte (76 digit) HEX which is 304 bit only.
If we are on the level of terminology, the more accurate statement would be that WIF is a 51 char string with certain chars excluded.
This is all off-topic, just to be on the same page discussing terminology
January 04, 2018, 05:56:11 PM
I would like to share some statistics I've made,
the conclusion: It isnot possible that the "yellow/red", "green/blue" bits (only) encode a private key
(or at least very unlikely)
(EDIT: see bottom comment)
looking at the distribution of 1's in the "yellow/red", "green/blue" bit streams it looks like the stream is random
we have 78 - 1's in "yellow/red" stream and 77 -1's in "green/blue" stream (nearly 50% of all 152x2 bits)
but if we take only bits if a flame is long:
we get:
P(yellow/red = 1 | long) = 0,6559139785
P(green/blue = 1 | long) = 0,5161290323
this is very strange (assuming the streams are random) but still possible, so let just check every second bit and cut out only bits according to 011011 pattern:
P(yellow/red = 1 | '0 1 1' = 1) = 0,68
P(green/blue = 1 | '0 1 1' = 1) = 0,52
this is very unlikely to happen for a private key, how unlikely?
I've tested 1000 WIF private keys generated with vanitygen in base64, base58 and binary coding, the highest P(private key = 1| '0 1 1' = 1) was ~0.62
Here are my statistics:
1. average P for a private key generated with vanitygen (1000 samples)
2. P for short/long, yellow/red, green/blue and slim/fat bit streams with cutouts (columns)
https://imgur.com/gallery/JRZFs
in case of 2. we can clearly see there is a correlation between "short/long" - "yellow/red" streams and "green/blue" - "slim/fat" streams
EDIT:
In this analysis I assumed that the private key is random, but that is not necessarily true,
in fact we only need 42bits of "randomnes" to generate a public key with a "1FLAMEN6" prefix,
so after all my main conclusion is probably wrong
the conclusion: It is
(or at least very unlikely)
(EDIT: see bottom comment)
looking at the distribution of 1's in the "yellow/red", "green/blue" bit streams it looks like the stream is random
Code:
yellow/red 00010101001011011100101100000000101110111000111100001010111000011100010111111101011100111101001100101001101100110001111000110000101110101100011101110010
green/blue 10001101001010111100001110110111110110010000101101000000110011011100011000101010011110010000001110100100010111111111011000011111101001011011010010101000
but if we take only bits if a flame is long:
Code:
short/long 01101101101000101101101100111101111101101101111100101000111000101101111101111101111100111001101101101101101000101101111100101000111100101100111001101100
yellow/red 00 01 10 1 0 11 01 11 0000 01011 01 10 01111 0 1 111 0 11 00101 11111 10111 111 10 11 01 10 11 1 1 00 11110 1 0 1011 1 11 011 11 00
green/blue 00 11 10 1 1 11 00 11 1101 11101 00 00 01011 0 0 110 0 11 00110 01010 00111 010 00 11 01 01 00 0 1 11 10110 0 1 1010 0 10 010 01 10
P(yellow/red = 1 | long) = 0,6559139785
P(green/blue = 1 | long) = 0,5161290323
this is very strange (assuming the streams are random) but still possible, so let just check every second bit and cut out only bits according to 011011 pattern:
Code:
pattern 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0
yellow/red 0 0 0 1 0 1 1 1 0 0 1 1 1 1 1 1 0 1 1 1 0 1 0 0 1 1 0 1 1 1 0 1 1 1 1 1 1 0 1 1 1 0 1 1 1 1 0 1 1 0
green/blue 0 1 0 1 1 1 0 1 1 0 1 0 0 0 1 1 0 0 1 0 0 1 0 1 1 1 0 1 0 0 0 1 1 0 0 0 1 1 0 1 0 1 1 1 0 1 0 0 1 1
P(yellow/red = 1 | '0 1 1' = 1) = 0,68
P(green/blue = 1 | '0 1 1' = 1) = 0,52
this is very unlikely to happen for a private key, how unlikely?
I've tested 1000 WIF private keys generated with vanitygen in base64, base58 and binary coding, the highest P(private key = 1| '0 1 1' = 1) was ~0.62
Here are my statistics:
1. average P for a private key generated with vanitygen (1000 samples)
Code:
vanity key bin base64 base58 ascii 7bit ascii 8bit
avr 0,4910042715 0,4928240574 0,4593443252 0,538281408 0,470996232
https://imgur.com/gallery/JRZFs
Code:
all '10101010’ '01010101’ 1 1 0 1 1 0 0 1 0 0 short/long 1 short/long 0 yellow/red 1 yellow/red 0 green/blue 0 green/blue 1 slim/fat 1 slim/fat 0
short/long 0,6118421053 0,6578947368 0,5657894737 1 0 1 0 0,7820512821 0,4324324324 0,6233766234 0,6 0,7333333333 0,4935064935
yellow/red 0,5131578947 0,5263157895 0,5 0,68 0,2307692308 0,6559139785 0,2881355932 1 0 0,5584415584 0,4666666667 0,56 0,4675324675
green/blue 0,5065789474 0,5263157895 0,4868421053 0,52 0,5384615385 0,5161290323 0,4915254237 0,5512820513 0,4594594595 1 0 0,6266666667 0,3896103896
slim/fat 0,4934210526 0,4210526316 0,5657894737 0,52 0,2307692308 0,5913978495 0,3389830508 0,5384615385 0,4459459459 0,6103896104 0,3733333333 1 0
Bit count 152 76 76 50 26 93 59 74 78 77 75 75 77
in case of 2. we can clearly see there is a correlation between "short/long" - "yellow/red" streams and "green/blue" - "slim/fat" streams
EDIT:
In this analysis I assumed that the private key is random, but that is not necessarily true,
in fact we only need 42bits of "randomnes" to generate a public key with a "1FLAMEN6" prefix,
so after all my main conclusion is probably wrong
January 04, 2018, 05:53:28 PM
It is extremely interesting. Maybe even a breakthrough post, for me. If you divide it in groups of 6 (exactly how alphabetcanary did for lengths earlier) you'll notice that the same patterns reoccure all over again:
Wow, actually that would be a game changer if true! I will try to verify.
January 04, 2018, 05:41:57 PM
Have you tried using the inner shape as the third bit (skinny line or blob of paint)?
you mean something like this:
Code:
short/long 01101101101000101101101100111101111101101101111100101000111000101101111101111101111100111001101101101101101000101101111100101000111100101100111001101100
yellow/red 00010101001011011100101100000000101110111000111100001010111000011100010111111101011100111101001100101001101100110001111000110000101110101100011101110010
green/blue 10001101001010111100001110110111110110010000101101000000110011011100011000101010011110010000001110100100010111111111011000011111101001011011010010101000
slim/fat 01001100001100011101011101011100001110001101011100010000111111000110011000100011010000011001001101001100011000101001011100011111110100111011011000111100
it is a possibility, in some cases the blobs (slim/fat) look like there were corrected.
It is extremely interesting. Maybe even a breakthrough post, for me. If you divide it in groups of 6 (exactly how alphabetcanary did for lengths earlier) you'll notice that the same patterns reoccure all over again:
Look:
Code:
slim/fat
010011
000011
000111
010111
010111
000011
100011
010111
000100
001111
110001
100110
001000
110100
000110
010011
010011
000110
001010
010111
000111
111101
001110
110110
001111
00
I am not sure what to do with that (yet, I hope), just sharing what I noticed
January 04, 2018, 05:41:31 PM
Of course it does leave 51 chars in base58 encoding. It is by no means surprising. As I said above, 152 flames, if you assume a flame codes only 2 bits i. e. two colors, inner and outer (with length bits EXCLUDED, exactly how you did exclude length information but using a different method), code 304 bits which is exactly the WIF length and as I said above, this is exactly the reason this theory was so appealing to many forum members (around page 29 of this thread I think)
Just to clarify terminology, WIF format is not 304 bits (my mistake on a previous post too, BTW).
WIF implies a base58 encoding because it's the format you import into a wallet. In this case, it would be either 306 bits for a non-compressed version and 312 for compressed version assuming 6 bits per char.
304 bits = 38 bytes which is enough space for a compressed 'raw' key (not base58, but the bytes before it gets base58 encoded) which fits just the inner/outer color informatin.
I think the subtle difference here is I don't exclude ALL length information when making the key. I include 2 bits to get up to that 306 number so I can make a base58 string. But I agree, this is not that surprising since I outlined all this around page 25 of this thread.
January 04, 2018, 05:29:47 PM
Have you tried using the inner shape as the third bit (skinny line or blob of paint)?
No. I noticed those too but just felt it was not consistent enough to count as data. 6PR theory might still be possible but I haven't gone down that road.
January 04, 2018, 04:09:43 PM
(Here, I've concatenated all the data starting with lengths, then inner, then outer colors in the order of the pattern. This is just ONE of a many ways of concatenating the data. Just for demonstration purposes, I used a base 58 alphabet here and use ? when the value goes beyond 58. By no means is this a complete list).
Now, due to the pattern in the lengths, the beginning part sticks out like a sore thumb because there are actually only 8 possible combinations for 6 bits when you fix 3 of them (0.1.1.). Turns out only 7 are actually used. That's why the characters repeat. So let's split the strings where the repeated characters end:
Code:
EgEG6Gn6nngGppn86GnppEn6n d?cQHrytSLCtk?cav4rxH4LnBZNCTQyU?heqAzMR?D3uApnq?Kr
UTCUGYUYBFCYYYFUUTCYBGCFU 2Mnsq3?cqkarYvtusft8c30rxBEB?FxwHn1tVRjXHFdQ?RYiUKh
UTCUGYUYBFCYYYFUUTCYBGCFU 9ukq?YS3u4Erbiz10JY?a?enBZNCVm1oy?ByVQ?V?DimryqomWs
UTCUGYUYBFCYYYFUUTCYBGCFU 2Mnsq3?cqkarYvtusft8c30rxAsv4r9ApK?DcgNaprUh1gZPdnQ
deudqZdZvruZZZrddeuZvqurd rMnsq3?cqkarYvtusft8c30rxAsv4r9ApK?DcgNaprUh1gZPdnQ
deudqZdZvruZZZrddeuZvqurd xCMG5Zf?C?sFWP7?6oZ3X2TKvVNCVm1oy?ByVQ?V?DimryqomWs
Oh look, you end up with exactly 51 characters left over after the pattern ends. (Note: This actually means that you start taking 'key' bits while two bits away from the end of the lengths but I don't think that really matters. That could be the tricky part. There's no reason the key needs to start exactly on a boundary between lengths and colors, for example.)
January 04, 2018, 03:55:57 PM
Have you tried using the inner shape as the third bit (skinny line or blob of paint)?
you mean something like this:
Code:
short/long 01101101101000101101101100111101111101101101111100101000111000101101111101111101111100111001101101101101101000101101111100101000111100101100111001101100
yellow/red 00010101001011011100101100000000101110111000111100001010111000011100010111111101011100111101001100101001101100110001111000110000101110101100011101110010
green/blue 10001101001010111100001110110111110110010000101101000000110011011100011000101010011110010000001110100100010111111111011000011111101001011011010010101000
slim/fat 01001100001100011101011101011100001110001101011100010000111111000110011000100011010000011001001101001100011000101001011100011111110100111011011000111100
it is a possibility, in some cases the blobs (slim/fat) look like there were corrected.
January 04, 2018, 03:50:56 PM
5). We begin to look at the requirements for the output. We see that this is closest to the WIF format. Given we know WIF is base 58 we can do a calculation to know the minimum amount of information needed to express one character:
ceil(log2(58)) = 6 bits
6 bits * 51 characters = 306 bits
So given, if the flames were used to encode a WIF string you'd need 2 flames for each character.
Actually WIF requires 304 bits which is (so it happens) 38 bytes which is 32 bytes for the 64hex private key format+1 byte (x80 header)+1 byte (x01 footer) + 4 bytes checksum. This is why 152-flames-coding-two-bits-only theory (with bits coded by inner&outer color and using length only as a pacemaker) was so appealing to many.
- 2 missing symbols represents the death of the phoenix and turtle dove.
I am sorry to have written the end to your theory of two missing flames symbolizing two loving souls. It was beautiful but unsound.
I'll give a fairly big hint. There's two missing flames in the inner ring. Beyond that, the way things are encoded is a mystery. But that should be enough, if you can reason with the theme of the poem, to catch up with what he's likely talking about.
Are those the two flames supposedly representing the death of the phoenix and turtle dove?
One more point. You published a nice google document with some information on missing flames in the outer border. The document has been subsequently edited with the relevant information removed. What is really your group's purpose ?
I used 6 bits assuming that each character was encoded using a fixed length (see Bacon Cipher). I edited it (I only have editing permissions) because I did not have conclusive evidence to keep it in the document. The document is my personal platform for notes, what I see as distracting or misleading I remove.
Edit: Are you assuming compressed private key?
it really does not matter. The compressed and noncompressed differ only in one byte (the x01 footer). Please refer to https://en.bitcoin.it/wiki/Wallet_import_format
The relevant data is 32 bytes for a bare private key, 37 bytes for noncompressed wif (no x01 footer), 38 bytes for compressed wif. The base58 is just another representation for those 37 or 38 bytes. Because the first byte is x80 and base58 codeing is not byte-per-byte, it starts always with 5 or K(L) depending if it is compressed or not. Whatever it is, the bitwise contents will be same (regarding the middle part i.e. the bare private key) for all representations.
@sini: Please reshare your outer border missing flames analysis
January 04, 2018, 03:43:23 PM
(Here, I've concatenated all the data starting with lengths, then inner, then outer colors in the order of the pattern. This is just ONE of a many ways of concatenating the data. Just for demonstration purposes, I used a base 58 alphabet here and use ? when the value goes beyond 58. By no means is this a complete list).
Have you tried using the inner shape as the third bit (skinny line or blob of paint)?
Each inner flame is either a blob or a line.
Inner Color, Outer Color, (Line/Blob)
8 variations of flames taken in pairs. 76 pairs of 64 variations.
I still think we are looking for a BIP38 encrypted key starting with 6PR.
Can I ask why you think that's the case?
January 04, 2018, 03:09:25 PM
(Here, I've concatenated all the data starting with lengths, then inner, then outer colors in the order of the pattern. This is just ONE of a many ways of concatenating the data. Just for demonstration purposes, I used a base 58 alphabet here and use ? when the value goes beyond 58. By no means is this a complete list).
Have you tried using the inner shape as the third bit (skinny line or blob of paint)?
Each inner flame is either a blob or a line.
Inner Color, Outer Color, (Line/Blob)
8 variations of flames taken in pairs. 76 pairs of 64 variations.
I still think we are looking for a BIP38 encrypted key starting with 6PR.
January 04, 2018, 01:45:00 PM
Oh, I know how not to be a troll
"Count, the number of flames, there is hidden, she hid, it must be, there is no other solution, only flames, any other solution is bad"
Now it fits and I'm not a troll anymore?
Every normal person will think twice about what they count at all and if their puzzles are worth it
"Count, the number of flames, there is hidden, she hid, it must be, there is no other solution, only flames, any other solution is bad"
Now it fits and I'm not a troll anymore?
Every normal person will think twice about what they count at all and if their puzzles are worth it
I miss you
January 04, 2018, 01:35:35 PM
The chess board, not as much.
LOL , so you don't have another great theory for the board?
January 04, 2018, 01:32:25 PM
Why are you getting salty. You're literally oozing cognitive dissonance. The turtle dove and phoenix were important. The chess board, not as much.
January 04, 2018, 01:26:06 PM
The outer ring, if you count orange flames, has almost the exact same number of flames as the inner ring. The thing is having a clear definition of what is an 'orange' flame and a colored one.
My theory stands as well that the outer ring and inner ring are needed to decode one another. I believe the outer ring is more likely the key, and the inner ring the cipher text. But the rest is a mystery.
My theory stands as well that the outer ring and inner ring are needed to decode one another. I believe the outer ring is more likely the key, and the inner ring the cipher text. But the rest is a mystery.
According to your great theory we need only 10% of the image to solve the puzzle! what an amazing theory! it sounds like coin-artist is stupid
https://imgur.com/a/91nrE
January 04, 2018, 01:09:10 PM
The outer ring, if you count orange flames, has almost the exact same number of flames as the inner ring. The thing is having a clear definition of what is an 'orange' flame and a colored one.
My theory stands as well that the outer ring and inner ring are needed to decode one another. I believe the outer ring is more likely the key, and the inner ring the cipher text. But the rest is a mystery.
My theory stands as well that the outer ring and inner ring are needed to decode one another. I believe the outer ring is more likely the key, and the inner ring the cipher text. But the rest is a mystery.
Jump to: