Author

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

copper member
Activity: 1330
Merit: 899
🖤😏
I was wondering, have you guys ever seen a wallet to generate a private key consisting of only decimal numbers without a single hex character? Well I haven't, and it is the case with only hex chars as well, so is there any way (possible way) to skip brute forcing all hex, all decimal keys and just search through the mixed keys? And what would happen to our search range if we could eliminate such keys, as in how many keys could we skip brute forcing? Isn't that an idea worth exploring?
member
Activity: 185
Merit: 15
Two things you should never abandon: Family & BTC
Saw this while browing old btc threads. Fun fact and completely off topic while our devices are chasing the right keys:

Quote

He seems so surprised about the amount of money that address had back then in 2019. The address he's talking about belongs to Mt gox and is now worth 2.3+ BILLION dollars lol. Nobody has been able to spend a dime out of that address so it practically belongs to no one now.
Show me the public key of that address, I will use Satoshi's super computer to crack it. I'd say that the hacker knows that mixers are rigged and using them would endanger him, however I don't think it's fair to steal from others, that's what coward pussies do, I'm sure the real owners are willing to happily pay 20% as a reward, that 20% would be legit, but no matter what, he has to answer for what he has done some day.

No pub key and not a dime spent. Coz whoever spends from this address will be chased down vigorously.
copper member
Activity: 1330
Merit: 899
🖤😏
Saw this while browing old btc threads. Fun fact and completely off topic while our devices are chasing the right keys:

Quote

He seems so surprised about the amount of money that address had back then in 2019. The address he's talking about belongs to Mt gox and is now worth 2.3+ BILLION dollars lol. Nobody has been able to spend a dime out of that address so it practically belongs to no one now.
Show me the public key of that address, I will use Satoshi's super computer to crack it. I'd say that the hacker knows that mixers are rigged and using them would endanger him, however I don't think it's fair to steal from others, that's what coward pussies do, I'm sure the real owners are willing to happily pay 20% as a reward, that 20% would be legit, but no matter what, he has to answer for what he has done some day.
hero member
Activity: 630
Merit: 731
Bitcoin g33k
The address he's talking about belongs to Mt gox and is now worth 2.3+ BILLION dollars lol. Nobody has been able to spend a dime out of that address so it practically belongs to no one now.

so why many people regularly send coins to that address?
member
Activity: 185
Merit: 15
Two things you should never abandon: Family & BTC
Saw this while browing old btc threads. Fun fact and completely off topic while our devices are chasing the right keys:

Quote

He seems so surprised about the amount of money that address had back then in 2019. The address he's talking about belongs to Mt gox and is now worth 2.3+ BILLION dollars lol. Nobody has been able to spend a dime out of that address so it practically belongs to no one now.
copper member
Activity: 1330
Merit: 899
🖤😏
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)
Not that one, I meant the one from Jean Luc, which could be used to search for rmd160 prefix. About the puzzle 66, if we knew the checksum for it's WIF for example, we could narrow down our search space.
hero member
Activity: 862
Merit: 662

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
legendary
Activity: 952
Merit: 1385
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.
member
Activity: 185
Merit: 15
Two things you should never abandon: Family & BTC
Quote
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)
copper member
Activity: 1330
Merit: 899
🖤😏
Quote
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.
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Quote
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.
copper member
Activity: 1330
Merit: 899
🖤😏
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? 😅
member
Activity: 275
Merit: 20
the right steps towerds the goal
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
member
Activity: 185
Merit: 15
Two things you should never abandon: Family & BTC
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
full member
Activity: 1162
Merit: 237
Shooters Shoot...
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.
member
Activity: 185
Merit: 15
Two things you should never abandon: Family & BTC
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?
full member
Activity: 1162
Merit: 237
Shooters Shoot...
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.
member
Activity: 110
Merit: 61
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.
member
Activity: 185
Merit: 15
Two things you should never abandon: Family & BTC
Quote
  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?
full member
Activity: 1162
Merit: 237
Shooters Shoot...
Quote
  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.
Jump to: