hashcat Forum

Full Version: high N scrypt eth wallets - reducing memory usage theory
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
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
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