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

https://github.com/XopMC/CudaBrainSecp/blob/main/GPU/GPUSecp.cu


all you need is there. mod mult, mod add, sha256 and hash160 for cuda.

Please can someone help me to implement private hex key to hash160 in gpu cuda c++? I believe I have found a possible way to eliminate too many checks, leaving the challenge interval 66 to about 27 trillion , please

Just wondering I get on the 125-bit puzzle (BSGS) search using Keyhunt (CPU) 192 Pkeys/s
(using this best test settings on a i7: -t8 -k1024)

How is it doing compared to a decent GPU?

I never claimed to be Satoshi. But my experience comes from running client 0.2 and losing that wallet. Keeping it on topic here. Feel free to go through my post history.

Download from this link early on https://bitcointalksearch.org/topic/bitcoin-02-released-16

Does anyone know a GPU CUDA platform that can process MKEY and CKEY values. Like crackBTCwallet? https://github.com/albertobsd/crackBTCwallet

Lol, weren't you satoshi himself just yesterday? You should already know all the keys of all puzzles!

My estimations are rounded up numbers and they could be inversed/ backwards, since I calculate from greater keys down the bit range, I could be 99.99% off the correct path, I am still working on validating the exact range, though if the puzzle key was out of the 2^125 range, like in 128 bit, I could tell according to my calculations.

The keys and their value representations I provided above are for simplicity, though we could calculate the keys based on decimal values of bit ranges.

For example, we could consider 2^124 as 16 in decimal and 2^125 as 32, we could as well call 2^124  "21" in decimal, I chose to represent 2^124 as 1000 in decimal.

The other miscalculation of mine could be due to the fact that I focus on hexadecimal representation of keys too much, therefore I could have confused the hex characters with their mirror versions, i.e, if we divide "a" by 2, we would get 5, dividing 1 by 2 will result in "e" and depending on each character on the right side of a hex character, the result of dividing them could differ and cause more confusion, which is why I might be off with my numbers.

One thing I have failed so far to figure out, is to subtract a key from another key to land on a rounded key. But my random logic and random numbers stop me from moving forward.😉

*Insert random numbers
*Insert random logic

Puzzle 125 starts with 1A. I understood it

what calculation do you have made

Why there is no activity around these woods? Chop chop people, get to work.
If it helps, I am 99.99% sure that puzzle #125 starts with 1a. I just don't know how could that be of any help other than lowering the bit range, but if there is any secret behind it, do let me know.😉

---

Something to work on. Please do your calculations and tell me if I'm wrong.

2000 (2^125) = 037e2cd40ef8c94077f44b1d1548425e3d7e125be646707bad2818b0eda7dc0151
1700 = (puzzle #125) = 0233709eb11e0d4439a729f21c2c443dedb727528229713f0065721ba8fa46f00e
300 = 0286936a275e6d53bb2b2718c93d8a5aa44f371f6e0300abb73b89dd851d2fbe88
700 = 03ed01ff219ed5c1afc12d991a82e3063ddcee1fd53b46f7cad52a0d87a7112aed
400 = 02a64a0b3739ddccddece6d90407c925717c75467cc8ce46321d73ec2663320130
200 = 0339ddd9a2a1a113c105175e17903c1f72326ff89b109efc8b976cc9916429c9c4
100 = 031f45d50a743e772f27543272ff4aba36da659540af3185907ad08e68ed0eee4f

And here is 500 = 2^123

500 = 020bfc0504a4b3235d065c0d426b8675fcb2c85d6f58275d791b43e1fe44a6db03

0000000000000000000000000000000008000000000000000000000000000000

---

I will leave a quote from gmaxwell here, I don't know whether my calculations are proving the #125 is in the range between 2^124 and 2^125 or not?

@WanderingPhilospher, after our conversation, i decided to brainstorm myself. I have made so many different modifications, but none of them gives a double increase in the speed of a kangaroo.
I tried  jacobian coordinates, tried not to load Y, but calculate it on the fly and much, much more..
Perhaps i misunderstood you and did not double the speed, but doubled the number of DP found?
What do i mean, if for example, 1660super with a grid 88,128 (PL60%) have a speed of 880MK/s, then in your modified version with the same grid you will have a speed of 1600MK/s or same speed 880MK/s but with doubled the number of DP?
Some calculations..
1660super have memory bandwith 369GB/s
Even if just read x,y,dist=96b, do simple additions with this values(just so the compiler doesn't ignore) and save x,y,dist (total 192b of memory operations) than speed 369/192 = 1.92Gb/s  And this without making any calculation over the points
So to be honest, achieving 1600Mk on 1660super with a grid 88,128 is simply unrealistic..

P.S. And as as i say early here one way to double DPs
That is result of normal kangaroo (puzzle #70)
speed = 2^36.54op / 114s = 876MK/s
And that is result of using addition negative coordinate of jump point
1|1 exacly show that solution finded by wildDP and tameDP that are both prodused from negative jump
totaly speed little drop due to calculation of negative jump but DPs count grow
2^36.78op / 84s = 1404MK/s

Is this the private key you were looking for?   3030303030302033303331203330333020333033302033303331203331333120

How can you not know the addresses? After all, you mined them all and their addresses exist on block chain and any explorer, but the main question is, why are you looking for Satoshi's addresses from 2009? This is disappointing.

Wait , are you saying you are Satoshi? Are you familiar with our ancient tradition? We  call it circular gangBJ, whenever a former clan master returns we make him to give all clan members BJ while we stand in a circle.🤣 I hope you have good knees because you'll have to be on them for a while.   Welcome back. Lol

---

No offense to @real_Satoshi.

Lets keep it on topic. For anyone looking to go the Valid WIF method. You can import a massive amount of keys through Bitcoin core using the importwallet command. The import text has to be in a specific format but the address does not have to be correct only valid. BTC core will ignore the address and import the WIF and basically ignores the address. I will give a small sample of a importwallet file. You MUST HAVE A FULLY SYNCED NODE!

5JBWV6pN7wQyxahtDswBuC1iwRpe3ftW2wBYqsEU3XQpqQaT85C 2009-01-18T17:45:44Z change=1 # addr=116Bp1UUknPpRuiwJBhdLmAvbvNitTTkNJ
5JBWV6pN7wMnshciffX9P9pCsy37EGgMwYYY4MMERBb7WXdkVK4 2009-01-18T17:45:44Z change=1 # addr=116Bp1UUknPpRuiwJBhdLmAvbvNitTTkNJ
5JBWV6pN7hGsLCpYUsQ2oSyXbk561q6e9dB5ATD61gziSgL7Yuy 2009-01-18T17:45:44Z change=1 # addr=116Bp1UUknPpRuiwJBhdLmAvbvNitTTkNJ
5JBWV6pM3XYYK71aqHzz3C89zWoj6vGBU4SN6KFzKVAu4cJ32DU 2009-01-18T17:45:44Z change=1 # addr=116Bp1UUknPpRuiwJBhdLmAvbvNitTTkNJ
5JBWV6jceaibTTjxytGnheCnVy1RZiNQqZw5qE4rsJ7n8n75Pwo 2009-01-18T17:45:44Z change=1 # addr=116Bp1UUknPpRuiwJBhdLmAvbvNitTTkNJ
5JBWUjrVNb6ULxoiuA2kQkdvVce1qDsRmkhKEJwyGWMC61JUbRx 2009-01-18T17:45:44Z change=1 # addr=116Bp1UUknPpRuiwJBhdLmAvbvNitTTkNJ

This format compressed or uncompressed will work with WIF imports.

All the keys will import ignoring the address, but you still have to have the address. change addresses are not relevant it will still pickup a added value. The core will skip it and you can watch the real addresses in debug.txt

After import the entire blockchain will rescan. Addresses will be updated to WIF. It takes a few hours. You can do this offline. During this time you can monitor debug.txt in ./bitcoin for any added transactions to the keys you imported.

I think I have done about 20,000-40,000 keys from raw data. Speed is only slightly impaired with a massive amount of keys. The core does have its limits however and anything over 40,000 keys at a time will probably brick it.

I am also sure you could use known addresses to compare and skip this information. In my case I did not know the address I was looking for. It was 64kb of a corrupted wallet of my own from 2009....

That's a lot of old wallets, I mean maybe Satoshi is the only one with more than 20,000 valuable keys, so no, it's not a good idea to involve bitcoin core or any wallet whatsoever, around these woods the residents tend to pick every address with a balance  more than 0.01 ( some go for lower than that ) and input them to whatever tool they use when they search the key space.  Just wanted to tell you that you are doing it wrong, and checking balance has nothing to do with security, you could use a block explorer via api to check for balance.

I guess you are lost and stumbled upon our garden, something tells me you don't even know what this topic is all about. Lol

Assume you possibly have a very old wallet that is corrupted. The wallet is your old wallet and may have a balance. Is it very smart to check for balances online. Use tools online? Or you could sync a full Bitcoin node and import keys to check offline on the full node.

I think offline is smarter and secure. Kind of what Bitcoin is about.

Why would you go all the way to check WIF? You'd first need to generate the public key, hash the private key twice, add checksum and convert to address. That is not how you special people should go about it!

Normal people use BSGS, kangaroo to only look for public key match, rookies like me, we go for add/subtract method, wifsolver is very slow comparing with kangaroo.

And about scanning,  what do you mean bitcoin core can handle 20,000 keys? Do you check for balance in every key you generate? 😳

Sooo long!
Approximately 2 years and 2 months.

You'd better use this:   https://github.com/PawelGorny/WifSolverCuda
There you can search both wif and hex!
https://github.com/PawelGorny/WifSolverCuda/blob/main/docs/examples.txt

As I see this project in python and does not use GPU, how long will it take to recover the lost 9 characters from the example above?

Can you show an example, for example on puzzle 80, by removing the middle part of the key? And how long will this work take?
00000000000000000000000000000000000000000000ExxxxxxxxxC11B5AD180

Basically yes it is the same, But because there are a lot of invalid WIF formats you could print only the valid ones, and then check them for valid keys. I guess if you could output valid keys very quickly and dump invalids even quicker it might be faster then what we are currently doing. Based on hardware limitations that I know about software is much faster at ignoring a input. However with the uncompressed byte being less it may be at least 1 byte less to scan. I guess its just a different way of looking at EC operations from the other end. And BTC core can handle 20,000 plus keys at a time during a scan. I know because I lost my own genesis wallet, and have tested it. And software can ignore something much quicker then process it.

If this helps someone please don't forget the little guy still learning python. And sorry if I sound a little special.

True, but you are just saying that in hex representation key to puzzle 66 is
000000000000000000000000000000000000000000000002XXXXXXXXXXXXXXXX
or
000000000000000000000000000000000000000000000003XXXXXXXXXXXXXXXX

which we already know lol

https://github.com/Mizogg/Tkinter-Power-Mini

WIF HEX DEC Recovery Tools

https://user-images.githubusercontent.com/88630056/207971831-5d34f507-f19a-4659-b731-b27fee75ea35.png