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

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

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.

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

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 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?

yes getwork is working 

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, you mentioned that Blake2 is faster, so why didn't you use that?

Rupy, I appreciate you sharing your idea and it is creative and interesting. However I think you are overlooking some key points. First, blakecoin already has its chosen algorithm, this is unlikely to ever change without making a whole different coin. Second, hashing algorithms general take many people several years to develop and test, so assuming your idea is plausible it probably won't come to fruition for at least 5 years. Finally, and most importantly, blakecoin is meant to NOT be asic resistant. If/when BLC is popular enough to warrent making an asic for it, we want the asics to be as fast, efficient, and CHEAP as possible. That way even if asics are made, the avg person can still afford one. Also will allow for higher network hashrate with minimal power consumption. People are so indoctrinated with the "asic resistance" B.S. spread by scrypt coins, I know it can be hard to wrap your head around "asic friendly" at first. But don't be disenchanted, if you want to invent a dynamic hash algo, it would be quite an achievement but you'll have to start studying cryptology asap :-)

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.

I was unable to get things going on Windows 7 64b. The readme states:
The main dependencies are python 2.7 and the PyUSB module created by Pablo Bleyer. PyUSB is available as source or an installer for Windows from: http://bleyer.org/pyusb.

I was unable to find a PyUSB module for Python 2.7, only 2.6. I was unable to get connected to the x6500.

I then tried a Windows XP 32b virtual machine and had immediate success. I have since moved to an Ubuntu virtual machine running eloipool_blakecoin.

Do the current pools support getwork? I could be wrong but I don't believe stratum is supported by mine.py.

Jude, it looks like you could successfully mine if you just pointed it at your blakecoin wallet via RPC.

Happy hashing

some lag on eu1 going to try a restart

Edit:
might need to put in another support ticket to my provider 

its not safe just resistant e.g 51% attack

Yes, well that's the point of all this, we didn't think we could have distributed "double spending safe" transactions either...

I don't think this is possible if you can write code in C you can FPGA or ASIC at some point

any dynamic bits you would just do in the miner software

Ok, you are missing the point. You wouldn't make the bitstream manually it would be transformed automatically by the client (tools that don't exist yet). You would have to invent stuff!

The point of the exercise: make a hasing algo that can't be ASICifyable because it changes and the parts that change have to be in the silicon to be performant.

Wait, this is a bounty! I would easily pay 5 btc for this, anyone else?

Blake-256 = Small, Fast, Simple, Power efficient

its going to be hard to beat that

maybe you want to have a go at Blake2 its the only faster algo I know, BMW-256 is quite quick as well

At one point I had the bright idea that Quark would be implementable in FPGA (one engine per hash algo, probably not fully-unrolled so as to get them to fit), so I thought I'd start with keccak (been working in collaboration, but I won't mention who unless he wants to chime in).

Not good. ISE just outright refuses to route it (even for a very small amount of LUT usage), the 1600 bits of state just seem to send PAR into a tizzy. Shame really as it looks nice on the ASIC floorplan.

I think you are missing the point!  

its silly and could still have an asic would just be an expensive one to have made 

what miner is going to spend days/weeks building a bitstream for each diff change would never get any transactions done

That's the thing, I don't have time (or the brains) to do this but I'm sure it's possible, using custom tools and whatnot. Someone out there is most certainly already working on it, and the rewards will be huge, think Bitcoin 2.0