btw - I gather you are down to around 10 secs per "sweep"
Whos's doing 10 second sweeps now? It takes me about 4 minutes each @61,000 c/s. (By sweep you mean one full set of 4 char inputs, right?) I ran a bunch more patterns while I slept. We should have a place to post the failed patterns so we don't repeat others work. I mean rather than cluttering up the thread with long lists. Yes, the problem now is coming up with more variations to test. its just his guess how long we need, i need around 1 min per sweep (creating wordlist and bruteforcing it). OpenCL platform 0: NVIDIA CUDA, 1 device(s).
Using device 0: GeForce GTX 580
Loaded 1 password hash (OpenPGP / GnuPG Secret Key [OpenCL])
guesses: 0 time: 0:00:00:35 DONE (Thu Dec 27 02:35:34 2012) c/s: 418637 trying: 158b4bcf931ebb9af629643fe653e904ee50733d208b64bc9d3262a96df7e437 - aada9f2c829ce479c03a35c35db77e15e3a8dc7634ccf831875b77b9cbf039af |
|
|
|
since u started bitcoind with "bitcoind" and not the one you did built. if you use bitcoind with parameters it changes to a simple JSON request/response tool. for example u could use namecoind -rcpport=8332 -rpcuser=rpcuser -rpcpassword=rpcpassword getinfo to query bitcoind with the namecoind binary. therefore stop bitcoind, uninstall the package u installed (or the old binary if u compiled/copied it on ur own) and copy bitcoind to /usr/local/bin, afterwards restart bitcoind with |
|
|
|
whats $opassword? ERROR: Undefined variable T_LOCAL!
it would'nt make it longer since theres no math in it, just simple strings. it would even be faster since the string is shorter.
Sorry - I should have made it clearer $opassword is the original password (and you can see it is being used along with the hash and some extra salt to rehash so the string is not shorter and of course the number 999 would be changeable). u could do "$password!=$opassword", thats good enough already. "1+1=2" dosnt help much as its static (nonchanging). that would be 64+2+64+1 (password, !=, password, \n aka newline) - 131 keylength which is much bigger than what we do have right now. |
|
|
|
btw - I gather you are down to around 10 secs per "sweep" - now if the script were to have the following addition: for i in {1..999}
do
password=`echo "$password 1+1=2 $opassword" | sha256sum`
done
how much slower would that make each pass? (this is nothing to do with the actual challenge but for inclusion in a distro) whats $opassword? ERROR: Undefined variable T_LOCAL! it would'nt make it longer since theres no math in it, just simple strings. it would even be faster since the string is shorter. |
|
|
|
If you are throwing in the towel then please post a BTC address here (or send me one in a PM) so I can at least throw 1 BTC your way for the time spent on this.
Doh - just as I posted - well glad to see you haven't given up!
Till date i never gave up on something, i dislike to see this happening  "at first it was for the money, but now I just want it to be solved " -- TechMix <-- same applies for me. u can find my BTC address in my signature, ty already (again)! |
|
|
|
|
For those who dont have enough hashing power, u can send me patterns per PM and il test em, if they match u get a portion of the 10BTC (going to distribute it fair to all who helped, including me).
|
|
|
|
"Solve a riddle, guess a 4 char password and add 10 BTC to your xmas stocking!" <-- why not "Solve a riddle, bruteforce a 4 char password with an unknown salt and add 10 BTC to your xmas stocking! )"
All will be revealed in time but I will add now that the title of this topic was not inaccurate. time is of the essence |
|
|
|
Next hint to be posted after 400 confirmations (unless there is consensus here for me to give it earlier).
"Solve a riddle, guess a 4 char password and add 10 BTC to your xmas stocking!" <-- why not "Solve a riddle, bruteforce a 4 char password with an unknown salt and add 10 BTC to your xmas stocking! )" dunno what to test, tested somany pattern. Did you change ${password} too? asking because of the 1p. |
|
|
|
Just woke up again to find that we are at confirmation # 202 so here is the next hint: and we still got tons of stuff to test  this gonna be fun |
|
|
|
Is anyone interested in an address that contains 230 satoshis? It's in an electrum wallet I'm about to delete and can't be bothered to try and salvage them without paying a fee, so if anyone wants them, they can have the wallet and get them!
sure  ty already. Good opportunity to hack around with electrum. |
|
|
|
I was able to copy wallet.dat into my new client. Thanks for the help .3 btc to both of you. ty enjoy ur Bitcoin journey |
|
|
|
For those wondering exactly where I am headed with this concept - it is to ideally present to an end user a list of questions that will be able to then be used to automatically modify the password hashing script to generate an algorithm in a manner that is very secure (on a secured computer of course - more to come on this in the CIYAM Open thread) without too much effort (but the end user's creativity is and will always be the *key* ingredient with this approach). I never said that this would be a trivial matter (or that this is the best solution to the problem) but I hope that this challenge has at least shown that the idea has some merit. Also using this method I am fairly sure that I've now managed to secure all of CIYAM Open's future BTC tx's for an outlay of under 100 USD (shitty old notebooks are cheap here in China - but you should have seen the look on the salesman's face when my wife asked for the WiFi card to be *removed* because "she hates the internet"  ). I think you did read the "Security by Obscurity" wiki entry. At last ur bound to a 64 alpha numeric password which is long enough to not be crackable by a dictionary nowadays (and the future, unlike something drastically changes). Real Security comes by a good Design and not Obscurity, lets take scrypt as example -> scrypt takes compared to other hashing algos very long to complete. Now take a look at Armory for example where a scrypt hash (u define the scrypt parameters) of ur password is your deterministic wallet key. Now if scrypt is broken (there are collisions/attacks possible) then ur whole wallet gets insecure. A good way to take care of it is wrapping/nesting good (not a bad one, there are hashing algos that tell of what input they are generated which would be a major drawback!) hashing algos. Cascascius (Mike) was talking about this too i guess. If you do this the sheer amount of hashes you have to crack is so big that it isnt worth trying and it would be easier to search for a collision. Pls let cryptograph specialist/programers/hackers decide if its safe or not, i see it so often that some dev thinks a hashing way is save and uses it everywhere (i had to fix a hacked system at my company, some stupid dev used base64 to "encrypt" the password) until u see its broken. Therefore picking a good way to Hash ur password and store it accordingly is the key to success. PS: sry for typos, just woke up! |
|
|
|
i'm at 188 shares and 1 orphan now, after modifying source to allow more outgoing connections
u see i just improved ur mining alot Well, now I'm at 20 shares and 3 orphans. Not a huge sample, but.. my conclusion would be that the initial outgoing # is too low. 10 as max is also too low. you should be able to set it up to 20-30. but, most orphans come from the size of the blocks. i did ~250 shares with 2 orphans with a maxblocksize of 10000, essentially making blocks of 5 or 6 transactions... later on I changed that to nothing, so all blocks had just 1 transaction. that also lowered the "GetBlockTemplate Latency" to a couple milliseconds, as can be seen at: http://nogleg.com:9332/static/graphs.html?DayNow I've set it back to a 500kB max block size and am at that 20 blocks w/ 3 orphans. My GetBlockTemplate latency has also increased, though tbh, I don't find that very relevant. It's a good diagnostic for spotting out possible issues, like if you have maxblocksize set to 0 and it's taking half a second, then that's a problem, I guess. That 1/4th or 1/3rd of a second later may matter in 1 out of 500 orphans. The bigger issue would be network slowness & latency. A bigger problem for p2pool than the network as a whole, since most pools will be run on dedicated servers on good networks. p2pool is different, because it has all these people mining w/ many of them on crap connections. For me to make the most bitcoins, then I should make all blocks with 0 transactions, to limit orphans. my block solved w/ maxblocksize of 10000: http://blockchain.info/tx/971d3109bdc197d1bb8d1334896db2235941b1da884081dee9e94df666a37e84i doubt getting 25.5 instead of 25.01 would make up for all the extra orphans that are caused by having transactions included (in p2pool) It seems to me like if you're keen on p2pool, you'd be better off running a private network with a select group of people, rather than losing 5, 10, or 15% of your hashing power due to people with poor connections... or else just set your maxblocksize to 0. ps: i'm changing my maxblocksize back to 0 it depends how "good" the network is, for example: BTC -> 25 connections are good (0% stale so far for me) LTC -> 50 connections to get 70 submited, 6 stale (needs more connections). The Coin got 2 sides, the more connection the more broadcast so send/validate/calc. This may lead to more DOA. so dont use astronomical numbers. |
|
|
|
alright, im pissed of creating wordlists (got 27 now...), going to sleep. cya @ 200 confirmations or later (introducing a new way for meetings? ) ty to all who helped (especially phr33) and ty CIYAM for such a awesome contest. |
|
|
|
F* ME! I wrote it in C and it's taking 1m 57s to generate the full 14776336 pwd set and I didn't even time it to disk as I planned to pipe it. Must be either openssl lib sha256 is pretty slow or I'm just being retarded with too much string copying and mickey mouse code.
I'll happely put it in bold: Python for the win! Kidding aside, it's generally a good idea to use as high level library functions as possible, e.g. in my case use itertools to create and iterate the list, rather than doing things manually. If you have a problem, you can bet someone already had a similar one, AND came up with a quicker solution than you would in 15 minutes Python just happens to have a sh-t load of such libraries. Not only do you get up and running quickly. It also often runs quite fast. (I realize this is the wrong forum to make such a statement. I know Bitcoin mining is not quick enough on a python ref implementation ) my java + JNI (C) stuff was faster my rule for levels: work at the API/level where u fully know what happens, never go deeper. |
|
|
|
yes, for opencl u have to change this typedef struct {
uint8_t length;
uint8_t v[24];
} gpg_password;change the 24 to 64 in both files (current folder and opencl). now its working Looks good! I would still defiantly try that using a key with known password to make sure it really works done, works for CPU and GPU implementation |
|
|
|
this hurts... who is so retarded and sets this? #define PLAINTEXT_LENGTH 32 Hehe. I bet they thought "noone is retared enough to try to brute force more than 32 chars anyway" when they set it As for the open-cl version they seem to have a more legit reason. Probably more restricted data types and more clever packing of data in there to get nice performance. yes, for opencl u have to change this typedef struct {
uint8_t length;
uint8_t v[24];
} gpg_password;change the 24 to 64 in both files (current folder and opencl). now its working guesses: 0 time: 0:00:00:36 DONE (Wed Dec 26 12:44:56 2012) c/s: 409200 trying: 7277b9b8b5034fc4e715be0e9e61bf3aac30cce46396a30b5272d89e19418a61 - eea8eca3d1525375b2091f1760ae69e eea8eca3d1525375b2091f1760ae69e <-- last hash in wordlist which is a bug but dosnt matter. (bug fixed, forgot to fsync it) |
|
|
|
I tested all passwords for 9 different key derivations before throwing in the towel.
Sorry to hear that but as you have been very helpful with this I will be sending you 1 BTC anyway (let me know what address to send to either here in a PM if you prefer). How are the rest of you going - want that hint earlier or happy to wait till until confirmation # 200? i got 7 so far, still got the wordlists waiting seems fine, i need to sleep too, my body is still human |
|
|
|
how did you fix this? google results are unrelated to this problem (or atleast all i have read so far).
good that i dont delete my wordlists so afterwards i can just recheck...
Google is usually good, but sometimes one need to just have a look at the source code. You'll find the gpg plugin implemented in src/gpg_fmt_plug.c I'm sure you will find the length defined there! this hurts... who is so retarded and sets this? #define PLAINTEXT_LENGTH 32 recompiling with 64. edit opencl_gpg_fmt_plug.c too! (defaults to 15, wtf?) compiling done: guesses: 0 time: 0:00:00:35 DONE (Wed Dec 26 12:31:23 2012) c/s: 411250 trying: 7277b9b8b5034fc4e715be0e@a785a10e4399ab30ec56aee3@f30430753b6537 - eea8eca3d1525375b2091f1760ae69e now the opencl stuff is crap (see the @). python stuff: $ python --version
Python 2.6.5 my guess: faster hashing/loops in 2.7 compared to 2.6. |
|
|
|
Has anyone tried to use c to create the dictionary?
i do it in java with JNI mixed. What's your speed? It would take me something like 1 day to write the 14 million combinations there are... 2 seconds to create the wordlist (4 chars) 17 seconds to create all sha256 sums 1.5 seconds to write it down to disk (916MB) Feel free to benchmark the python version on your überclocked machine with blazing fast SSD! i dont have SSD, dislike to loose my data so fast, the reason why it writes so fast is simply the ext4 cache/buffer. real 1m39.336s
user 1m38.058s
sys 0m0.868s
altough this test dosnt seem to be a good benchmark since there are several daemons/VM running. which python version, pypy or python? |
|
|
|
|
Show Posts
