[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130704163245.GA14500@openwall.com>
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.
