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

After hours of trying to compile the client on a clean Debian, I gave up on this:

Also, because I updated everything, I get this error trying to run the binary:

Nice very nice thank you kramble you are a star 

I have just pushed my FPGA miner code up on github https://github.com/kramble/FPGA-Blakecoin-Miner

Its very early in development (and the code is still a bit of a dog's breakfast), but I think its good enough to share now.
Performance is 44MHash/sec on a dual-LX150 Lancelot board, though there is a lot of scope for improvement.

The code is based on my existing litecoin miner code, so the discussion at https://forum.litecoin.net/index.php/topic,5162.0.html may be of interest. The original framework is fpgaminer's (plus contributions from teknohog and others).

The BLAKE engine is based on code from http://www.rcis.aist.go.jp/files/special/SASEBO/SHA3-ja/BLAKE.zip which quotes a free
license for research purposes, see http://www.rcis.aist.go.jp/special/SASEBO/SHA3-en.html
This code was used as its written in verilog, whereas the reference implementations are in VHDL which is just gobbledygook to me.

I'll get a bitstream up shortly for anyone who wants to test. You'll need a Lancelot board, Xilinx platform cable (or clone) for programming, plus a huge download of the Xilinx ISE software (no licence needed just to run the IMPACT programmer, but LX150 compilation requires a free 30 day evaluation license).

I'll put together the Altera version later (I did my original code on a DE0-Nano as Quartus is much nicer than the Xilinx toolchain).

same could be said for any cryptographic hash function that why there are so many papers and competitions on the subject  

I would love to see a SAT miner but have only seen a test case on Bitcoin for a few blocks and it was slower than bruteforce

Through great efforts I think I finally exposed my client's port through 3 NATs I'll report if this solves anything.

out of the 8 machines I have only 1 has shown any de-sync but others have reported same issue so when I get time will look into it 

If the 8 rounds version uses the same computing and memory footprint but less time, then it is a valid choice, if of course it is just as good or better than SHA-256.

Just remember that you get a reduced internal set size and entropy compared to the bigger rounds versions, and not only it is easier to bruteforce but there also possible future SAT, pre-image or constructed hardware attacks. While the reduction looks to be linear, we don't know if it won't be logarithmic (2^(14-8) faster instead of (14-8)/8 faster) or a combination.

I just closed the client now:
Then reopened:

So basically my client was out of sync for an hour, all my hashing power is not being used at all. This keeps happening, if more peers are affected than this is really bad.

Blake was extended due to the concern that it was too fast, blake2 uses 8 rounds as they concluded it was more than safe as like I said no better attack on it than bruteforce atm and due to it not being picked doubt many papers will have a go

64 G function calls ~ 64 rounds SHA-256, linear algorithm vs parallel ?

Unfortunately I didn't save the sources for the document, I was trying to compare the functions based on strength parity with SHA-256, so I didn't pick the lower rounds versions. Be aware that during the SHA-3 contest, BLAKE was "extended" while Keccak was "reduced" to optimize both their security and performance (respectively). If I were to use BLAKE there's no way the 8 rounds version would be considered (unless the hardware is light and closed source) because I'm not competent enough to understand all the implications, so the recommended versions are safe choices. As for the benchmark results, take your pick based on predicted future attacks and computing performance.

All the information and more can be found by googling "sha-3" and following the pages and pdfs (lots of scientific articles and detailed pages).

cool any chance you could profile the reduced round version?

the round 1 candidate for Blake used 10 rounds and the final used 14 rounds so no comparison yet for the 8 rounds Blakecoin is using

would be nice and scientific to see Blake 8, 10 and 14 tested independently

using the sphlib my results are as follows
14r = 290MB/s (slightly better than SHA-256 at ~270MB/s)
10r = 360MB/s
8r  = 400MB/s

edit:
If I remember correctly those Asic results are for 65nm and 90nm technology? you can already get FPGA's in 22nm-20nm although they are expensive power draw would be on par or less than those Asic's?

BLAKE will be faster than SHA-256, I was curious on your criteria for picking BLAKE. I know that Keccak has been implemented by some other coin as part of the hashing process (but not exclusive) so we have access to an implementation there (after all we are advancing human knowledge and technology here). I don't have any problem with your design.

Here is my short investigation: https://docs.google.com/file/d/0B6IDpD-2WO8qSnpCNmRpMmNsMlE

Blakecoin is aimed at CPU, GPU and FPGA and FPGA's are re-programmable and almost as fast and power efficient as Asic's these days and you can't get as bad a power efficiency with Blakecoin than with scrypt based coins?  

I agree with you on the points that a fast hash where your hash needs to withstand just a few minutes until the next block is quite a good choice.

As for speed comparison, I only compared the 256 bit strength versions and Keccak was faster on ASICs (which is good) that is why I asked. On CPUs/GPUs Blake is faster, but is the version you chose faster than Keccak on ASICs? (you know... just in case your coin becomes worth millions of dollars and power efficiency is desired)

Blake is faster overall on all platforms if you use less rounds, Keccak is superior because it uses the sponge construction function and is less like the older SHA functions thus more secure    that is why it won the SHA-3 not because its faster.

you don't need more security for a hashcash type system like Blakecoin or Bitcoin Gavin even said you could get away with using a less secure function, currently this function should offer about ~2^192 security and the best attack on the function is called a boomerang attack and is less efficient that bruteforce.

Another thing to consider is that Blake is easy to work with and understand lots of examples about, I did test all the functions in the sphlib library including Keccak but the best performance was blake-256 or bmw-256 on my i7 2600k Keccak was slow.

I researched other platforms like FPGA and GPU for the performance and Blake was best with BMW a close second

I could also have used Blake2 which is almost as fast as md5 but I had issues with the library on my dev machine and the sphlib library works well on both ubuntu 12.04 and windows 7 x64 which are my build environments    

Edit: 0.8.6 is due out soon should fix some bugs.  all peer nodes that are listed are datacentre hosted and have gigabit internet thats the best I can do with the resources I have to spend on blakecoin  

the wallet is still encrpted/decrytped using the same sha256d ecdsa public/private key function like Bitcoin so wallet should be as secure

Just out of curiosity, when I checked out the SHA-3 finalists, Keccak was superior to Blake, before, during and after the approval process (which is why it's now SHA-3). Did you choose Blake to work on having a Blake-based blockchain and software toolkit instead of the more popular Keccak or was it something else?

Also, this:


Also, again I got frozen 20 blocks behind, I'm helping secure the network, but if I lose block rewards again because I'm on orphaned chains and if I can't confirm new transactions on new blocks, this isn't working too well for everyone involved.

Could I use some better peers or do something else than manually restarting the client to keep up with the network?

check here daily as Blakecoin is new please expect bug patches at least in first few weeks, I did post here ~1000 blocks before change

0.8.6 is due out very soon (a day or two at most)

p2pool and a python blake proof of work module for pool operators within next few days maybe sooner

I will post here once I get some of this stuff done   

It seems my client found a block, but then spent all night on a dead-end chain that ended on block 3095. When I restarted it, the last block was 4014 after reorganization. How can I prevent this in the future, I was constantly connected to 9-10 peers?

Thanks, that did the trick!

Try this:
Go to "C:\Users\YourUsername\AppData\Roaming\Blakecoin" and in blakecoin.conf add this nodes:

addnode=54.202.86.231
addnode=54.202.51.105
addnode=83.160.126.160
addnode=198.136.49.104
addnode=95.137.65.2
addnode=77.94.104.6
addnode=54.242.65.36
addnode=92.115.69.196
addnode=221.231.109.62
addnode=188.195.183.99
addnode=83.133.105.235
addnode=5.13.43.11
addnode=25.59.129.231
addnode=54.214.57.241
addnode=54.205.219.43
addnode=54.217.135.123
addnode=54.242.114.109
addnode=54.226.16.3
addnode=54.212.14.113
addnode=79.111.160.118
addnode=88.122.104.90
addnode=105.237.22.204

Save blakecoin.conf and restart your blakecoin-qt

If you want here's blocks - blk.rar
In this archive:  blocks, chainstate, blakecoin.conf, peers.dat
Put these files and folders in "C:\Users\YourUsername\AppData\Roaming\Blakecoin"

If you want here's the blakecoin client that I'm using - Blakecoin-0.8.5-WIN_2.7z
v0.8.5.0-g0101012-beta