Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 195. (Read 229812 times)

OP! Bulista, Welcome back! Nice to meet you again mate, Glad to see you alive! Are you doing okay?

There are currently no known formula and will probably not be one to be found for the puzzle private keys which did not reveal its public key. The only way to search and find 66 is the bruteforcing.

HOWEVER: every 5 bits have their public key revealed which makes it easier to solve with a LOT of known and NOT known formulas for example Kangaroo made by Jan or BSGS (Baby Step).
Nevertheless recently puzzle 120 and 125 got solved by the same persons or group of people which make us doubt that there are indeed a hidden formula that is being used to solve the puzzles that have their pub keys revealed by those unknown group of people. We believe the same solvers are currently trying to solve 130 now too. Which has over 13 BTC now. We are trying to fight them and take the coins before they take 3 prizes in a row.
Keep in mined, the possible hidden formula applies only for the puzzles addresses, that haves their pub keys revealed. For 66, there is almost 100% certainty that it will not be possible to solve exepct by bruteforcing. Because its public key is not revelaed and the hash cannot be undone, so there is no way to escape.

Nice to see this puzzle is still on going. It’s been years and I totally forgot about this.

So the conclusion until now is that it is only possible to crack the keys with brute force and no formula was found?

Was thinking to start working on this again but when I think of the amount of brain cells that are going to be destroyed I just shake it off.

What I could eventually do is provide some funds for funding of hardware or something needed.

Anyone thinks that with the help of some funds it can help to crack the case?

Thank you so much @WanderingPhilospher for compiling. You indeed compiled them last year, but you only compiled 2 tools out of 8 tools that Alberto developed. Now after checking github, they re now completed. Thanks friend again!

Let me explain you all guy how one can reduce bit size from 2^130 to near to 2^103.
First of all you just focus on how much bits are reduced? around 26 bits right (The first one can always be subtracted from pub key). So how big is 2^26? 2**26 = 67108864
So these are the pub keys in which one of the key is under 2^103.
The moment to try to go one single bit further, things are gonna get a little bulky.
The trick is simple, you have 1 public key, add generator to it and now you have two public keys whose private keys for instance are 89 & 90 or 534354234384847 & 534354234384848.
Why we do this? because we want to divide our public key to reduce its size and we don't know whether it is odd or even so add one to it and and now you have both.
Now you divide both and you have one correct result and one incorrect.
In second step you repeat the process of adding 1 to both of them and dividing 4 of them..
So this is like dividing pubkeys, 2, 4, 8, 16, 32, .... yep,, you got it!!

Excellent idea!, thank you; now I just need to know if mcdouglasx is willing to play along.

Do I not have a compiled version on GitHub?

If this is the one that also contains, BSGS, that’s the only program that doesn’t work on my compiled version.

Just sign a message with the privatekey to proof that you own the privatekey for the pubkey without exposing it.
Post the signature with the used message. Without knowledge of the message the signature can be forged.

You are right, I didn't even think about it. On the other hand, I understand his point. I can make another pub key and see if he's willing to test his method with me or not.

With a known private key, each person can reduce the key to any size.  Here is an example:

115 bit
pub key: 02903740144e9f301f62362813dec638747153d4f18467f32286d09b9b4412768b
priv key: 0x5735095df3f8c24ee33e4dfe955da

85 bit
pub key: 02f50518c0b808dff5bd75f10e146d33677dccbfd18370e64be0c4cc36abc9675f
priv key: 0x1f3f8c24ee33e4dfe955da

40 bit
pub key: 03a0f8f7d72f6199bb09762c8500ed22eba5253f9661f752db338bbf5eeefb1852
priv key: 0xe4dfe955da

By revealing the private key, you will not know whether the method works or not.

Well, if that is really the problem, here is the private key for that public key:

 priv key HEX:               0x155d735095df3f8c24ee33e4dfe955da
 priv key DEC:               28399010381067550399127235982780880346

 pub key:                       0343b7d69e8372746596980d678d6cdecbffb2927916b3dbd3bc3d27bf5366b166


As you can see, I won't solve any puzzle with the info you provide; I only want to test if your script works or not.

But if you decide not to test it with me, that's OK.

Cheers.

Sorry, If I manage to solve any puzzle I will give all the information at the moment I do not have a good economic position for it.

Anyone could add x quantity to the puzzle key, generating a different public key and camouflage the puzzle with it, and by giving them information I would be solving the puzzle without knowing it.

then simply subtract that same amount from the camouflaged public key and go back to the puzzle and solve it.

Have you thought about it? You can post them here if you prefer.

they are all in the 255 bit range, 256 bit is a mirror. a mathematical illusion.

therefore any key in it is in 255 bit and 256 bit simultaneously.

So are you suggesting that all the keys starting with 8, 9, a, b, c, d, e and f are all in 255 bit range and also all keys starting with 1, 2, 3, 4, 5, 6, and 7 are as well in 255 bit?



Whenever you see a private key starting with 8, 9, a, b, c, d, e, f, you can tell it's 255+ bit, even most of the keys starting with 7 are in 255+ bit. This is why I use hexadecimal over decimal, as it is easier to recognize patterns, but if you work with decimals, you can't even tell which number is greater than the other, but in hex you can count 2 by 2 to quickly determine the size and the exact range.

For the love of Almighty God, for the love of everything, Please guys help me; someone help this newbie compile the ecctools made by Alberto for windows,

https://github.com/albertobsd/ecctools

I tried compiling myself but it fails. I don't know, I'm not programmer.

Many thanks,

All keys are in 255 Bit , 256 bit is a mirrow

0x7/2
./keymath 025cbdf0646e5db4eaa398f365f2ea7a0e3d419b7e0330e39ce92bddedcac4f9bc / 2
Result: 03592152c398d6c719636a03a6dad64246a5a6814aa62c156b0ce5332f6759b031
We get the result divided in half in the middle of the key range of the bitcoin curve.
https://privatekeys.pw/key/7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a4#public

How do you propose we divide by bits down to 1? And who taught you what exactly, the youtube you meant?

---

He just subtracted 7 from N and divided the result by 2, and as I see it, it's just 15 divided in half, because dividing 7 in half would give you 3.5 where you could see 3 as the first character and that .5 as a huge number, here is the example :
3fffffffffffffffffffffffffffffffaeabb739abd2280eeff497a3340d9052

As you see, the .5 which is a fraction has turned to something different, this is the beauty of big numbers combined with elliptic curves.😉

    (dec)HALFINV:  57896044618658097711785492504343953926418782139537452191302581570759080747169 Length Bits =  255
    (dec)HALF   :    57896044618658097711785492504343953926418782139537452191302581570759080747168 Length Bits =  255

    Privatekey (dec)k3:  57896044618658097711785492504343953926418782139537452191302581570759080747168 Length Bits =  255
    Privatekey (hex)k3:  7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0

    k3 X:  86918276961810349294276103416548851884759982251107
    k3 Y:  28597260016173315074988046521176122746119865902901063272803125467328307387891
    Binary k3:  1111111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111110101110101010111011011100111001 1010101111010010001010000000111011101111111101001001011110100011001101000000110 110010000010100000



Privatekey (dec)k3h:  57896044618658097711785492504343953926418782139537452191302581570759080747169 Length Bits =  255
    Privatekey (hex)k3h:  7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1

    k3h X:  86918276961810349294276103416548851884759982251107
    k3 Y:  87194829221142880348582938487511785107150118762739500766654458540580527283772
    Binary k3h:  1111111111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111110101110101010111011011100111001 1010101111010010001010000000111011101111111101001001011110100011001101000000110 110010000010100001

# Curve-secp256k1

modular elliptic curve

Total of all the wallets n is the last number.
n= 115792089237316195423570985008687907852837564279074904382605163141518161494337 (In Dec)

n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 (In HEX)

Half way of n
n//2 = 57896044618658097711785492504343953926418782139537452191302581570759080747169

57896044618658097711785492504343953926418782139537452191302581570759080747169 Lenght Bits =  255

So we know half way is 255 Bit so 50% of wallets in 255-256 Bits and the other 50% in 1-255 Bits.

What if we could divide by bits the range all the way to 1 bit? All keys are the modular inverse of the first key start point.

Thanks to Quite the Contrary for teaching me how to do this https://youtu.be/Vlqy1zB-QkE  ecdsa secp256k1 algorithm explained.
 

As I see it, it's just 7 divided in half.
https://privatekeys.pw/keys/bitcoin/1286578769303513282484122055652087865031528491989721159806724034905757349938#7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0