Show Posts
|
Pages: [1]
|
Stride will not help you in address mode, its a simple math, those prime numbers you found in address prefix are irrelevant as a pattern since multiple hashes from private key for generating address would kill any correlation. stride is used to make a collision between a sequential subgroup to a distributed targets based on a pattern, useful in BSGS or Xpoint, like when you use key negation and know the exact distance between targets, then you need to look for a very large prime number that is close to d/n (distance/sequential search(-n)).
for your second question, the Keyhunt behavior is not strange, that's the nature of compress mode, it checks both side of the elliptic curve for any given key.
|
|
|
Thanks for quick response. I believe Xpoint + Stride could solve puzzle 130 much faster than bsgs even if Stride drops the performance of Xpoint. Hopefully you find a way and make some time to implement it for Xpoint.
By the way one of comments above was about Stride combination with Vanity, another guy was talking about it. In my opinion there is no relation between a prime number and vanity search based on the address characters. Multiple hashes happens from private key to generate an address. There is no reason for address to have a correlation with private key in terms of Stride and prime number. Those hashes kill any relation. The only point of having Stride is working with public key to target the X array. Using Stride in any other mode is useless and waste of time. Someone might get lucky using Stride and find the key but based on mathematics, there is no relation between private key and address.
I want to add that having Stride with Xpoint kinda works like Pollard Kangaroo, we can try some prime numbers to find collision between -n value for sequential search and -Stride value. One of them would be wild Kangaroo, the other would be the tame one. Its all about finding good prime numbers. BSGS is not going to work for puzzle 130 even with high end CPU and 1TB RAM. This algorithm is not efficient for 130 bits, someone need to get extremely lucky.
|
|
|
Another question, in github "changelog" you said you added bloom filter for address as well, I thought it was only for bsgs to create hash tables, how does bloom filter can help to speed up the address mode and rmd160.? Also whats the "-z" multiplier in your code? Thanks!
|
|
|
Hi Alberto, I see some Stride development in your code, does it work with Xpoint mode? I got some idea. I tried to flag it with -I 0xprimenumber but it didnt work. Checked some previous github issues, I noticed it used to work with addrsss, rmd160 and xpoint but somehow you shut it down. Would like to see if you can have it back on. Thank you and I appreciate all you have done for this research.
|
|
|
|