Date: Thu, 4 Jul 2013 20:32:45 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Parallella: scrypt Rafael - I'm afraid that you're almost totally confused about this mining stuff. You need to read something on it. I am not very familiar with it too, but I am not quite as ignorant about it. ;-) Question to folks in here who are more familiar with cryptocurrency mining - what would be good resources for Rafael to quickly familiarize himself with Bitcoin and Litecoin? Maybe some pages on the wiki at https://en.bitcoin.it/wiki/Main_Page ? This includes pages on the protocol, etc. I will comment on Rafael's confusion below, but I'd appreciate it if someone more familiar with this reviews my comments and corrects me if I'm wrong about anything. On Thu, Jul 04, 2013 at 04:38:46PM +0100, Rafael Waldo Delgado Doblas wrote: > I will focus on Litecoin integration, OK. I suggest that you spend half a day to play with Litecoin mining as a user first - register with a pool, run some miners. > I would like confirm this: > > Cgminer divides the work between the different host connected to the mining > pool, I think it receives portions of work - so the pool (and not the miner) divides the work. > then it will send keys to be hashed with scrypt and the hash would be > compared with the one that we want to break (normal brute-force attack). No, there's no "hash that we want to break". Instead, we're trying to find such preimage (input to the hash function) that our hash value would be lower than (or equal to, but that's unlikely) the current target: https://en.bitcoin.it/wiki/Target > Once the correct key has been found, There's no one correct key, and there are many possible preimages that would result in sufficiently low hash values. However, yes, any new success at generating a low enough hash value means that a block is found. > it will be shared with the pool in > order to generate the Litecoins that would be shared between the all hosts. Yes. So miners are paid even when they're unsuccessful at generating any blocks (as long as some other miners in the same pool are occasionally successful). Miners also share some proof-of-work even when they're unsuccessful at achieving a low enough hash value to generate a block. They need to do this in order for the pool to credit them for trying - but I am not familiar with this at all. > We are going to use JtR to hash the keys that has been sent to us, compare > the hash with the ciphertext that we want to break and return if is valid > or not. No! Cryptocurrency mining is quite different from how JtR works normally, so there's no intent to use any JtR code for the mining addition to it. You simply take portions of cgminer code and have them invoked when JtR would otherwise terminate. (We'll need to revise the exact condition of when to do this or to skip it later.) > Also Cgminer can work in solo mode Do you mean without a pool? > but I suppose that this not that much interesting Yes. > and in anyway for JtR communication only changes the key set > that we are going to hash. There's no JtR communication. > Then in order to integrate Cgminer with JtR, I need to remove from Cgminer: > scrypt, sha256, fpga,gpu support and any other hash function (since we'll > hash from JtR) and only keep Cgminner's pooling functions. No, that's not right. You need to keep cgminer's optimized and specialized scrypt code (it's deeply integrated with Litecoin mining - there's no scrypt on its own) for CPU and GPU. You may probably drop the rest of cgminer's crypto, as well as its "drivers" for devices other than CPU and GPU, and its support for cryptocurrencies other than Litecoin. The rest of cgminer we might need to keep. The integration will be in invoking it at the right time and with parameters taken from the right place (perhaps from john.conf?) Also, when JtR was using a GPU for password cracking, it's the exact same GPU that should be used for that JtR invocation's Litecoin mining when the cracking has completed. One thing I'm not sure of is cgminer's ncurses interface. We currently have no dependency on ncurses in JtR, so maybe we should exclude that in order to avoid bringing in an extra library dependency. > Then it doesn't matter if Cgminer supports CPU mining or not because this > work will be accomplish by JtR core since we will only use Cgminer to > connect with the rest of the Litecoin network. Wrong. > Cgminer also suports bitcoin then also bcrypt will be needed to a full > Cgminer but since Katja still working on it I will comment any bitcoin > reference for now. Bitcoin has nothing to do with bcrypt. I'll leave it up to you whether to keep cgminer's Bitcoin mining code in the tree integrated into JtR. On one hand, this is a more popular cryptocurrency and more people may be interested in the capability right now, but on the other Bitcoin mining will almost entirely move to ASICs soon(er), where GPUs won't be able to compete (and CPUs already can't). Thus, Litecoin mining on GPUs may have a slightly longer useful lifetime (maybe a couple of years, vs. Bitcoin's a few months remaining - just a guess). Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.