Topic: [ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 175. (Read 409569 times)

Started: [2013-11-01 18:20:17]
 [2013-11-01 20:48:13] New block detected on network
 [2013-11-01 20:52:18] Found block for pool 0!
 [2013-11-01 20:52:19] Accepted 00082789 Diff 8.04K/7420 BLOCK! ICA 0

Just a little luck eh?

YOWZER !!

You're probably best spending your time on the pool and block explorer software as those are the most needed. I've got a volunteer for ztex testing this weekend so we'll see how that goes. If it doesn't work out then perhaps we can come to a "loan" arrangement for the hardware so I can do some hands on debugging (says he cheekily ). I'll take a look at bfgminer, though as you know software is not my particular forte.

I do have a ztex 1.15y and a cairnsmore 1 for testing but not had the time to play with them much 

Yep, I already had 3.1.1 compiled on raspi, so I decided to start with this version rather than the most recent one. The code changes to support blakecoin are actually quite trivial (just a few lines in cgminer.c to change the midstate and hash calculation). Its the driver code that's more awkward to debug (my fault for changing the data protocol I suppose). Not sure how it will go with x6500, ztex etc but I'll give it a try as and when willing guinea pigs volunteers turn up.

I don't see the scrypt FPGAs giving any real advantage over GPUs. Other than the obvious ASIC scams out there, the real FPGA products in the pipeline are coming in significantly more expensive than GPU with the only advantage being lower power consumption. Anyway since this is a little OT I'll just post my current progress in getting cgminer to work on fpga

Blakecoin mining on Lancelot with cgminer 3.1.1 on raspberry pi.


The speed estimates are a bit high (should be 780Mhash/sec) but the WU looks correct. I think the "holes" in the nonce range scanned by the FPGAS are confusing it. Seeing as this is such an old version of cgminer, I don't thinks its appropriate to fork the github so I'll just put the changed files up on mine. You still need to use blakeminer.py or testblakeminer.py to set the clock speed after loading the bitstream. Not yet found a block with it but it'll take most of the day at current diff.

Unlike Quark, Blakecoin offers long term reward for the miners. Soon we'll see how well will Quark do with almost zero block reward.
Unlike Litecoin, Blakecoin doesn't resist to FPGA or ASIC mining, but tries to make the transition as smooth as possible. Again, with upcoming scrypt FPGAs we'll see how Litecoin and clones will manage this transition.

Hello, I've been following this thread for about 2.5 weeks and mining blakecoin most of that time. finally made an account on the forum to post on here. anyways, I was wondering why you made blakecoin and what benefits you see it having. The different algo is obviously a nice change from other alt coins, and the constant block reward is an interesting twist. But I am curious what effect these changes would make in the long term compared to litecoin for example. If my math is right, blakecoin will still be giving out block rewards for about 1,500 years. only reason i can see for this would be to counter the effect of people accidently losing their wallets over time, or to ensure constant incentive for miners. Essentially I want you to sell me on why I should keep mining blakecoin

Aside from the technical aspect of blakecoin's advantages, I was also wondering what plans you have for it such as mining pool (which I see is in the works), market place, etc. Perhaps adding support for blakecoin into PaySwarm would be a good idea. I would be interested in hosting a mining pool if someone could point me in the right direction on how to do this. thanks!

CONGRATULATIONS!!! Now we're cookin'

I've been lucky orphan-wise, all been good other than a couple of bad stretches early on when the block chain forked. Possibly since both BlueDragon and I are in the UK so I've got good connectivity to his seed nodes. Since I'm running blakecoind rather than qt its a bit more difficult to check on orphans, but I found that grepping debug.log for "AddToWallet" and plugging the txid into gettransaction gives some useful info.

PS You may want to drop your getwork interval (--interval argument) from the default 20 seconds as they will be exhausting the nonce range. I run my blakecoin.py at 1 second but 5 seconds would probably be OK for the x6500. Note that the nonces are distributed to the cores according to the top two bits (supports 4 cores), but since only two are instantiated the nonce range is exhausted twice as fast as would be naively expected.

JACKPOT!!!  1 block accepted, not an orphan!  

Running bitstream "X6500-StaticClock-v01-2core-100MHz.bit".

That looks about right. The invalids are nothing to worry about as there are very few and probably due to nonces falling between jobs, I get rather more with my Lancelot build which I'm currently running at 195MHz eg ... 1 accepted, 8364 failed, 87 errors (over 13 hours).

It would be nice to actually see it solve a block, but I guess its just a matter of time. I'll see if I can push the speed up (the aim is around the 200MHz mark but I'll take it a little at a time, especially as I'll probably need to restore my serial data mods to get the higher speeds). As I mentioned these builds can take many hours (and I've got some other stuff I need to build too), but perhaps I'll have one at 150MHz for tomorrow.

I've had a good look through the cgminer code and I'm pretty certain I can get this to run blake ... just a matter of modifying calc_midstate() and rebuild_hash() in cgminer.c plus some changes to the drivers to update the device verification jobs from sha256 to blake. I'll do an initial test with 3.1.1 (since I already have this running on raspi for bitcoin on Lancelot), then look at the current release.

I built a slower one in case that one did not work https://www.dropbox.com/s/326h5k3imt8llcs/X6500-StaticClock-v01-2core-50MHz.bit

I've also updated core/job.py in MPBM https://github.com/kramble/Modular-Python-Bitcoin-Miner/tree/master

I've now got MPBM mining blakecoin with my Lancelot. Seems I just needed to run it on my raspi rather than windows and the admin page works nicely in the Midori browser. As well as the updated job.py it also needed some tweaks to the icarus driver in modules/theseven/icarus as the job data protocol is different for my current Lancelot code, and to disable the device verification check. Something similar may also be needed for the X6500 and ZTEX drivers, though at least the data protocol is unchanged for these.

The blockexplorer and the pool is too slow to come

maybe this is biggest problem for this coin

Interresting to see that the diff is back at 10K right now!
Must be lots of users hashing on Blakes.

I too have been getting orphaned blocks, but this seems to be caused by the wallet getting stuck on an old chain. This is true even with 10+ connections to the network, and I am only mining with 1x7970 and no CPU, so no "power shortage" for the wallet. I was using the patched cgminer by melnikalex.

My solution has been to check in to my box and restart the wallet every now and then. I hope this will reduce the amount of orphaned blocks. A restart and resync every 12h seems to be necessary as the wallet will get stuck at least once a day.

I put the test against network target back in, so it will only submit shares at the block winning difficulty (one in 6526 right now). You can submit all shares by uncommenting line 104 of mine.py. This is probably a good idea, at least until its proven to successfully find a block. To print the hash just uncomment lines 88,89 (also a good idea to check its generating valid hashes).

I haven't made the time to investigate MPBM yet. I just did the quick blake hack, but it won't run properly for me (even without the hack).

A fixed 100MHz clock bitstream is now at https://www.dropbox.com/s/3xkuo97m154v24x/X6500-StaticClock-v01-2core-100MHz.bit - it was an 8 hour build overnight. Overclock won't do anything on this build as I took that code out. I'll do faster (or slower if it doesn't work) versions later, but right now I've got a ztex 1.15y version to build  

OK, the initial ztex test build is up at at https://www.dropbox.com/s/a8tare3wqy5zolb/ztex_ufm1_15y1-v01-1core-80MHz.bit

Its just a single core and clocks at 80MHz (the input clock is 160MHz, I just halve it internally), but it will do for a start. It probably won't work, but as a shot in the dark it may be worth a try. I've done a modified version of MPBM for Blake at https://github.com/kramble/Modular-Python-Bitcoin-Miner/tree/master (NB this is the master branch, the default is Testing if you go there from the root of my github, so you'll need to select Master from the branch drop-down). It runs but the web interface is all messed up on my browser so its a bit awkward. You'll need to disable the default bitcoin pools and add your own blakecoind instead. Unfortunately with diff so high you won't be finding a block any time soon, but the stats will at least show if its hashing.

I'm currently looking at cgminer. The Blake version a few pages back upthread won't work for fpga as the blake code is inserted in the GPU Scrypt driver, but I'll have a poke around with it and see if I can move it somewhere useful. It was a bit of a pain just getting it to build on linux as the zip file was already configured for mingw so I had to start from the official github and just copy over the changed files. These "professional" C/C++ code distrubutions are still somewhat of a mystery to me, eg how would I go about adding a source file to the build process? For the moment I think I'll follow the lead of the hacked blake version and just #include the files directly in the existing source.

I also got only 1:6 rate of good block to orphans for today and yesterday, early there was no orphans at all. Strange