Thanks, after thinking a bit it's not a significant finding. Any even numbered decimal private key will have a factor of 2, so I guess you can forget about all that. I have a small number of 13zb1hQbWV prefixes I've found in the 66 bit space, I will probably keep them to myself until after the puzzle is completed by somebody. 
On another note, I notice sometimes Keyhunt doing strange things like this, even when the range is specified. Any ideas?
root@C.12292023:/app/bitcrackrandomiser/keyhunt$ ./keyhunt -m vanity -v 13zb1hQb -r 3a86ef00000000000:3a86ef10000000000 -l compress -s 1 -t 60 -n 0x10000
Vanity Private Key: fffffffffffffffffffffffffffffffebaaedce6af48a03817636e85556f0d7c
pubkey: 03056b43664b1aabcdb968796a502b1a81a30fbc76d7c46eeadce91d3ff11405c4
Address 13zb1hQb4i7T18v37e9LKwEqx1t7EhcgAd
rmd160 20d45a6a7598570779fd21913bb29777704d0182
Base key: 3a86ef00ab6da0000 7 seconds: ~205 Mkeys/s (205689239 keys/s)
Vanity Private Key: fffffffffffffffffffffffffffffffebaaedce6af48a03817636e82195f2a18
pubkey: 028bca9f9f5fe984858819330afc10a9c80cab1f2a756fda17033f811b20775cea
Address 13zb1hQbUbJxj9ZKag8n2nepFtmzRRSNc9
rmd160 20d45a6a761acbcc30d7a84bad85eb9dfce4286a
Base key: 3a86ef01b25980000 133 seconds: ~205 Mkeys/s (205687449 keys/s)
It's finding private keys to a prefix match outside of the range I specified. Let me know what you think and thanks in advance!
[/quote]
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.
On another note, I notice sometimes Keyhunt doing strange things like this, even when the range is specified. Any ideas?
root@C.12292023:/app/bitcrackrandomiser/keyhunt$ ./keyhunt -m vanity -v 13zb1hQb -r 3a86ef00000000000:3a86ef10000000000 -l compress -s 1 -t 60 -n 0x10000
- Version 0.2.230519 Satoshi Quest, developed by AlbertoBSD
- Mode vanity
- Added Vanity search : 13zb1hQb
- Search compress only
- Stats output every 1 seconds
- Threads : 60
- N = 0x10000
- Range
- -- from : 0x3a86ef00000000000
- -- to : 0x3a86ef10000000000
- Bloom filter for 1 elements.
- Loading data to the bloomfilter total: 0.03 MB
Vanity Private Key: fffffffffffffffffffffffffffffffebaaedce6af48a03817636e85556f0d7c
pubkey: 03056b43664b1aabcdb968796a502b1a81a30fbc76d7c46eeadce91d3ff11405c4
Address 13zb1hQb4i7T18v37e9LKwEqx1t7EhcgAd
rmd160 20d45a6a7598570779fd21913bb29777704d0182
Base key: 3a86ef00ab6da0000 7 seconds: ~205 Mkeys/s (205689239 keys/s)
Vanity Private Key: fffffffffffffffffffffffffffffffebaaedce6af48a03817636e82195f2a18
pubkey: 028bca9f9f5fe984858819330afc10a9c80cab1f2a756fda17033f811b20775cea
Address 13zb1hQbUbJxj9ZKag8n2nepFtmzRRSNc9
rmd160 20d45a6a761acbcc30d7a84bad85eb9dfce4286a
Base key: 3a86ef01b25980000 133 seconds: ~205 Mkeys/s (205687449 keys/s)
It's finding private keys to a prefix match outside of the range I specified. Let me know what you think and thanks in advance!
[/quote]
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.