 Show Posts
|
|
Pages: [1] 2 »
|
|
Drotika:
Bit: 75
Pubkey: 049f6eee498ebd1f4430e9af95e212c365da105b525973b59b17bcf4c4cda3f71da4750479a47af b676ebcc0e7ff10e116c2b810c173f602ae0d95602b1a26fd2c
Pubkey (compressed): 029f6eee498ebd1f4430e9af95e212c365da105b525973b59b17bcf4c4cda3f71d
Address: 1DdM6MipUFcHADvxSjg2NvNvDj4eU9Y7sP
Address (compressed): 1HzpRSSBdpgFBwq2P7a8fvAssVimy9d3RP
Sorry, but 75 bit is easy with pollard kangaroo
|
|
|
|
Drotika:Bit: 75 Pubkey: 049f6eee498ebd1f4430e9af95e212c365da105b525973b59b17bcf4c4cda3f71da4750479a47af b676ebcc0e7ff10e116c2b810c173f602ae0d95602b1a26fd2c Pubkey (compressed): 029f6eee498ebd1f4430e9af95e212c365da105b525973b59b17bcf4c4cda3f71d Address: 1DdM6MipUFcHADvxSjg2NvNvDj4eU9Y7sP Address (compressed): 1HzpRSSBdpgFBwq2P7a8fvAssVimy9d3RP Sorry, but 75 bit is easy with pollard kangaroo Solution decimal sha256: e8531e693f811079be9a236450c342281e2e0b2a069a5aea2a7593b0062b222b (under linux: echo -n <private_key_integer_base_10> | sha256sum)
|
|
|
|
Drotika: you can give me proof and solve the puzzel what i made for you with this tool what you sell.
i generate a 74 bit address tell me the priv key and i will buy instantly.
here is the compressed pub key.
02860383bb423be58e05694974bd9f509f6cf9d003c16360c1062cc417acd4270c
compressed address:
1NfQBC3hcwugx4fFjkp6ugNC8ZmYGddMz
This might be a sockpuppet account. So catpatkany might be same person as drotika. So be careful guys! If a mod could check this (IP?) please. Looks shady. |
|
|
|
thank you view profile good luck To anyone who considers buying this: Generate a public key with the private key in the 75 bit range and ask drotika to give you the private key for this public key. Regards |
|
|
|
#80: 0xea1a5c66dcc11b5ad180
#85: 0x11720c4f018d51b8cebba8
#90: 0x2ce00bb2136a445c71e85bf
#95: It wasn't me
#100: Also not me
Nice. What software/script and what hardware did you used? What are the costs? Thanks! Pollard kangaroo on gpu. No costs. Just out of curiosity, implemented in C or Python? I see there is a discussion how many kangaroos is optimal, any conclusions from your side on this question? C++. Single threaded 4 to 5 (but probably hardly matters). You increase your chances to hit a sweet-spot but spread speed over the kangaroos. So it compensates. To parallelize: as many as needed. Ratio 1:1. |
|
|
|
|
Sorry I won't release source code at this point in time.
As I am out of the game I want to say thank you to the creator of this puzzle. You had a good timing for revealing the public keys for us! Hope the next solvers will be lucky and grateful too. I will donate a good amount of the BTC I found for good purposes. Regards.
|
|
|
|
#80: 0xea1a5c66dcc11b5ad180
#85: 0x11720c4f018d51b8cebba8
#90: 0x2ce00bb2136a445c71e85bf
#95: It wasn't me
#100: Also not me
Nice. What software/script and what hardware did you used? What are the costs? Thanks! Pollard kangaroo on gpu. No costs. |
|
|
|
|
#80: 0xea1a5c66dcc11b5ad180
#85: 0x11720c4f018d51b8cebba8
#90: 0x2ce00bb2136a445c71e85bf
#95: It wasn't me
#100: Also not me
|
|
|
|
|
#75: 4c5ce114686a1336e07
I have a very slow GPU (965m). For 80+ I need better GPU.
|
|
|
|
|
No not bitcrack. It does not work here.
|
|
|
|
Anyone with a fast GPU (nvidia) and linux who can give me ssh for a % share of #85? The system needs to have cuda installed. Private message me please if interested  |
|
|
|
./clBitCrack -d 1 -b 72 -t 256 -p 1024 --keyspace 1ABBCE2000000000:1ABBCE3000000000 -o res61.txt 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
[2019-03-04.19:49:36] [Info] Compression: compressed
[2019-03-04.19:49:36] [Info] Starting at: 0000000000000000000000000000000000000000000000001ABBCE2000000000
[2019-03-04.19:49:36] [Info] Ending at: 0000000000000000000000000000000000000000000000001ABBCE3000000000
[2019-03-04.19:49:36] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2019-03-04.19:49:36] [Info] Compiling OpenCL kernels...
[2019-03-04.19:49:43] [Info] Initializing Ellesmere
[2019-03-04.19:49:45] [Info] Generating 18,874,368 starting points (720.0MB)
[2019-03-04.19:49:49] [Info] 10.0%
[2019-03-04.19:49:51] [Info] 20.0%
[2019-03-04.19:49:52] [Info] 30.0%
[2019-03-04.19:49:52] [Info] 40.0%
[2019-03-04.19:49:53] [Info] 50.0%
[2019-03-04.19:49:53] [Info] 60.0%
[2019-03-04.19:49:53] [Info] 70.0%
[2019-03-04.19:49:54] [Info] 80.0%
[2019-03-04.19:49:54] [Info] 90.0%
[2019-03-04.19:49:55] [Info] 100.0%
[2019-03-04.19:49:55] [Info] Done
[00:02:06] 1152/7536MB | 1 target 109.79 MKey/s (0000000FB6800000 remaining) [ETA 10.23 minutes]
This does not work ETA stays 10min for too long. And the "remaining" never goes below 0000000F00000000 ...
I think that you may have a declaration problem, your "remaining" integer may have been declared as a 32bit integer.
Thanks! It is fixed now. |
|
|
|
@pikachunakapika - to the suggestion regarding the format of presenting the remaining time, I still have a suggestion regarding the PRESENCE of the remaining keys, namely that it should be shown in the form DEC and not HEX. @racminer - I will check it out on cuBitCrack or if the problem is the same. Nevertheless, even if so I think that ten minutes of incompatibility at this stage can be regarded as a tolerance threshold with a slight breath New version shows decimal remaining time. Please git pull as I accidentally push a commit without random seed while testing for the last version. So the last version has always the same random values. [Error] Error detecting devices: CUDA driver version is insufficient for CUDA runtime version
Please where to place Cudart32&64 files?
The above error happens anytime I run the Bitcrack 3.0 and the latest CUDA Driver wouldn't install (always saying system restart is required). Please pikachunakapika Help with solutions...thanks
I guess you are on windows. I will setup a windows machine soon to help you (currently have none). Zielar, can you help him please? Regards |
|
|
|
it does not work. By firing "from scratch" on a clean script for the scope --keyspace 01000000000000000: 01FFFFFFFFFFFFFFF --share 41/160, the estimated time is 1.75 months. Using the --continue file which contains the starting point at half of what I initially set (just: in a situation where 50% of the range has already been scanned) - the counter gives 1.75 months. This is not something here .... since I've scanned 50% ... it can not be that it will take as long as it will last as if I started scanning from now on again The -r option can not be used because it does not work with "- -continue "and not using this option at this level is probably a waste of time. Thanks! Fixed respecting the --continue file. Working on the changes for --continue with -r option now. All changes are in the master branch now and the remaining branch has been removed. |
|
|
|
Rx480 has a limit ... You can't have -t higher than 256.
Oh ... it changes the form of things :-) well ... I wanted better :-) --- Is there someone here who would be able to convert the counting number of scanned keys in BitCrack into a counter showing the number of REMOTE keys to be scanned along with the estimated remaining time to complete? It would be more interesting information than the amount that was scanned. Unfortunately, I do not know the programming language completely, and my knowledge ends at the stage of compiling a ready solution with possible code change in the sources. I would be grateful for such a small addition. Please checkout the branch "remaining" at https://github.com/pikachunakapika/BitCrack. It also includes my changes for random starting points. With -r you get no ETA and remaining count. |
|
|
|
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
Thank your for testing! |
|
|
|
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 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. typedef struct 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. |
|
|
|
Ok.
I have made other tests you may want to look into. I suppose it is better to open issues on github rather than here?
Yes that would be great. I have enabled issues for the repository. |
|
|
|
OK thanks.
The integer read after the -r option seems to be a signed byte, can't go beyond 127 (you get a negative range)
Thanks! Fixed in current version. Nice  I tried this (I am not sure if it does what I think it shoukd ) ./clBitCrack -r 61 -d 1 -b 72 -t 256 -p 2048 --continue hup.txt -o res.txt 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB And this is what I get in my continue file hup.txt start=0000000000000000000000000000000000000000000000000000000000000001 next=00000000000000000000000000000000000000000000000000000004A4000001 end=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 blocks=72 threads=256 points=2048 compression=compressed device=1 elapsed=344463 stride=0000000000000000000000000000000000000000000000000000000000000001 I suppose that in this context, continue file just tell me how many cases I ran .. right? Yes you are right. This is not covered yet. I forgot continuation-file was a thing so this will get fixed with next update too. |
|
|
|
|
