[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAepdCbZ54FW9xO8FDT-oXvoda_JNU0emSP-u__iOFFsAcYyBg@mail.gmail.com>
Date: Thu, 4 Jul 2013 18:45:39 +0100
From: Rafael Waldo Delgado Doblas <lord.rafa@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: scrypt
Alexander -
Thank you for your help.
> 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 will do that.
> 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.
WOPS sorry it's true, I just meant that in order to integrate Cgminer with
JtR the work would come from Cgminer, but as I have seen below this will
not the way.
> 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.
Thank you, now I understand a little bit better this point.
> 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.)
> 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.
Ok, then the cgminer integration with JtR, Is it just call from JtR to
cgminer?
I don't get what do you mean here: "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."
> Also Cgminer can work in solo mode
>> Do you mean without a pool?
> but I suppose that this not that much interesting
>> Yes.
Yes I read about it but is not useful any more.
> and in anyway for JtR communication only changes the key set
> that we are going to hash.
>> There's no JtR communication.
When I said communication I meant, the communication between JtR code with
Cgminer code because I thought that we will use JtR to calcule the hashes.
> 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).
WOPS. sorry I mistook bcrypt with SHA-256 forget about I said.
Alexander
2013/7/4 Solar Designer <solar@...nwall.com>
> 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
>
Content of type "text/html" skipped
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.
