Hello everyone, I have a question about the Large Bitcoin Collider

[ee1234ee]

Why doesn't this project use a completely random method to collide private keys? The method used in this project is private key increment, which I think is incorrect because it is too slow.
I have checked and the project has now calculated this private key
00000000000000000000000000000000000000000000000000a14ed264b00000
The reality is that almost no one's private key has so many zeros, so I think it's a waste of time.
If we change it to completely randomly generate a 256 bit random number private key for collision, the success rate may be higher? Hope to receive everyone's reply, thank you!

[franky1]

to do a random number collider would then need to also keep a database of each number tried to avoid re-trying..
(unlike a incrementor that just needs to store current position to avoid re-trying lower number again)

to store all these random attempts would require alot of space
00000000000000000000000000000000000000000000000000a14ed264b00000 =64 hex = 128bytes

00000000000000000000000000000000000000000000000000a14ed264b00000 = in hex = 45404136789770240 in decimal

so just to store 45404136789770240 attempts so far(if done randomly) would = 45404136789770240 *128byte
= 5811730terrabyte

now you should have some prospective of how many keys are possible if you start doing the math to then see how much data would be used up to log all keys tried

[ee1234ee]

to do a random number collider would then need to also keep a database of each number tried to avoid re-trying..
(unlike a incrementor that just needs to store current position to avoid re-trying lower number again)

to store all these random attempts would require alot of space
00000000000000000000000000000000000000000000000000a14ed264b00000 =64 hex = 128bytes

00000000000000000000000000000000000000000000000000a14ed264b00000 = in hex = 45404136789770240 in decimal

so just to store 45404136789770240 attempts(if done randomly) would = 45404136789770240 *128byte
= 5811730terrabyte

now you should have some prospective of how many keys are possible if you start doing the math to then see how much data would be used up to log all keys tried

I think that if a completely random collision method is used, there is no need to save the private key generated each time, because the probability of generating the same private key twice is not high.
If duplicate private keys are indeed generated, it will not have a significant impact on the collision time and will not waste much time, as it is entirely a matter of luck.
It is more effective than the Large Bitcoin Collider mentioned above.

[MeGold666]

I think that if a completely random collision method is used, there is no need to save the private key generated each time, because the probability of generating the same private key twice is not high.
If duplicate private keys are indeed generated, it will not have a significant impact on the collision time and will not waste much time, as it is entirely a matter of luck.
It is more effective than the Large Bitcoin Collider mentioned above.

There are programs on Github that use random approach you are describing, I had some "fun" with it and the database of all Bitcoin wallets that have more than 10 Bitcoins in it - you can run it as a "free" lottery machine  

I think it was this one: https://github.com/nft30001/lostcoins