Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 205.

digaran

copper member

Activity: 1330

Merit: 899

🖤😏

Quote from: citb0in on April 13, 2023, 01:36:49 AM

you obviously has a thinking error here.

Prove me wrong! While you don't even know what I'm saying, just show me a private key generated by a wallet from an integer which has a hex representation consisting of only the 0-9 numbers with no A-F characters.

Deep down every thing is 0 and 1, but on the surface things are different, and yet I'm waiting to see that wallet though.

Again excluding only numeral private keys from a bit range has a potential of at least 60% less bit space to search since there are more numeral only private keys than hex only and mixed hexadecimal keys combined. What I haven't figured out yet is how to actually erase such keys completely from the search table in a way that as if they were never existed so the CPU could process the numbers without any hiccups. Maybe working on a code that doesn't allow integers which would result in all numeral private keys, this could significantly reduce the entire bit range of all elliptic curves narrowing down the search space.!😉

Unplugged Taste

newbie

Activity: 18

Merit: 1

Quote from: albert0bsd on April 12, 2023, 03:47:07 PM

Quote from: digaran on April 12, 2023, 02:57:21 PM

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?

In my case (keyhunt) and I think that it is a general case, hexadecimal is only used as output only for "friendly" representation. Internally the program works with decimal numbers a.k.a. "Big number" variable like mpz_t (from libgmp) or Int for (libsecp256k1 library).

So it should be the same performance.

Hi Alberto!
I hope you are doing great!
I posted my 1 BTC lost case at this forum here https://bitcointalksearch.org/topic/m.62070769

I visited your keyhunt options for my issue but since I am not a fulltime programmer I am confused which one is best suited to my identical situation.

I'll gladly share with you 0.1 BTC on recovery of my 1 BTC.

I am in possession of 1 billion public keys. Those public keys have 1 billion private keys which are a sequence like starting private key for instance is 503, 504, 505, 506,..... upto 1 billion added.

I know the start and end range like that in BTC puzzle but its' not perfect like zeros and fffs, I'll not be sharing specifics for obvious reasons.

Plus I know the public key holding the funds. I am convinced that if Kangaroo algorithm is modified to take this 1 billion public keys in some way and find only one private key. Rest is a matter of adding or subtracting around it within 1 billion one can easily reach the private key holding funds.

citb0in

hero member

Activity: 630

Merit: 731

Bitcoin g33k

Quote from: digaran on April 12, 2023, 10:02:21 PM

I was referring to the fact that an example string like "0xd56ff80b2c5aa58670bf455a" is being generated as a private key, and ...

you obviously has a thinking error here. The deterministic wallet is not generating a hex string as a private key. It is generating an integer number. In your example it generated the number 66055669210921708841997387098. The string you specified is just a representation of it as a hex value.

Code:

#!/usr/bin/env python3
number = int(input("Please enter an integer number: "))

print("Hex: ", hex(number))
print("Octal: ", oct(number))
print("Binary: ", bin(number))

digaran

copper member

Activity: 1330

Merit: 899

🖤😏

Quote from: albert0bsd on April 12, 2023, 03:47:07 PM

Quote from: digaran on April 12, 2023, 02:57:21 PM

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?

In my case (keyhunt) and I think that it is a general case, hexadecimal is only used as output only for "friendly" representation. Internally the program works with decimal numbers a.k.a. "Big number" variable like mpz_t (from libgmp) or Int for (libsecp256k1 library).

So it should be the same performance.

I was referring to the fact that an example string like "0xd56ff80b2c5aa58670bf455a" is being generated as a private key, and I haven't seen a wallet to generate a key like this "0x350090156477349068832154" have you? There is always a-f somewhere between the numbers, I am well aware of the inner workings of computers somehow, I was trying to say what if we could remove all private keys with only 0-9 numbers and somehow search the keys with hexadecimal mixed values?

Here is how it could be, not sure how we could translate such complex algorithm for the CPU, since excluding some integers from the math equation could potentially break the function of the CPU. however here it is, if we convert the following hex representations

Code:

1000000000
2000000000
3000000000

into their decimal values we will see

Code:

68719476736
137438953472
206158430208

now let me give you a larger hex, you treat the following as hex, convert them to decimal and then treat the result again as hex to then converting them to decimal, do that until you see a-f mixed with 0-9,

Code:

528216165414251202501294350264944956991007754601639839861203467066178672860939717813863336428545439587781636107076910321618979511602500894461939292687226932251590796958660985476268182103670

what if we could skip searching such private keys? That would decrease the search range by what factor exactly?😉

albert0bsd

hero member

Activity: 862

Merit: 662

Quote from: digaran on April 12, 2023, 02:57:21 PM

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?

In my case (keyhunt) and I think that it is a general case, hexadecimal is only used as output only for "friendly" representation. Internally the program works with decimal numbers a.k.a. "Big number" variable like mpz_t (from libgmp) or Int for (libsecp256k1 library).

So it should be the same performance.

digaran

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?

Evillo

member

Activity: 185

Merit: 15

Two things you should never abandon: Family & BTC

Quote from: digaran on April 12, 2023, 01:32:23 PM

Quote from: Evillo on April 12, 2023, 01:16:46 PM

Saw this while browing old btc threads. Fun fact and completely off topic while our devices are chasing the right keys:

Quote

Woah that https://www.blockchain.com/en/btc/address/1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF?offset=250&filter=6 address is filled with $300 million!

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.

digaran

copper member

Activity: 1330

Merit: 899

🖤😏

Quote from: Evillo on April 12, 2023, 01:16:46 PM

Saw this while browing old btc threads. Fun fact and completely off topic while our devices are chasing the right keys:

Quote

Woah that https://www.blockchain.com/en/btc/address/1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF?offset=250&filter=6 address is filled with $300 million!

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.

citb0in

hero member

Activity: 630

Merit: 731

Bitcoin g33k

Quote from: Evillo on April 12, 2023, 01:16:46 PM

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?

Evillo

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

Woah that https://www.blockchain.com/en/btc/address/1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF?offset=250&filter=6 address is filled with $300 million!

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.

digaran

copper member

Activity: 1330

Merit: 899

🖤😏

Quote from: Evillo on April 11, 2023, 12:55:48 PM

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.

albert0bsd

hero member

Activity: 862

Merit: 662

Quote from: PawGo on April 12, 2023, 09:46:19 AM

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

PawGo

legendary

Activity: 952

Merit: 1385

Quote from: albert0bsd on April 04, 2023, 12:19:07 PM

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.

Evillo

member

Activity: 185

Merit: 15

Two things you should never abandon: Family & BTC

Quote from: digaran on April 11, 2023, 12:38:03 PM

Quote from: WanderingPhilospher on April 11, 2023, 09:09:58 AM

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)

digaran

copper member

Activity: 1330

Merit: 899

🖤😏

Quote from: WanderingPhilospher on April 11, 2023, 09:09:58 AM

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.

WanderingPhilospher

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.

digaran

copper member

Activity: 1330

Merit: 899

🖤😏

Quote from: WanderingPhilospher on April 09, 2023, 07:38:25 AM

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? 😅

zahid888

member

Activity: 272

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

Evillo

member

Activity: 185

Merit: 15

Two things you should never abandon: Family & BTC

Quote from: WanderingPhilospher on April 10, 2023, 08:37:31 AM

Quote from: Evillo on April 10, 2023, 08:11:12 AM

Quote from: WanderingPhilospher on April 10, 2023, 07:52:37 AM

Quote from: _Counselor on April 10, 2023, 07:19:27 AM

Quote from: Evillo on April 10, 2023, 06:41:33 AM

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

WanderingPhilospher

full member

Activity: 1162

Merit: 237

Shooters Shoot...

Quote from: Evillo on April 10, 2023, 08:11:12 AM

Quote from: WanderingPhilospher on April 10, 2023, 07:52:37 AM

Quote from: _Counselor on April 10, 2023, 07:19:27 AM

Quote from: Evillo on April 10, 2023, 06:41:33 AM

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.

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