[ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net

[SpeedDemon13]

question for developer:
if coin supply is 7 billion , 3 minute blocks , ect it seems to me Blake Coin is going to be churning out coins for a long , long time. I looked at your source and cannot tell if the extra award is calculated in this. Thought i saw max size 50 i guess if difficulty gets really large over time.
Is the difficulty subsidy counted in the 7 billion ?
Even if it is I think Blake Coin may be one of the coins with the longest ever production cycle?
(of course SIC simple inflation coin the Russian coin is designed to run forever)
Still that is a lot of coins for a long time.
I am curious why you decided on these amounts & long time span?
Not criticizing your work just curious the logic behind this?

long life cycle sounds great I do want to be able to mine Blakecoin for many many years to come don't you?

7 billion is coin Max, this includes block reward and inflation, I did not see any reason to have a low coin max and artificially create rarity it does not make sense to me  

I picked 7 as it is both a symbol of luck and a prime number  

should not be any cap on reward for Blakecoin, the idea was to create a steady coin supply that did not cut reward for miner over time and to use a fast hash function that would work on CPU/GPU/FPGA without being SHA-256 Asic compatible e.g a new main algorithm

SIC,QRK,YAK do at least try to do something different but the main thing I did not like was that they use a type of waterfall hashing from one algorithm to another which is artificially slow and would not fit in an FPGA and I was working with scrypt in FPGA with kramble's Litecoin miner but due to scrypt's linear function it was clear to me that it could never really take full advantage of the FPGA compared with the speeds of the GPU's.

I have also been working on a free to play 3D MMO framework with another developer since 2011 and thought it would be a good idea if we could use mining a coin within the game while the user was playing, "paid to pay/earn while you play" type of thing but after some research it was clear that the difficulty of Bitcoin was to high and it was not possible to merge mine scrypt based coins.

what was needed was a fast lightweight hash function that did not use too much memory and after some research the candidates where Blake-256, BMW-256, Blake2s all of which are very fast and have as much if not more security than SHA-256.

Blake-256 won for me as it is easy to work with lots of examples on CPU/GPU/FPGA and once I had done a reduced round variant was almost as fast as Blake2s and faster than BMW-256  

Hence Blakecoin was born  

atm still working on the pool stuff am rewriting the block submission function as it has bugs  

once the pool stuff is done I will be working on the blockchain explorer and a merged coin but a kickstarter/crowd funding for the first game title is due for xmas so need some time to work on that as well, it will be the post apocalyptic FPS MMO think Mad Max, Fallout, Diablo.

I feel that Blakecoin has a really good chance at becoming the second largest cryptographic coin for CPU/GPU/FPGA in the world but it might be a little unrealistic to think that it can surpass Bitcoin in the near future but who knows maybe 10 years from now Blakecoin will be number one      

Hope that answers your questions of why Blakecoin exists and what its future is with some background on the design decisions    
  

As long as you keep support for this coin, have useful products and services, I can see it be in the top 10 of cryptocurrency for many years. But first, this needs to have a pool and hit a market, then see how it goes from there.

[1714872774]

1714872774

[1714872774]

1714872774

[kramble]

I stopped mining after 2 days not find a block with 2 x 7970 burning around 520 watts at .32 Kw/h
Just is too much for a coin with 0 value for me.

Something very wrong with your setup. I've been finding an average of 6 blocks per day with my 800MHash/sec Lancelot

My last two logs ...
[6 accepted, 15215 failed] 24 hours
[9 accepted, 19691 failed] 30 hours

Bluedragon:
I've found some python code for blake, got it working to calculate hash and midstate for 8 rounds if you're interested.

[BlueDragon747]

I stopped mining after 2 days not find a block with 2 x 7970 burning around 520 watts at .32 Kw/h
Just is too much for a coin with 0 value for me.

Something very wrong with your setup. I've been finding an average of 6 blocks per day with my 800MHash/sec Lancelot

My last two logs ...
[6 accepted, 15215 failed] 24 hours
[9 accepted, 19691 failed] 30 hours

Bluedragon:
I've found some python code for blake, got it working to calculate hash and midstate for 8 rounds if you're interested.

sure always worth looking at code examples and midstate would be most useful for the proxy as I am using the -nm switch atm

just email it to me  

[kramble]

Bluedragon:
I've found some python code for blake, got it working to calculate hash and midstate for 8 rounds if you're interested.

sure always worth looking at code examples and midstate would be most useful for the proxy as I am using the -nm switch atm

just email it to me  

Will do, it'll also go up on my github once I've integrated it into blakeminer.py (replacing those messy system calls to midstate and checkblake). I'll also drop it into fizzisist's x6500 miner and TheSeven's Modular Python Bitcoin Miner, so we'll be able to support the x6500 and ztex boards with a proper miner. Just need to get the verilog ports working (x6500 is being a real pain, see upthread).

[feeleep]

I stopped mining after 2 days not find a block with 2 x 7970 burning around 520 watts at .32 Kw/h
Just is too much for a coin with 0 value for me.

Something very wrong with your setup. I've been finding an average of 6 blocks per day with my 800MHash/sec Lancelot

My last two logs ...
[6 accepted, 15215 failed] 24 hours
[9 accepted, 19691 failed] 30 hours

Bluedragon:
I've found some python code for blake, got it working to calculate hash and midstate for 8 rounds if you're interested.

sure always worth looking at code examples and midstate would be most useful for the proxy as I am using the -nm switch atm

just email it to me  

I would be also interested - maybe this will help with stratum server code....

feeleep

[kramble]

I would be also interested - maybe this will help with stratum server code....

feeleep

Its this ... pretty much works as is (just change self.ROUNDS from 14 to 8 ), though I needed to add a tiny wrapper for midstate.

I've put it at https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/MiningSoftware/blake_python for now, blake8_test.py shows how to call it. Copyright indicates free usage ...

        Copyright (c) 2009-2012 by Larry Bugbee, Kent, WA
        ALL RIGHTS RESERVED.
       
        blake.py IS EXPERIMENTAL SOFTWARE FOR EDUCATIONAL
        PURPOSES ONLY.  IT IS MADE AVAILABLE "AS-IS" WITHOUT
        WARRANTY OR GUARANTEE OF ANY KIND.  USE SIGNIFIES
        ACCEPTANCE OF ALL RISK. 

    To make your learning and experimentation less cumbersome,
    blake.py is free for any use.     
   
    Enjoy,
       
    Larry Bugbee
    March 2011

[atavacron]

I stopped mining after 2 days not find a block with 2 x 7970 burning around 520 watts at .32 Kw/h
Just is too much for a coin with 0 value for me.

I'm still finding about 1 - 2 blocks per hour with 2 x 7950s and 1 x 7990.

The frequency has slowed now that the Difficulty is 8241.48538182.  Blakecoin must have attracted more miners.

[atavacron]

I would be also interested - maybe this will help with stratum server code....

feeleep

Its this ... pretty much works as is (just change self.ROUNDS from 14 to 8 ), though I needed to add a tiny wrapper for midstate.

I've put it at https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/MiningSoftware/blake_python for now, blake8_test.py shows how to call it. Copyright indicates free usage ...

        Copyright (c) 2009-2012 by Larry Bugbee, Kent, WA
        ALL RIGHTS RESERVED.
       
        blake.py IS EXPERIMENTAL SOFTWARE FOR EDUCATIONAL
        PURPOSES ONLY.  IT IS MADE AVAILABLE "AS-IS" WITHOUT
        WARRANTY OR GUARANTEE OF ANY KIND.  USE SIGNIFIES
        ACCEPTANCE OF ALL RISK. 

    To make your learning and experimentation less cumbersome,
    blake.py is free for any use.     
   
    Enjoy,
       
    Larry Bugbee
    March 2011

Kramble,

I recall you mentioning that you use modelsim for the fpga testing.  In my search for blake code examples, I found the below site.  Note the folder labeled "modelsim" and the multiple SHA-3 candidates at top.  There is a modelsim folder for each.

http://www.iis.ee.ethz.ch/~sha3/blake/

[kramble]

Kramble,
I recall you mentioning that you use modelsim for the fpga testing.  In my search for blake code examples, I found the below site.  Note the folder labeled "modelsim" and the multiple SHA-3 candidates at top.  There is a modelsim folder for each.
http://www.iis.ee.ethz.ch/~sha3/blake/

Yep, its a useful site (shame they have converted all their source code into html, just makes more work to copy it). I've got a project on the back burner to implement Quark hashing on FPGA, which will require pretty much all of those, or at the very least keccak in case someone comes up with a SHA3 coin, wanna be ready to hash from the get-go

Anyway thats OT, so back to modelsim. Those are just build scripts, so are not of much use. Modelsim itself is a commercial product http://www.mentor.com/products/fv/modelsim/ and I'm using the free version bundled with Quartus II for the DE0-Nano fpga dev board. You can download it from http://www.altera.com/products/software/quartus-ii/web-edition/qts-we-index.html Its not really meant for use with xilinx fpgas, but I was familiar with it so just stayed with it rather than learning the xilinx webpack simulator http://www.xilinx.com/products/design_tools/logic_design/verification/ise_simulator_faq.htm

I should have an updated version of the x6500 python miner later today (just finshing off my blakeminer.py mods first). Then I'll have a look the TheSeven's Modular Python Bitcoin Miner (should be trivial to add blake support now I've found some python code). And then I'll make a start on the x6500 debugging.

[mogrith]

Kramble, Sounds like you are having a lot of fun with this. Thanks. (even if I don't have a FPGA )

[kramble]

Kramble, Sounds like you are having a lot of fun with this. Thanks. (even if I don't have a FPGA )

Yep, having a ball. Got to keep those little grey cells busy now I've retired from the world of wage slavery. It wouldn't be nearly so much fun if I was getting paid to do it (though all experience is useful, and there is no knowing where this will go) 

[atavacron]

It is fortunate we have someone like Kramble that is kind enough to explain to FPGA newbs, like myself, the ins and outs of FPGAs as it is applied to crypto coins.  I've been fascinated by FPGAs for some time now and testing the Blakecoin FPGA miner has given me the needed push to dive deeper.  Plus it doesn't hurt to make some coins in the process.  Thanks Kramble.

I'm looking forward to your next bitstream.  As for the last bitstream, I ran "X6500-Robust-v04-2core-fmax-100MHz.bit" for 21 hours with the below results.  Interestingly, the overclock was set to 63MHz but the Run Summary reports a Hash Rate @ ~120MHz.

python mine.py -d 0 -u 127.0.0.1:8772 -w <username:password> --verbose --overclock 63

Code:

...
0 kH/s | 0: 0/2177/0 100.0%/0.0% | 1: 0/2203/0 100.0%/0.0% | 21h47m | xxxxxxxx
midstatehex= aed57a86736a9369d4254d680c1199970a1437c1f834d6c88f9c336901ead826
2013-10-30 11:54:49 | 0: Job data loaded in 0.034 seconds                     
2013-10-30 11:54:49 | 1: Loading new job...                                   
2013-10-30 11:54:49 | 1: Checking for nonce*...                               
2013-10-30 11:54:49 | 1: Writing job...                                       
0 kH/s | 0: 0/2177/0 100.0%/0.0% | 1: 0/2203/0 100.0%/0.0% | 21h47m | xxxxxxxx
midstatehex= 445f08592f53292635592347ffc80f481674dd22851ff9b491216ac76a4cd402
2013-10-30 11:54:49 | 1: Job data loaded in 0.034 seconds                     
2013-10-30 11:55:00 | Exiting...     

Run Summary:                                                                  
-------------
Device: 0
Serial: xxxxxxxx
Number of FPGAs: 2
Running time: 21h47m
Getwork interval: 20 secs
FPGA 0:
  Accepted: 0
  Rejected: 2177 (100.00%)
  Invalid: 0 (0.00%)
  Hashrate (all nonces): 119.14 MH/s
  Hashrate (valid nonces): 0 kH/s
  Hashrate (accepted shares): 0 kH/s
FPGA 1:
  Accepted: 0
  Rejected: 2203 (100.00%)
  Invalid: 0 (0.00%)
  Hashrate (all nonces): 120.57 MH/s
  Hashrate (valid nonces): 0 kH/s
  Hashrate (accepted shares): 0 kH/s
Total hashrate for device: 239.71 MH/s / 0 kH/s / 0 kH/s

[smolen]

I've got a project on the back burner to implement Quark hashing on FPGA, which will require pretty much all of those, or at the very least keccak in case someone comes up with a SHA3 coin, wanna be ready to hash from the get-go

Great! Do you have any back of envelope estimations for amount of LUTs needed?
BTW, Copperlark (heavily premined but still alive) is keccak based.

[kramble]

I've got a project on the back burner to implement Quark hashing on FPGA, which will require pretty much all of those, or at the very least keccak in case someone comes up with a SHA3 coin, wanna be ready to hash from the get-go

Great! Do you have any back of envelope estimations for amount of LUTs needed?
BTW, Copperlark (heavily premined but still alive) is keccak based.

Sorry, at the moment the project is just at a very early stage (I only thought of it a couple of weeks ago when blake got going). I've downloaded the reference HDL (unfortunately its VHDL rather than Verilog so I'm on a steep learning curve there). However looking at the comparisons, all of the SHA3 final round candidates were roughly the same in terms of area implementation (see the image at http://www.iis.ee.ethz.ch/~sha3/), blake and keccak being to the smaller end of the range. In terms of LUTs, the reference implemetations were for a mimimum size, rather than maximizing the throughput. I would expect keccak to work out fairly similar to blake since it actually won the competition (a total guess that!). The simplest blake easily fits on a DE0-Nano (10k LE used for the midstate variant), while my current builds run to about 40k LUT per core on the LX150 (though only two cores currently fit due to routing problems)

Sorry I can't help further, I'll have a better idea once I actually start on the project proper (perhaps in the next few weeks, depending on how the blake work goes).

Thanks for the Copperlark info, I'll take a look at that.

[smolen]

Great! Do you have any back of envelope estimations for amount of LUTs needed?

I've downloaded the reference HDL (unfortunately its VHDL rather than Verilog so I'm on a steep learning curve there). However looking at the comparisons, all of the SHA3 final round candidates were roughly the same in terms of area implementation (see the image at http://www.iis.ee.ethz.ch/~sha3/), blake and keccak being to the smaller end of the range. In terms of LUTs, the reference implemetations were for a mimimum size, rather than maximizing the throughput. I would expect keccak to work out fairly similar to blake since it actually won the competition (a total guess that!). The simplest blake easily fits on a DE0-Nano (10k LE used for the midstate variant), while my current builds run to about 40k LUT per core on the LX150 (though only two cores currently fit due to routing problems)

Keccak have no additions, only ANDs and XORs (and rotations will be eliminated in the synthesis stage), so fully unrolled implementation should have low height and be very fast. Wonder how they managed to squeeze groestl to "roughly the same" size, for GPU miner I wrote code generator to push groestl through AMD compiler. (Keccak and JH were compiled to 32 bit x86 code with -O3, then decompiled back to C and I got all GCC optimizations for OpenCL ). Probably there are some new tricks to learn in VHDL code, thank you for idea!

[kramble]

Atavacron

Sorry, I managed to delete this previous post while quoting from it (probably pressed edit rather than quote), hope you read it first (I was just commenting that the hash rate is correct since we've got two cores per fpga).

I suppose I could do a couple of fixed frequency builds (it really should be working at >100MHz) which will eliminate the initial DCM programming as the source of the problem. Yup, I'll fire up the build machine and get those done now.

I've been running a 100MHz build for about 3 hours now, still not fully routed (899 to go), so I'll leave it run overnight (UK time). Not a bad sign, the earlier builds seemed far too quick, I've put some more timing constraints in place so perhaps this will give a better result. (As an aside, open source code is great, but does not always match the actual code/build parameters used to create the released bitstreams. We developers sometimes like to hold something back. So its not really surprising that the bitcoin x6500 code is not quite as easy to replicate you'd expect )

[bronan]

Well i used both programs provided cgminer and reaper and at first i was getting some coins
However the last week that i mined nothing was being accepted as valid
So if you people can get coins and i don't that does not mean my setup is wrong but others get the coins instead of me

[SpeedDemon13]

Well i used both programs provided cgminer and reaper and at first i was getting some coins
However the last week that i mined nothing was being accepted as valid
So if you people can get coins and i don't that does not mean my setup is wrong but others get the coins instead of me

That's the negative side-effect of solo mining. Someone can mine the same block and solve it faster and/or submit it first. A pool would make it more balanced.

[smolen]

Quick earnings calculator, edit those numbers to match your hashrate and current difficulty and paste it to Calc
Coins/day @ 500 MH/s, 8843 difficulty
500 * 1000000 * 25 * 60 * 60 * 24 / 4294967296 / 8843

[bronan]

I have no clue if its correct but if i would calc what i should get this would be : 4400 * 1000000 * 25 * 60 * 60 * 24 / 4294967296 / 8843
The resulting value = 250,234359073434 coins
But i actually was getting 0,00 coins a day