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

[bzyzny]

BlueDragon747, you mentioned that Blake2 is faster, so why didn't you use that?

[BlueDragon747]

BlueDragon747, you mentioned that Blake2 is faster, so why didn't you use that?

it was a compromise you can't currently get Blake2 in OpenCL and Verilog and only a few examples in VHDL which as kramble has pointed out can make things more difficult for an implementation.

to get best speed from Blake2 it would also be best to remove the endian conversion from the wallet and other software, Blake-256 was compatible as it was designed to replace SHA-256 which is big endian

I did the reduced round to minimize the difference between them in terms of speed/power efficiency while maintaining the security buffer, designed for a best attack of min 2¹²⁸ ideal was 2¹⁹² but real world 2²⁰⁰ so quite happy with design decisions  

that buffer basically means no better way than brute force as a boomerang attack would not make any difference to the wallet/mining anyways

for bruteforce its Blake-256 = 2²⁵⁶ and SHA-256D = 2²⁵⁵ (extra collision due to double hash)  

[BlueDragon747]

Do the current pools support getwork?

yes getwork is working 

[rupy]

@bzyzny I agree, just have to understand the theoretical collision attack for SHA1 and how SHA2 solves that. How is a hash algo developed, by trial and weakness detection or do they "calculate" the theoretical strength somehow?

[BlueDragon747]

@bzyzny I agree, just have to understand the theoretical collision attack for SHA1 and how SHA2 solves that. How is a hash algo developed, by trial and weakness detection or do they "calculate" the theoretical strength somehow?

read some academic papers they do it in math first before writing an algo then get it independently verified, but most of the algo's are built from previous algo's its not easy to write a secure hashing algo especially from scratch

e.g blake was from lake and chacha

Daniel J. Bernstein is one of the best:
http://cr.yp.to/djb.html

JP Aumasson is also very good (blake/blake2):
https://131002.net/

SHA-256 uses the Merkle–Damgård construction method
Blake-256 uses the HAIFA construction method which an improved Merkle–Damgård
Keccak uses the sponge construction method

SHA-256 is weak against length extension that's why they use a double hash as it is suposed to give resistance to that attack, Blake-256 is resistant to length extension due to the HAIFA construction method and Keccak is immune to length extension that's why they picked it for SHA-3 not for its speed

This is cool ref and will give you the background on different construction methods:
http://theglobaljournals.com/paripex/file.php?val=MTExNA==

This is how I know 8 round Blake-256 has a best attack of 2²⁰⁰, independent academic paper by one of the worlds leading groups of cryptographers  
https://eprint.iacr.org/2013/852.pdf <-- bottom of table on p4, before this I used an educated guess based on other attacks (I was a little pessimistic at 2¹⁹²)

[bzyzny]

@bzyzny I agree, just have to understand the theoretical collision attack for SHA1 and how SHA2 solves that. How is a hash algo developed, by trial and weakness detection or do they "calculate" the theoretical strength somehow?

I believe most cryptographic algorithms are made by either academic research groups at universities or by private corporations. Regardless, as BlueDragon pointed out, they usually start with the theoretical math and use existing techniques as a basis. Quite often new algorithms are made because theoretical flaws or weaknesses are found in existing algorithms, and so they apply that knowledge to find ways to remove/reduce those flaws. Once the improved algorithm is made, there is extensive peer review and analysis done before finalizing its implementation. In order for an algorithm to become a standard (like SHA2 and SHA3) it must go through several rounds of examination and comparison to other algorithms. And an important point to remember is that just because a particular algorithm is chosen as the standard (i.e. keccak for sha3) does not necessarily mean it is "better" than the other candidates, but only that it met the required criteria better. They try to pick whichever algo is most well rounded, or that best addresses a specific issue in the previous standard. Point is that keccak and blake not necessarily better or worse than each other, but each has advantages/disadvantages depending on what you are using it for. I think BlueDragon747 made the right choice with using blake since it seems better suited for use in cryptocurrencies than keccak. As for how they detect weaknesses and calculate theoretical strength, I dont know the specifics but it involves a lot of advanced math and statistical analysis regarding probabilities, and also i'd imagine they utilize supercomputers to try to crack it.

if you are interested in the history of cryptography, this is a good read:
https://archive.org/download/NSA-WasntAllMagic_2002/NSA-WasntAllMagic_2002.pdf

[bzyzny]

BlueDragon747, thanks for the explanation about blake2 vs blake1, makes sense you would choose the one that has more documentation and resources available and is easier to implement. Also I'm glad you pointed out the reason keccak was chosen for SHA3, I was having trouble finding an explanation of their decision.

[BlueDragon747]

no problem bzyzny you have quite a good understanding about crypto stuff  

[MikuCoin]

Network hash rate slowly getting higher.

[bzyzny]

no problem bzyzny you have quite a good understanding about crypto stuff  

perhaps more than most, but i feel like im still only scratching the surface. i studied network communications at university and loved protocols and encoding schemes, but cryptography wasn't something i started learning about until i discovered bitcoin

[rupy]

Since 7 this morning there are no credit transactions for my account on eu1... So I see the confirmed coins but no unconfirmed ones...

[rupy]

pool eu1 my account... wallets don't have workers...

[BlueDragon747]

pool eu1 my account... wallets don't have workers...

ahh ok I see an error: Potential Double Payout detected

checking DB now

Edit:
should be fixed now

did you get a payout and can you see unconfirmed?

[rupy]

Yeps, all back to normal.

[BlueDragon747]

Yeps, all back to normal.

cool 

if you see any other issues just let me know 

[kramble]

I did solo-mine, would have found two blocks.

But the base difficulty and golden nonce are off in mine.py for the coin so it counted the solved blocks as rejected.

There is an easy work-around, just uncomment line 104 of mine.py. This will submit all shares regardless of the difficulty target, which is harmless when solo mining, and since (AFAIK, Blue may want to chip in here) the blakecoin pools are currently fixed diff=1 (even though the dashboard may report higher), it should be OK there too.

A slightly more sophisticated fix would retain the subsequent CheckTarget() and logger calls, but always return True.

[BlueDragon747]

I did solo-mine, would have found two blocks.

But the base difficulty and golden nonce are off in mine.py for the coin so it counted the solved blocks as rejected.

There is an easy work-around, just uncomment line 104 of mine.py. This will submit all shares regardless of the difficulty target, which is harmless when solo mining, and since (AFAIK, Blue may want to chip in here) the blakecoin pools are currently fixed diff=1 (even though the dashboard may report higher), it should be OK there too.

A slightly more sophisticated fix would retain the subsequent CheckTarget() and logger calls, but always return True.

my pools are fixed diff 1 so work should get accepted if the share is diff 1 and the miner can submit it, kr105's pool blakecoinpool.org is diff 2  

getwork is on port 8337
http://eu1.blakecoin.com
http://ny1.blakecoin.com

give it a try 

[kramble]

my pools are fixed diff 1 so work should get accepted if the share is diff 1 and the miner can submit it, kr105's pool blakecoinpool.org is diff 2  

getwork is on port 8337
http://eu1.blakecoin.com
http://ny1.blakecoin.com

give it a try 

OK, thanks, I was a little confused about the diff, but I did recall kr105's as sometimes reporting diff 2 and sometimes diff 4 on the dashboard. Anyway the worst that can happen is an increased reject rate, which is not ideal from the pool's point of view, but fairly harmless if it's just for testing. The FPGA always returns diff 1 shares, so unless there is an issue with hardware errors there will be no problem on your pools.

Once we've actually got some shares accepted on pool, the mining script can be tweaked to fix any target issues (see my previous post on the workaround).

[BlueDragon747]

my pools are fixed diff 1 so work should get accepted if the share is diff 1 and the miner can submit it, kr105's pool blakecoinpool.org is diff 2  

getwork is on port 8337
http://eu1.blakecoin.com
http://ny1.blakecoin.com

give it a try 

OK, thanks, I was a little confused about the diff, but I did recall kr105's as sometimes reporting diff 2 and sometimes diff 4 on the dashboard. Anyway the worst that can happen is an increased reject rate, which is not ideal from the pool's point of view, but fairly harmless if it's just for testing. The FPGA always returns diff 1 shares, so unless there is an issue with hardware errors there will be no problem on your pools.

Once we've actually got some shares accepted on pool, the mining script can be tweaked to fix any target issues (see my previous post on the workaround).

I am still using your python Blakecoin miner for the Lancelot boards and set that to diff 1 works a treat on the pools

[Jude Austin]

I did solo-mine, would have found two blocks.

But the base difficulty and golden nonce are off in mine.py for the coin so it counted the solved blocks as rejected.

There is an easy work-around, just uncomment line 104 of mine.py. This will submit all shares regardless of the difficulty target, which is harmless when solo mining, and since (AFAIK, Blue may want to chip in here) the blakecoin pools are currently fixed diff=1 (even though the dashboard may report higher), it should be OK there too.

A slightly more sophisticated fix would retain the subsequent CheckTarget() and logger calls, but always return True.

Thanks for the response Kramble!

I will give this a shot.