Topic: [Bounty] Scrypt-jane CGMINER (Read 7076 times)

bump
https://bitcointalksearch.org/topic/ann-yet-another-gpu-miner-release-yac-232241
 

i dont mind pre-complied for x64 ubuntu, i want to see the feasibility, and considering the money it would make me, i'd be further willing to put 5 BTC for the source code.

Guys, lol, can't you see you're just being trolled? Gold rush sure has struck here.

Adding 200 YAC to the bounty (a small amount for you, not for me), will pay when released. People please add to the bounty or it will go nowhere. ^^

How fast is it? Mine is, with N=128, 4MH/s on a core-underclocked (830->738) HD6990.

I'm afraid it will leak out and kills the difficulty for CPU miners.
Not even sure if I'm releasing it.

+1 willing to donate my time to do some "testing".

wouldnt u like a "beta " tester alongside you?

I'm mining with GPU now, works great.
Testing it for 2-3 weeks for stability, then release.

well people?

Thanks for your tips. Will try tomorrow with pyopencl first. Im proficient python but not C ... so ... if i can somehow by magic get ocl kernel to work... i guess the cgminer side of it should be trivial in comparison.

Can you provide some test data?

i.e. some inputs and known nonce for it? That would be real helpful.

I'm a decent programer but I'm "scared" of looking into openCL because most of my programming is databases, user interfaces, automation etc... not much math involved like all graphics stuff.

What kind of bounty would be worth your time?

Also please don't dump more YAC

I started (late, 8.5 hours after coin launch) with a massive server farm while I modified cgminer, then once that was working, I moved on to the Xilinx implementation.  I just got the Xilinx approach (for N=32, anyway) going last night.  I'll reevaluate whether to bother continuing to mess with it when N=64 tomorrow, we'll see whether Yac exchange rates continue dropping.  N=32 was not difficult on the FPGA, it's really not difficult to pipeline a bunch of 32 bit wide processing stages (as opposed to, say, 1024 bits of data width for Litecoin).  N=64 starts getting a little hairier.



Lots of hints already posted in this thread that'll probably point a fair number of people toward where they need to look.  And if not, perhaps more people will have learned about OpenCL in the process, something they might never have otherwise had the fun of playing with.  I don't need the bounty.  But I'm very curious to see which of the people I gave hints to wins the bounty first, or if someone else that already modified cgminer comes forward to collect the bounty.  Personally, I think the bounty is much too low though.

Actually, most of all, I'm curious to see the hash rates the other implementations achieve(d).  I didn't spend a lot of time optimizing, I moved straight on to writing Verilog for the FPGA attempt.

I thought you were on FPGA bro, not GPU.

mind sharing the knowledge

And even in that case, the power consumption difference is massive

 

Yes, N is hard-coded in the OpenCL source for scrypt(1024,1,1) for Litecoin.  N changes so slowly for Yacoin that you might as well hard-code it as well.  Or #define N to be 32 at the top of the OpenCL file so you can change it to 64 tomorrow with a single line tweak when N=64.  In the long run, to automate this, I'd just modify the cgminer source to read in the .cl file, modify the #define line with the appropriate value of N, write it back out to another .cl file, and use that .cl file as the source for compiling the OpenCL program.

Remember to change the hashing algorithm in the main cgminer source first, since it needs to check the hashes.  If you get it working correctly with cgminer doing CPU mining, and the shares are being accepted by, say, pushpool (or the YAC-modified pushpool over at the yac.dontmine.me pool), you can then move on to changing the OpenCL kernel.  Or solo-mine Yacoin testnet, or make your own genesis block for Yacoin and solo mine off-network with very low difficulty so you can solve blocks quickly.  That way you already have a known-good implementation for the hashing algorithm to check the hashes coming from the GPU.

But where is the "N" going in scrypt130511.cl ? I know for litecoin its something static.

I see this many times in scrypt_core

Is 1024 the N of litecoin and thats being hardcoded in there?

That's what I was thinking, and also a SHA2 hash needs to be changed to SHA3 i believe. The code in that scrypt cl file is tedious to write, but technically trivial code. It's just mathematical operators to follow the algorithms.

Interesting, i assumed scrypt-jane was the algo.

https://github.com/ckolivas/cgminer/blob/master/scrypt130511.cl#L712

By the way is Yacoin mining with OpenCL almost as simple as swaping out salsa with chacha20?