Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Evillo]

Hello
I found this "puzzle" by a student who wondered if it is possible for the keys to be sequential, the answer to this is that it could be possible that a mathematical formula was used for this.

but it is also possible that he only did this:

n=1,256
r(2^n-1))

and then manually modify the values "randomly", It is most likely that he did so.

In short, I would have to investigate with more time, honestly I do not have the computational power to use brute force, but I can give you some statistical advice on this.

1- brute force with large numbers is always better randomly.
I will use the Monty Hall paradox as an example.

Suppose you're on a game show, and you're given the choice of three doors: Behind one door is a car; behind the others, goats. You pick a door, say No. 1, and the host, who knows what's behind the doors, opens another door, say No. 3, which has a goat. He then says to you, "Do you want to pick door No. 2?" Is it to your advantage to switch your choice?



At first the contestant has 1/3 chances, then when the host opens a door and gives you the option to change at first glance it seems that if you would have the same probability but no.

The car has a 1/3 chance of being behind the door chosen by the player. The other door have a probability of 2/3 and not 50%.

This is the reason why at this point in the "puzzle" a random search is always better than staying in a large range.

2- Is human randomness really random?

playing with some statistical algorithms I made calculations that are close to the range where there is a greater probability that the private keys are found.

Pn-                 range                                  found
65-     30580000000000000000         30568377312064202855
66-     61230000000000000000
67-     137500000000000000000
68-     266900000000000000000      
68-     459400000000000000000
69-     520700000000000000000
70-     978700000000000000000        970436974005023690481

Given that the range of the puzzles 65 and 70 of the formula that I use are close to reality, by statistics the ranges 66, 67, 68 and 69 exist the probability of being close to the real result.

if the puzzle creator made manual changes pretending randomness or disassociating from 2^n-1 , he fail because humans are bad at it.
we always tend to repeat sequences unconsciously by association.

exercise:

If I ask you to read 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25 and quickly I ask you to say a color without meditating or thinking.
The most likely thing is that you chose the color: "answer at the end of the comment" (don't cheat, just say the numbers and say the first color you think of quickly).

my opinion

I don't know what is the reason for this, it's my first approach to bitcoin, but if the creator is rich enough to do it because I don't just take addresses like mine ( 1HUGxcudaxCdufCaYHRoNadeCa73i3hB2r) randomly and send money?
Does he try to test if bitcoin can be hacked? Does he want to encourage the creation of brute force tools?

Personally, I think it would be more likely to find a back door to the elliptic curve used by satoshi than to brute force 256.

In any case, if I were to do this, I wouldn't do it because my resources are basic.

I would use random numbers in a range


I would search for known public keys to maximize the performance of the code by skipping various processes that slow down the search.


I don't know if I'm wrong because this is a new world for me, if I am, please correct me.

sorry for my English.


answer: RED.

That's exactly how i do my pvt key search. Random is the name of the game when it comes to big numbers.

I'm surprised that although you're new to this, most of what you suggested was spot on. In fact, almost summed up the entire experience of this thread. Even the math algorithm part was once a thing to discuss in the early days of this puzzle

[1714639399]

1714639399

[1714639399]

1714639399

[digaran]

And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever.

Won't work, rmd160 has 40 characters and by searching for their prefix, should we stop hashing half way? Meaning converting sha256 hash of public key into rmd160 but only looking for a specific prefix, either we generate the whole hash and compare with our target or we can't generate just a prefix to compare because it would break the function and we wouldn't know the result.

About brute force tools, bitcrack, vanity etc they all convert rmd160 to address, otherwise why would they accept an address as an input to check against?

Say huh?! You have it backwards. Or at least saying it backwards. Vanity takes addresses and converts to 160.
I also believe it converts the partial strings to 160 as well; I’d have to recheck on that but I’m pretty sure it does.

You know I was wondering, when I try to search for 7 char prefix by entering only 7 characters, and by searching for the full address I get the same speed and performance.

Unless programs such as vanity and bitcrack can magically turn 7 characters into a complete rmd160 hash and just search for the hash instead of address, then I can't see a reason as to why searching for full address and 7 char prefix would have the same speed.

According to you those tools decode the address we give them and then only search for the rmd160, decoding the prefix of an address gives no clue about the actual rmd160 hash of said address, therefore they all are hashing the rmd160 twice with sha256 algo in order to find the correct checksum, hence slowing down the process.

[WanderingPhilospher]

And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever.

Won't work, rmd160 has 40 characters and by searching for their prefix, should we stop hashing half way? Meaning converting sha256 hash of public key into rmd160 but only looking for a specific prefix, either we generate the whole hash and compare with our target or we can't generate just a prefix to compare because it would break the function and we wouldn't know the result.

About brute force tools, bitcrack, vanity etc they all convert rmd160 to address, otherwise why would they accept an address as an input to check against?

Say huh?! You have it backwards. Or at least saying it backwards. Vanity takes addresses and converts to 160.
I also believe it converts the partial strings to 160 as well; I’d have to recheck on that but I’m pretty sure it does.

You know I was wondering, when I try to search for 7 char prefix by entering only 7 characters, and by searching for the full address I get the same speed and performance.

Unless programs such as vanity and bitcrack can magically turn 7 characters into a complete rmd160 hash and just search for the hash instead of address, then I can't see a reason as to why searching for full address and 7 char prefix would have the same speed.

According to you those tools decode the address we give them and then only search for the rmd160, decoding the prefix of an address gives no clue about the actual rmd160 hash of said address, therefore they all are hashing the rmd160 twice with sha256 algo in order to find the correct checksum, hence slowing down the process.

VS and KH def convert addresses to rmd160, not 100% sure about bitcrack. I also stated, "believe it converts the partial strings to 160"; you can check the code as well as I can.
Speed is the same unless you add a wildcard, then the speed drops tremendously.
The point is/was, you said, "Searching only for the public key, saves us a sha256 and rmd160 to skip." and I am saying that programs already do that, and some programs search for the rmd160 of an address, if rmd160 matches, the program checks and verifies by completing the complete address generation. So the speed up in programs, whether searching for rmd160 or xpoint, have been out for years.

[_Counselor]

You know I was wondering, when I try to search for 7 char prefix by entering only 7 characters, and by searching for the full address I get the same speed and performance.

Unless programs such as vanity and bitcrack can magically turn 7 characters into a complete rmd160 hash and just search for the hash instead of address, then I can't see a reason as to why searching for full address and 7 char prefix would have the same speed.

According to you those tools decode the address we give them and then only search for the rmd160, decoding the prefix of an address gives no clue about the actual rmd160 hash of said address, therefore they all are hashing the rmd160 twice with sha256 algo in order to find the correct checksum, hence slowing down the process.

VanitySearch checks the full address (i.e. performs full hashing) only if the given prefix matches, and before that it calculates and works with ripe160 only.
I didn't delve into the bitcrack algorithm much, but I know for sure that it decodes given addresses into ripe160.

[digaran]

I have a serious question, why can't we determine the range of a given private key by looking at the derived public key? Why is it so hard? I mean we practically know the range of all private keys and their public keys, I haven't figured it out yet as to why we can't easily map public keys to private keys, it's not magic but only math, even if it was magic we could nullify it. But since it's mathematics I would say all the answers are in "Permutation" equation, other than that there is no mathematic solution. So chop chop dear developers, get to work, we've got mouths to feed.🤣

And even better, what if we can apply the prefix concept on hash160 too. Instead of looking for address prefix, we look for hash160 prefix. Even more speed. In fact, this would be the fastest way ever.

You were actually right about this, I was assuming you were talking about searching for prefix before the hash operation completes, lol. But indeed it would be the fastest method to search for rmd160 prefix because it saves us a double sha256 hash.😉
And don't listen to some developers claiming their tools already do that, because they don't, otherwise why there is no option to set our desired rmd160 prefix? Because they all generate addresses from scratch and either check for a whole address match or for an address prefix, slowing down the process, I think we need some professional devs, these devs are rookies.🙃

[GR Sasa]

And don't listen to some developers claiming their tools already do that, because they don't, I think we need some professional devs, these devs are rookies.🙃

Why don't you then develop one yourself? Lol t's not even hard though.

[WanderingPhilospher]

  And don't listen to some developers claiming their tools already do that, because they don't, otherwise why there is no option to set our desired rmd160 prefix?

Again, the codes already do this.

I know it will be too hard for you to look at VS code on GitHub, or you would have already done it.

Look at keyhunt Cuda. You actually provide it with a list of rmd160s, in binary format, sorted.

If you are merely talking a rmd160 prefix versus full rmd160, there would be no speed up. The full rmd160 is already generated from the public key.

The most time consuming part of address generation is the first step, the actual math part.

[Evillo]

  And don't listen to some developers claiming their tools already do that, because they don't, otherwise why there is no option to set our desired rmd160 prefix?

If you are merely talking a rmd160 prefix versus full rmd160, there would be no speed up. The full rmd160 is already generated from the public key.

I'm genuinely interested in knowing what would happen if we generate the hash160 then ignore the last 30 out of its 40 characters then load only the 10-digit prefix into the bloom filter to look for it against our target h160 prefix(es). Does this only mean less memory used by the blf and that's that?

[_Counselor]

I'm genuinely interested in knowing what would happen if we generate the hash160 then ignore the last 30 out of its 40 characters then load only the 10-digit prefix into the bloom filter to look for it against our target h160 prefix(es). Does this only mean less memory used by the blf and that's that?

Bloom filter works exactly like this. It's a memory-time tradeoff. You can adjust the filter parameters so that it takes less memory, but in this case it will give more false positives.

[WanderingPhilospher]

I'm genuinely interested in knowing what would happen if we generate the hash160 then ignore the last 30 out of its 40 characters then load only the 10-digit prefix into the bloom filter to look for it against our target h160 prefix(es). Does this only mean less memory used by the blf and that's that?

Bloom filter works exactly like this. It's a memory-time tradeoff. You can adjust the filter parameters so that it takes less memory, but in this case it will give more false positives.

Agreed! I did exactly this about a year ago.

The program still completes/computes the full rmd160, but then only checks for x characters against the bloom/file used.

I also did it with x points.

I can’t remember the length of rmd160 prefix but I do remember starting with 20 characters of x point and getting many false positives and slowly shifting the characters up to around 32; so roughly half of the x point, to limit the amount of false positives.

[Evillo]

I'm genuinely interested in knowing what would happen if we generate the hash160 then ignore the last 30 out of its 40 characters then load only the 10-digit prefix into the bloom filter to look for it against our target h160 prefix(es). Does this only mean less memory used by the blf and that's that?

Bloom filter works exactly like this. It's a memory-time tradeoff. You can adjust the filter parameters so that it takes less memory, but in this case it will give more false positives.

Agreed! I did exactly this about a year ago.

The program still completes/computes the full rmd160, but then only checks for x characters against the bloom/file used.

I also did it with x points.

I can’t remember the length of rmd160 prefix but I do remember starting with 20 characters of x point and getting many false positives and slowly shifting the characters up to around 32; so roughly half of the x point, to limit the amount of false positives.

I'm okay with more false positives as it's easy to filter the found.txt file later on. But did it help with the speed at all?

[WanderingPhilospher]

I'm genuinely interested in knowing what would happen if we generate the hash160 then ignore the last 30 out of its 40 characters then load only the 10-digit prefix into the bloom filter to look for it against our target h160 prefix(es). Does this only mean less memory used by the blf and that's that?

Bloom filter works exactly like this. It's a memory-time tradeoff. You can adjust the filter parameters so that it takes less memory, but in this case it will give more false positives.

Agreed! I did exactly this about a year ago.

The program still completes/computes the full rmd160, but then only checks for x characters against the bloom/file used.

I also did it with x points.

I can’t remember the length of rmd160 prefix but I do remember starting with 20 characters of x point and getting many false positives and slowly shifting the characters up to around 32; so roughly half of the x point, to limit the amount of false positives.

I'm okay with more false positives as it's easy to filter the found.txt file later on. But did it help with the speed at all?

No. Just less memory and size of bloom/input file.
You could run a small test using python.

[Evillo]

I'm genuinely interested in knowing what would happen if we generate the hash160 then ignore the last 30 out of its 40 characters then load only the 10-digit prefix into the bloom filter to look for it against our target h160 prefix(es). Does this only mean less memory used by the blf and that's that?

Bloom filter works exactly like this. It's a memory-time tradeoff. You can adjust the filter parameters so that it takes less memory, but in this case it will give more false positives.

Agreed! I did exactly this about a year ago.

The program still completes/computes the full rmd160, but then only checks for x characters against the bloom/file used.

I also did it with x points.

I can’t remember the length of rmd160 prefix but I do remember starting with 20 characters of x point and getting many false positives and slowly shifting the characters up to around 32; so roughly half of the x point, to limit the amount of false positives.

I'm okay with more false positives as it's easy to filter the found.txt file later on. But did it help with the speed at all?

No. Just less memory and size of bloom/input file.
You could run a small test using python.

So fundamentally useless. I would normally increase the bloom filter size and memory and get same speed and way less false positives by using the entire 40 hash160 characters. No wonder everybody loves keyhunt and keyhunt-cuda. I wish there was keyhunt-ocl as well though .. there is one on github but it's not passing my tests

[zahid888]

Here is the result of "masked with leading Zeros" from block no. 0 to 780075 all txhash and merkleroot

BTC p2pkh comp:         
1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE
000000000000000000000000000000000000000000000000000000000003080d
0000000001501e77ebe300537830324cfdc73d879c9e1d6d7621753cbcbb080d

BTC p2pkh comp:         
1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE
000000000000000000000000000000000000000000000000000000000003080d
00000000002e77a33471fb2c764baa29e672ccc15d68814f16ca8d9668d3080d

BTC p2pkh comp:         
1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w
000000000000000000000000000000000000000000000000000000000005749f
00000000000007059f7a8a49f40d8cac4a886bdcb0da9d5628c612755e19749f

ETH:                   
0x72dcf3d75a533042d18a71bb8c3108886ffde045
0000000000000000000000000000000000000000000000000000000000028625
00000000000002119baf977bcf56fd6a33594eb163025ae07cf25fa372908625

BTC p2pkh comp:         
1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum
00000000000000000000000000000000000000000000000000000000000d2c55
000000000000041d6a29dbdbd3934a1fb4ddd81f3dd9a222f86d7bae1a852c55

ETH:                   
0x72dcf3d75a533042d18a71bb8c3108886ffde045
0000000000000000000000000000000000000000000000000000000000028625
000000000000001e114cdfc1d0d2f926af9209bfaf837b0862c92837130e8625

BTC p2pkh comp:         
1CfZWK1QTQE3eS9qn61dQjV89KDjZzfNcv
00000000000000000000000000000000000000000000000000000000002de40f
000000000000001bb4124c32cd6127339c2173186c972975feeb7a67a24de40f

BTC p2pkh comp:         
1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE
000000000000000000000000000000000000000000000000000000000003080d
000000000000000002f81cfc4fd3976180041d7799944e25299085cec909080d

BTC p2pkh comp:         
1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w
000000000000000000000000000000000000000000000000000000000005749f
0000000000000000032962504eef195c863244417d119faa192650b97b95749f

ETH:                   
0x5f8e7b474584864822f6dea4a86e3519a12bbfb0
0000000000000000000000000000000000000000000000000000000000753951
000000000000000000b1ac7afde377d03c031ea2212ceb3a367687f725b53951

ETH:                   
0xbeee2516a81eba11fd7a51b3de2c3351210a7079
00000000000000000000000000000000000000000000000000000000000d2c82
000000000000000000bcd59c52ac5b51f93e67c4ae540ef3035bba451c252c82

ETH:                   
0x91c1a55b48b1d2e851f87e24b53e6dc4f5949497
0000000000000000000000000000000000000000000000000000000000099178
00000000000000000029682ddf4c66d25d49497a94a4fc975fb22086e5419178

ETH:                   
0x72dcf3d75a533042d18a71bb8c3108886ffde045
0000000000000000000000000000000000000000000000000000000000028625
00000000000000000009551c8d5c8036e44486bee3d9ac4d2fe1804026a68625

ETH:                   
0x91c1a55b48b1d2e851f87e24b53e6dc4f5949497
0000000000000000000000000000000000000000000000000000000000099178
00000000000000000009721151134dea640b06d63d77e0d5a243810e91619178

ETH:                   
0x72dcf3d75a533042d18a71bb8c3108886ffde045
0000000000000000000000000000000000000000000000000000000000028625
00000000000000000002598837d00d0c0c465585d7af2b6cdc140bb629528625

BTC p2pkh comp:         
1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w
000000000000000000000000000000000000000000000000000000000005749f
0000000000000000000b75f426fed21131848471bc91acf3c204ac9c47e1749f

LTC p2pkh comp:         
LgHVBRXpioMogLiCRejQjDx4rP1TH49p2z
00000000000000000005cd70209521335307760481e7ca9c4f36ab77e8baa1fd
00000000000000000005cd70209521335307760481e7ca9c4f36ab77e8baa1fd

BTC p2pkh comp:         
1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w
000000000000000000000000000000000000000000000000000000000005749f
000000000000000000099ca3d31399c1f34343eff91d6e1dae5509ea4a75749f

BTC p2pkh comp:         
14oFNXucftsHiUMY8uctg6N487riuyXs4h
00000000000000000000000000000000000000000000000000000000001ba534
0000000000000000000778b806a545e1b78546594cb49e727e2ef5dc18cba534

BTC p2pkh comp:         
1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum
00000000000000000000000000000000000000000000000000000000000d2c55
d75be823f1db85a10485bfac62442ccca727abf98171afcee441d08652b52c55

BTC p2pkh comp:         
1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w
000000000000000000000000000000000000000000000000000000000005749f
e5cfd1e062c7f83618ec45fd4cafcbd2015ae3995d5ef2c163c26fce1789749f

BTC p2pkh comp:         
1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum
00000000000000000000000000000000000000000000000000000000000d2c55
11b1a56d2121a83ebac899a7b2c04610242446f4ec889e5ca7247a33e5a52c55

BTC p2pkh comp:         
14oFNXucftsHiUMY8uctg6N487riuyXs4h
00000000000000000000000000000000000000000000000000000000001ba534
5baabedf0c492543243ac11c86033694d26a7846dd11af42f3b15dc8e8aba534

ETH:                   
0xbeee2516a81eba11fd7a51b3de2c3351210a7079
00000000000000000000000000000000000000000000000000000000000d2c82
c3acbff9152c9682e3689cf4b856ea7ab4a50576aac9e64aeed270c713e52c82

BTC p2pkh comp:         
1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE
000000000000000000000000000000000000000000000000000000000003080d
4f2ae571dc5c41719bb04ac4eb604a09d07d5e4313326546b0cf7f892da5080d

ETH:                   
0x72dcf3d75a533042d18a71bb8c3108886ffde045
0000000000000000000000000000000000000000000000000000000000028625
1421fdec8e0603f4142e66c887e3acaaad871b8f4ea72706bf5943cdd5c28625

BTC p2pkh comp:         
1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum
00000000000000000000000000000000000000000000000000000000000d2c55
0eae2bf5a5747ba301b2f6f185fbe39bab5d583a63938597be5e2398dec52c55

ETH:                   
0x666e2a132fa74ab6de9981f5f397bd6267e9c1fe
0000000000000000000000000000000000000000000000000000000000284e14
01a16171d6b11e7e5845dbfdf311d23d51a1ac2aec560dc968b3a502bd084e14

BTC p2pkh comp:         
1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE
000000000000000000000000000000000000000000000000000000000003080d
69a52a784691c29806dbabe3663c8332e62ceea37b5f1837995cf9fd8595080d

BTC p2pkh comp:         
1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE
000000000000000000000000000000000000000000000000000000000003080d
507ee33b116c19a14bd346de0a7efeec625b9ee151b9d7daba7fa15d0731080d

ETH:                   
0x72dcf3d75a533042d18a71bb8c3108886ffde045
0000000000000000000000000000000000000000000000000000000000028625
45031d630245eb9f6e73d863bfd4a146e1823e7a68e157d39fe566f644fe8625

ETH:                   
0xbeee2516a81eba11fd7a51b3de2c3351210a7079
00000000000000000000000000000000000000000000000000000000000d2c82
26b1b6c45584237b56682c988959edb3376aab7bcb365529418060805abd2c82

ETH:                   
0xc222cc70dc8c96f9f6d19536a3871dce29baac40
00000000000000000000000000000000000000000000000000000000001befac
354f42a7ba3a0f0f8140017146be13de5edd2b800d8c1f2b4a97d5b5060befac

ETH:                   
0xe504a7b4eb7e154e1751b865d401644927501e21
f6bacd87385f9f4962beda1b824546ca2d34825a50cce96ab89a3981341d4e59
f6bacd87385f9f4962beda1b824546ca2d34825a50cce96ab89a3981341d4e59

BTC p2pkh comp:         
1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE
000000000000000000000000000000000000000000000000000000000003080d
0d8464a34309db803e581186ea5443ecdd50a0e1e3174cfc309e5a0b6f73080d

ETH:                   
0x72dcf3d75a533042d18a71bb8c3108886ffde045
0000000000000000000000000000000000000000000000000000000000028625
e238628829dbbd3827b8b7f9744b015ef122e7377b21a75267d2919db91a8625

BTC p2pkh comp:         
1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w
000000000000000000000000000000000000000000000000000000000005749f
af10d598e4ce926bc2ea085cd924506ad15c1822381507c42b606b863199749f

ETH:                   
0xbeee2516a81eba11fd7a51b3de2c3351210a7079
00000000000000000000000000000000000000000000000000000000000d2c82
65bf26540796921c67db1dbceda8fdf91e4e42c1c771e26aac855247a8ad2c82

BTC p2pkh comp:         
1CfZWK1QTQE3eS9qn61dQjV89KDjZzfNcv
00000000000000000000000000000000000000000000000000000000002de40f
1612f274cb765356e3630bef1f9d9b08395a026d68065692d0a90cd8f34de40f

[digaran]

Again, the codes already do this
I know it will be too hard for you to look at VS code on GitHub, or you would have already done it.

Look at keyhunt Cuda. You actually provide it with a list of rmd160s, in binary format, sorted.

If you are merely talking a rmd160 prefix versus full rmd160, there would be no speed up. The full rmd160 is already generated from the public key.

The most time consuming part of address generation is the first step, the actual math part.

Where is this keyhunt cuda? You mean the one you removed from your repo? Well I have been looking for any length  prefix finder for rmd160, now you are telling me that my mentor had this tool all this time?🙂 please release the offline cuda version🥳.

Btw, what is this Zahid dude doing around these woods? You guys think we should get him some medical help? Lol I mean what are you doing man? Goose chase? 😅

[WanderingPhilospher]

Where is this keyhunt cuda? You mean the one you removed from your repo? Well I have been looking for any length  prefix finder for rmd160, now you are telling me that my mentor had this tool all this time?🙂 please release the offline cuda version🥳.

No it was not a rmd160 prefix finder, it searched for full rmd160.
That particular one was archived because it was programmed specifically for a #64 pool we were running.

Also, Zahid is no more on a goose chase than you are with this whole rmd160 prefix finder 😂

At least he is trying something and doing it on his own.

There is no time trade off with rmd160 prefix, just a memory/input file size trade off.

[digaran]

Where is this keyhunt cuda? You mean the one you removed from your repo? Well I have been looking for any length  prefix finder for rmd160, now you are telling me that my mentor had this tool all this time?🙂 please release the offline cuda version🥳.

No it was not a rmd160 prefix finder, it searched for full rmd160.
That particular one was archived because it was programmed specifically for a #64 pool we were running.

Also, Zahid is no more on a goose chase than you are with this whole rmd160 prefix finder 😂

At least he is trying something and doing it on his own.

There is no time trade off with rmd160 prefix, just a memory/input file size trade off.

First of all ouch! Secondly, doing things on our own will never work, team work efforts is the answer, that's why it's called a community.
Guess I will have to go for btccollider then.

[Evillo]

Where is this keyhunt cuda? You mean the one you removed from your repo? Well I have been looking for any length  prefix finder for rmd160, now you are telling me that my mentor had this tool all this time?🙂 please release the offline cuda version🥳.

No it was not a rmd160 prefix finder, it searched for full rmd160.
That particular one was archived because it was programmed specifically for a #64 pool we were running.

Also, Zahid is no more on a goose chase than you are with this whole rmd160 prefix finder 😂

At least he is trying something and doing it on his own.

There is no time trade off with rmd160 prefix, just a memory/input file size trade off.

First of all ouch! Secondly, doing things on our own will never work, team work efforts is the answer, that's why it's called a community.
Guess I will have to go for btccollider then.

LBC was once great, but now It's abandoned 👋 i think if we can revive it nowadays we could reach over 1k TN keys / per 24hs (out of 36+ million TN keys in the puzzle 66 range lol)

[PawGo]

The GPU max Memory available is some 32 GB in some high end devices.

A100 has 80GB, but as memory usage is not linear, it does not really matter. GPU is not a magical tool which would solve any problem any time. Especially when we talk about memory usage - in case of GPU you CANNOT use memory as a simple storage as it will affect your performance a lot. There is probably somewhere a golden rule, between the same algorithm on CPU and on GPU, but definitively it does not work like "just give me more RAM".
BTW, GPU may use host RAM directly, so build-in RAM is not really a limiting factor. All depends how it will be used, as latency could be killing the performance.

[albert0bsd]

BTW, GPU may use host RAM directly, so build-in RAM is not really a limiting factor. All depends how it will be used, as latency could be killing the performance.

Thank you for the clarification, i want to have the same experience like you for GPU topics, it will be soon I hope.

Regards