Topic: == Bitcoin challenge transaction: ~1000 BTC total bounty to solvers! ==UPDATED== - page 16. (Read 47425 times)

Ok, here you go.
Subtract this
0302157655af8bb1decd37d161aa92cc7050cae1d6b4f44e4aa04507e3c1855159

From this
000000000000000000000000000000001e739ce739cf7bdef7bdef7bdef7be0c

To reach #125.

Adding this
00000000000000000000000000000000018c6318c630842108421084210841f4

To the key above will get you 2^125.

Subtracting the above from this

0286936a275e6d53bb2b2718c93d8a5aa44f371f6e0300abb73b89dd851d2fbe88

Will get you this

0302157655af8bb1decd37d161aa92cc7050cae1d6b4f44e4aa04507e3c1855159

Therefore, #125 is smaller than
000000000000000000000000000000001e739ce739cf7bdef7bdef7bdef7be0c


Note, if you add this

0286936a275e6d53bb2b2718c93d8a5aa44f371f6e0300abb73b89dd851d2fbe88

To #125, you will reach 2^125.

If you are smart enough you should figure out  what the above key actually is, by eliminating possible candidates, meaning you should find keys  smaller than this
000000000000000000000000000000001e739ce739cf7bdef7bdef7bdef7be0c

And compare their distance to 2^125, with this one

0286936a275e6d53bb2b2718c93d8a5aa44f371f6e0300abb73b89dd851d2fbe88

If you could find a key greater than above to add to another key in order to reach #125, then that key is smaller than #125.

I know it's confusing, but you need to put #125 in the middle of a smaller one and a greater one, then the distance between those 2 keys is

0286936a275e6d53bb2b2718c93d8a5aa44f371f6e0300abb73b89dd851d2fbe88

You'd solve the puzzle.😉

I get that fact now bro, let's do the maths and not be a pussy. I'm new on the calculations part too and I am very much interested in puzzle 125 as well. How do we begin the calculation? my machine can also go as much as 80 Pkeys/seconds for puzzle 125 on Keyhunt BSGS Mode. Give a range lets search some more. I've only been randomly searching bit range 125 for over 20 days now still no luck.

I wonder if you read my posts then why haven't you noticed that I'm not solving #66, but #125.
Bitcoin public keys represent numbers like 1, 2, 3 etc, the only way to find them is through math.

Anyone using powerful hardware to find a puzzle is a pussy, so using hardware to do the job is for pussies, now tell me, are you a pussy? Do you want to rely on silicon wares and keep your brain zipped or are you going to use it and join the team of real men? 😉

I see many of yours message in this topic; do you have a good machine to try your ideas/calculation? Why don't you want to understand that puzzle isn't solvible with the math, but you need a massive hardware computation

for only tryin to solve it. At this stage, I guess that puzzle 66 will require many months to be solved, unless community will combine its own force.

i told you im working on 125 bit, that means, im substracting the 125 with -f address to find similar address because when you substract you will have the end space ffffffff..... to 125 bit space,,, we can get any address in bit 90 or 100 im trying to guess a smaller range to search the sub there you get it bro ?? and yes there is a diffrence, and for now im working on public keys to find their range exactly that will help scaning in smaller range instead of scaning in hole 125,

im looking for address in 125 ? did i say that ?? no bro,, ill show exemple
keysub -p 0233709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e -s -n 2147463600000 -r 0:1f245bd3efe3ab8768efc849659bef11 -o D:\test3994.txt

so here , ill have the address from end range to 120, im searching for closer range by matching same address first 7 digits or hash160.

@kalos, I don't know what you are doing looking for addresses in 125 bit! When you have public key.

But, here let me give you a hint
000000000000000000000000000000001e739ce739cf7bdef7bdef7bdef7be0c

0302157655af8bb1decd37d161aa92cc7050cae1d6b4f44e4aa04507e3c1855159

Add the keys above to each other and tell me what you see.

thats what im doing in 120 and 125 now for months , now im just searching for addresses that matches the range of 00000000000000 or end range fffffffffff to guess the range of 125 bit.. my opinion from lot of calculations, pr of 125 between 30 and 9f.. the a to f range is in the end of keyspace i guess that and i dont know for sure but im trying, now,,

and ,, no digaran thats a bad idea,, you substract only from the public key and try to guess the range by similar first 7 digits of address is the same in range 100 or 80,,, but doing that to find 66,,, no men,, ill run vbcr with 10mkey per second and not substraction of 1 million per 10 minutes and searching,, bad idea, but its good on 125 onlyy ,,, thats is impossible to get lucky and have find address that you now its prvkey,, but its not impossible,, sometimes i do that for fun, but you must be very lucky men

Yeah about that, it's the other way around, we solve the address using EC only, the DLP  part can be solved through public keys and not addresses.

---

I have an idea, why not picking a key from the middle of 66 bit range and start adding and subtracting to it using key subtract in address mode, you never know, you might get lucky and find puzzle 66, at least this way you could adjust start and end range of addition and subtraction, then you could for example, add and subtract 1 million keys to your middle of the range key with this stride "10000000000" and then add and subtract the same to another key, repeat that until you see #66 address, but we have no tool capable of doing that by itself, so you'd have to do addition and subtraction a few million times by hand, but if we could modify key subtractor to do that by itself, it would be great.

I wonder who is a wondering developer around these woods? !!!😉

What do you mean by "windows is closing"?

Also, you can not solve the ECDLP problem using wallet address, because they are a hash of the public key, not the public key itself. Now it is theoretically possible that you break 160-bit space and find a private key that encodes into the exact same address, which can then be used in transactions to fool script verifiers since they only include the address hash in UTXOs. But that's a completely different matter.

guys, windows is closing. we need a new method to solve ECDLP with wallet address only.

And what? What success have you achieved?

Wow, look what I found!  I found it using my phone, I also have another one on laptop.

0399ae0cf361425cbea86fc0c1fecdff5f61ca8a4c4c28a1db891f3d651dc7f00e

Imagine my face when I realized they are both different keys.🤣

I always cut power to 70% and adjust clocks.

Didn’t try without power limits.

I am running DP 32 as well but trailing bits versus leading.

Great work

Your speed test without power limits ?

I make few fixes and now see small speed up.

now  RTX 3070(pl 170w) = 3217 Mkeys/s

I calc only dp32 for #125
https://gcdnb.pbrd.co/images/8QF3YGOUdTJS.png

I figured out that this setting never came to success because random base key is not in set range Anybody have correct code for this setting?

I just noticed, on the third Op post there is a ms windows coming soon! Haven't they come yet @Op? That's some legit viagra they use!🤣

https://mempool.space/address/13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so

No output

At least you guys know your way around explorers somewhat! When I go to one of them, it's like Bob in wonderland. I don't know why is it so hard for them to sort transactions as incoming, and outgoing, but instead they show you 200 other addresses just to inform you that your address has received coins from some other address, well I don't wanna be informed about other transactions of the sending address right away, just show me mine without confusing me with the rest. Lol.

 

OK you're right. A massacre like this blockchain.com is going to the dogs. The graphic design is getting worse, the information is getting less and less... soon you won't even be able to see balance of any wallet :-)

I've seen that sometimes blockchain . com don't show all the TX history, check that address in https://mempool.space/ , they it show TX before November/22 for that address

https://mempool.space/address/bc1q9v5nh4j2pnll47wfuskzdqwymjz2za4czn2rwy