There are many posts lately.
It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ...
I'll start with the conclusions:
- torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method.
- I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written.
Now questions:
- Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on?
- 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical.
And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist
It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ...
I'll start with the conclusions:
- torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method.
- I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written.
Now questions:
- Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on?
- 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical.
And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist
2step gaint
i run under original script 1<<25
5 million used pubkeys
found 2 keys
when checked those 2 keys never used and never in my 5m pubkeys list
repeat run same identical keys
repeat with 1 <<26 , no result
i think something wrong inside script, i mention compelete script only filtered 2 pubkeys which output privkey but never used in my above posts
You are getting false positives which is normal with this version of the code and your big hashtable.
Read recent posts of arulbero in this thread to understand why.
Simplified said there are collisions in the hashtable.
Code:
typedef struct hashtable_entry {
uint32_t x;
uint32_t exponent;
} hashtable_entry;
uint32_t x;
uint32_t exponent;
} hashtable_entry;
Here uint32_t x; is to small too prevent collisions.
If you make it bigger you will also require more system memory. So you have to find a smart way or just verify each found match if it is a true positive.
i have tested it with higher values too, need to of optimization
i created issues inside your pull of bitcrack and modified for random, check that too
if they still have their BTC
