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

[atavacron]

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 )

No problem.

I got the x6500-miner to load and run the new code.  No rejects, which might be a problem, or blocks so far.  I'll un-comment the debug output and try get an idea if it is working.

I also managed to get MPBM to load the bitstream, point the source to the BLC client (reported correct info such as current diff), and report the blockchain info.  Unfortunately, after what seems like the start of mining, it crashes with a proxy error (I'll rerun it and post the error).

[1713238641]

1713238641

[1713238641]

1713238641

[1713238641]

1713238641

[1713238641]

1713238641

[atavacron]

Anyone getting consecutive orphans?

I haven't got a single orphan until about 12 hours ago.  Now all newly mined blocks are orphans.  I realize that the diff is high but this seems odd.  The diff was much higher, near 10k, a while ago and I had no orphans.  Strange.

[BlueDragon747]

Anyone getting consecutive orphans?

I haven't got a single orphan until about 12 hours ago.  Now all newly mined blocks are orphans.  I realize that the diff is high but this seems odd.  The diff was much higher, near 10k, a while ago and I had no orphans.  Strange.

yeah I got about 6 in past 12 hrs and was not getting them before, gone back to reaper to see it that helps as it does not seem to stress the wallet as much but it is strange 

[atavacron]

Anyone getting consecutive orphans?

I haven't got a single orphan until about 12 hours ago.  Now all newly mined blocks are orphans.  I realize that the diff is high but this seems odd.  The diff was much higher, near 10k, a while ago and I had no orphans.  Strange.

yeah I got about 6 in past 12 hrs and was not getting them before, gone back to reaper to see it that helps as it does not seem to stress the wallet as much but it is strange 

I think I'll do the same.  Of course, it is Halloween.  The Reaper should shred right through the BLC \\\ O~O ///

[trid]

Anyone getting consecutive orphans?

I haven't got a single orphan until about 12 hours ago.  Now all newly mined blocks are orphans.  I realize that the diff is high but this seems odd.  The diff was much higher, near 10k, a while ago and I had no orphans.  Strange.

restart wallet, sometimes happens, i don't understand why

[meta.p02]

Google docs exchange: https://bitcointalk.org/index.php?topic=321823.new#new

Looking for trusted members to help sustain the exchange when I am asleep (in ~8 to 9 hours from now)

[trid]

btw, sent you PM 

[fenix79]

Wallet stop on "blocks" : 12112
Restart does not help

ok it's works now

[melnikalex]

Anyone getting consecutive orphans?

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

[kramble]

I got the x6500-miner to load and run the new code.  No rejects, which might be a problem, or blocks so far.  I'll un-comment the debug output and try get an idea if it is working.

I also managed to get MPBM to load the bitstream, point the source to the BLC client (reported correct info such as current diff), and report the blockchain info.  Unfortunately, after what seems like the start of mining, it crashes with a proxy error (I'll rerun it and post the error).

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.

[110110101]

Anyone getting consecutive orphans?

I haven't got a single orphan until about 12 hours ago.  Now all newly mined blocks are orphans.  I realize that the diff is high but this seems odd.  The diff was much higher, near 10k, a while ago and I had no orphans.  Strange.

yeah I got about 6 in past 12 hrs and was not getting them before, gone back to reaper to see it that helps as it does not seem to stress the wallet as much but it is strange 

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.

[dr_chen]

Anyone getting consecutive orphans?

I haven't got a single orphan until about 12 hours ago.  Now all newly mined blocks are orphans.  I realize that the diff is high but this seems odd.  The diff was much higher, near 10k, a while ago and I had no orphans.  Strange.

yeah I got about 6 in past 12 hrs and was not getting them before, gone back to reaper to see it that helps as it does not seem to stress the wallet as much but it is strange 

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.

The blockexplorer and the pool is too slow to come

maybe this is biggest problem for this coin

[atavacron]

I got the x6500-miner to load and run the new code.  No rejects, which might be a problem, or blocks so far.  I'll un-comment the debug output and try get an idea if it is working.

I also managed to get MPBM to load the bitstream, point the source to the BLC client (reported correct info such as current diff), and report the blockchain info.  Unfortunately, after what seems like the start of mining, it crashes with a proxy error (I'll rerun it and post the error).

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.

Awesome!  I'll try the new x6500 bitstream asap.

[kramble]

Awesome!  I'll try the new x6500 bitstream asap.

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.

[atavacron]

I got the x6500-miner to load and run the new code.  No rejects, which might be a problem, or blocks so far.  I'll un-comment the debug output and try get an idea if it is working.

I also managed to get MPBM to load the bitstream, point the source to the BLC client (reported correct info such as current diff), and report the blockchain info.  Unfortunately, after what seems like the start of mining, it crashes with a proxy error (I'll rerun it and post the error).

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.

Awesome!  I'll try the new x6500 bitstream asap.

I ran "X6500-StaticClock-v01-2core-100MHz.bit" for ~12hours.  The static clock seems to work great.  Below is the result:

Code:

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

2013-10-31 09:32:51 | Device 0 opened (xxxxxxxx)
2013-10-31 09:32:51 | Connected to 2 FPGAs
2013-10-31 09:32:51 | FPGA 0 is running at 100MHz
2013-10-31 09:32:51 | FPGA 1 is running at 100MHz
2013-10-31 09:32:51 | Connected to server
2013-10-31 09:34:32 | 78a54dac invalid!!
2013-10-31 11:08:01 | be880bd invalid!!
2013-10-31 11:56:18 | 7ec2196e invalid!!
2013-10-31 12:18:45 | 1a1d757d invalid!!
2013-10-31 14:25:24 | 45c4fa70 invalid!!
2013-10-31 15:03:15 | 6a17ada3 invalid!!
2013-10-31 15:28:23 | 447f5e9 invalid!!
2013-10-31 15:59:54 | 78352ea invalid!!
2013-10-31 17:32:23 | 3c4347eb invalid!!
2013-10-31 18:02:31 | 1539eae5 invalid!!
2013-10-31 19:38:21 | 31d688eb invalid!!
2013-10-31 20:22:34 | 35dd20e6 invalid!!
2013-10-31 20:38:19 | 775f320e invalid!!
2013-10-31 20:52:24 | 63d15138 invalid!!
2013-10-31 21:15:11 | 35a118b6 invalid!!
2013-10-31 21:44:12 | Exiting... 

Run Summary:                   
-------------
Device: 0
Serial: xxxxxxxx
Number of FPGAs: 2
Running time: 12h11m
Getwork interval: 20 secs
FPGA 0:
  Accepted: 0
  Rejected: 0 (0.00%)
  Invalid: 7 (0.34%)
  Hashrate (all nonces): 199.47 MH/s
  Hashrate (valid nonces): 198.79 MH/s
  Hashrate (accepted shares): 0 kH/s
FPGA 1:
  Accepted: 0
  Rejected: 0 (0.00%)
  Invalid: 8 (0.41%)
  Hashrate (all nonces): 192.52 MH/s
  Hashrate (valid nonces): 191.74 MH/s
  Hashrate (accepted shares): 0 kH/s
Total hashrate for device: 392.00 MH/s / 390.53 MH/s / 0 kH/s

[kramble]

I ran "X6500-StaticClock-v01-2core-100MHz.bit" for ~12hours.  The static clock seems to work great.  Below is the result:

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.

[atavacron]

I ran "X6500-StaticClock-v01-2core-100MHz.bit" for ~12hours.  The static clock seems to work great.  Below is the result:

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.

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

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

Code:

Run Summary:                  
-------------
Device: 0
Serial: xxxxxxxx
Number of FPGAs: 2
Running time: 7h36m
Getwork interval: 20 secs
FPGA 0:
  Accepted: 0
  Rejected: 0 (0.00%)
  Invalid: 2 (0.17%)
  Hashrate (all nonces): 187.04 MH/s
  Hashrate (valid nonces): 146.44 MH/s
  Hashrate (accepted shares): 0 kH/s
FPGA 1:
  Accepted: 1
  Rejected: 0 (0.00%)
  Invalid: 4 (0.36%)
  Hashrate (all nonces): 176.38 MH/s
  Hashrate (valid nonces): 144.08 MH/s
  Hashrate (accepted shares): 156 kH/s
Total hashrate for device: 363.43 MH/s / 290.52 MH/s / 156 kH/s

[kramble]

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

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.

[bzyzny]

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!

[BlueDragon747]

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!

well I am a technical type of guy and not a sales man but will try to give some answers

1. It is not a constant block reward it has inflation which is tiny atm but give it a few years and should be noticeable
2. 1,500 years would be assuming we keep brute force mining and not something like SAT solving to create new blocks
3. The scrypt algo is good for long term storage or password hashing but is awful for block hash guessing, with the blake algo it just takes much less compute to create a block hash guess compared with either Bitcoin or Litecoin so it is more efficient
4. In the future I plan to support Blakecoin in my online games, the idea is you can mine Blakecoin and play a 3D MMO at the same time e.g within the game client then exchange your Blakecoin for game credits to buy in-game content which further helps support the game and Blakecoin or just sell them to help pay your expenses
5. You mine Blakecoin now because you believe it has a promising future and you like its features and you also understand that the difficulty is increasing each week which is a result of more people mining ~ an investment of time and effort which gives Blakecoin value
6. Blakecoin was built by a miner for miners so has a better reward structure and has tried to include many forms of compute while trying to remain fast and efficient
7. after I get the pool and block explorer done I will be trying to create an merged mine coin to increase the reward for the miner when pool mining

I do feel that too many people here are taking such a short term view of Blakecoin it is less than 1 month old atm and many just want to dump it on an exchange for another coin which does make me feel a little sad 

I strongly feel that there is more to Blakecoin than just mining to sell asap but I guess I might be alone in thinking this 

not had the time to really think about exchanges and markets etc.

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    
  

Please Note:

Blakecoin is still new and the supporting software is not as mature as Bitcoin/Litecoin so you might also need some patience while myself and others from the community work on solving the problems, this weekend I will be testing the new rewrite on the pool software hopefully that solves the submission bug if not I will continue to work on it, once it is working the pool software will go on Github.

100% of my spare time is working on Blakecoin and the supporting software but if my development speed is not as fast as you would like the only advice I can give is that you can: wait, work on the solution or find someone to do it for you