high N scrypt eth wallets - reducing memory usage theory

[Katarnkyle]

I know well the problem of memory cost on "high N" scrypt encrypted ethereum wallets, but this guy in the link below shows there is a very real possibility to reduce N settings by a trick via multipled operations and then allow to use devices for scrypt cracking , which are pretty fast but currently unusable for high N scrypt settings due to memory cost ( GPU, FPGA, maybe even ASIC ). It brings me a theory there could be a way how to significantly speed hashing up of ethereum high N scrypt wallets with Hashcat because of that loop unrolling and reducing memory usage. Even if that method slows classic, current hashing ( with high memory usage ) thousand times, it could be more than equilibrated by the usage of highly paralelized computing devices then. The goal is to use hell fast devices currently unusable for scrypt, getting lower price and time per hash.   https://blog.ircmaxell.com/2014/03/why-i...crypt.html

[Katarnkyle]

Any idea why this feature is not applicable in Hashcat for ethereum wallets? It could indeed move on the ability of Hashcat and help many desperate ethereum users even if that is a "plus" paid feature :-) In this thread is his first note regarding that scrypt issue or a "bug" feature https://www.drupal.org/project/drupal/is...nt-4675994

[hashzero]

Interesting discovery, thanks for sharing. Perhaps you would get more replies adding a feature request over at the github page.



https://github.com/hashcat/hashcat/issues




Or take a look at the code yourself:




https://github.com/hashcat/hashcat/blob/...00-pure.cl




I'd certainly be interested to hear what the experts have to say on it.

[maryLane1409]

Thanks for the good information. Tell me, can I break my wallet on this site redot.com? I don't know a lot about hashcat usage