[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130627121440.GA20753@openwall.com>
Date: Thu, 27 Jun 2013 16:14:40 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: scrypt
Rafael -
On Wed, Jun 26, 2013 at 10:49:10PM +0100, Rafael Waldo Delgado Doblas wrote:
> I have done a fork from the magnum repo (
> https://github.com/LordRafa/JohnTheRipper).
I'm sorry I did not comment sooner. Actually, I think doing your work
on top of the core tree is preferable for testing on Parallella, at
least initially, because -jumbo has extra prerequisites and takes ages
to build (although I know you did successfully build it there).
As to integrating Litecoin mining into JtR for end-user consumption,
indeed we need this in jumbo rather than in core - but we need it mostly
for platforms other than Parallella. We're not hoping to achieve good
enough performance on Parallella in absolute terms - at best, it'd be
decent performance per Watt, which will make future generations of
Epiphany (with many more cores) potentially attractive for this purpose
(if they come out soon enough).
Thus, I suggest that you work on two branches:
1. A branch forked from core tree. You may obtain it by forking
magnum's master branch, which you obtain with:
git clone https://github.com/magnumripper/JohnTheRipper -b master
2. A branch forked from bleeding-jumbo. You may obtain it by forking
magnum's bleeding-jumbo branch, which you obtain with:
git clone https://github.com/magnumripper/JohnTheRipper -b bleeding-jumbo
As far as I can tell, right now, the repository at the URL quoted above -
https://github.com/LordRafa/JohnTheRipper - is based on the
unstable-jumbo tree. This branch is a dead-end; we're not developing
anything further on it.
> Also I checked the
> django-scrypt implementation in the host CPU and it gets an score of 1.1
> then 0.7 for the ref implementation looks normal.
These numbers don't mean much without considering the specific scrypt
parameters (embedded in the test vectors). I don't know if your testing
was for the same or different parameters. Anyhow, as discussed before,
the reference implementation is not meant to be fast at all. It's good
for testing of other implementations against it and for learning how
scrypt works.
> Alexander, I have read the log that you send me. I have checked the miner
> that epixoip told you, cgminer, but looks like doesn't have CPU support,
> for CPU support there another one called "cpuminer".
As pointed out in other messages, maybe we need to take an older version
of cgminer.
> Also I saw that there
> a lot of different cryptocurrencys based on scrypt but for now I think that
> it's better focus in one.
Yes, focus on scrypt for now.
> I still needing a road map to start to work.
I understand. At this time, the project is quite disorganized. Sorry
about that.
> 2013/6/26 magnum <john.magnum@...hmail.com>
> > Working in your own repo is probably the best. However, in my opinion you
> > should do a fork of the "master" branch of
> > https://github.com/magnumripper/JohnTheRipper (which is a Git copy of
> > Solar's core CVS and currently almost the same as a core 1.8.0 tarball) or
> > even the "bleeding-jumbo" branch - and then do your stuff from that base.
Exactly - work on forks of these two branches - master and bleeding-jumbo.
Not unstable-jumbo (despite of it being checked out by default at this time).
Thanks,
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.
