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

update to blake coin with bugfix as reported by a gitpull (same one on photon also now fixed) fixes an issue with signatures

i built this

https://drive.google.com/file/d/0Bz8503hoyr74QU5vZzRrTmNsTHc/edit?usp=sharing

from this

https://github.com/photonproject/Blakecoin

NOTE, Bluedragon asked me to test and update this , he will merge the gitpull when he has time......

Thanks to all supporters of the blake 256 system

itself I was surprised. I test. thanks.

I reset eu3 but I dont see any issue on the server I also checked with one of my miners all accepted and no rejections so far maybe you changed some settings?

was a lot of rejections. all right?

The explorer at blc.cryptocoinexplorer.com has been updated to the latest build.

Features Added:

Market information is now on the home page where the ticker used to be.

Address ownership claim system is now in place. Access with the "Address Claim" button. Address ownership information is available on the top 1000 balances only.


Next build plans:

Charting page (tx, difficulty,blocks - 24 hrs,Week, Month)

Country ID and flag for the IP addresses on the peers page.

Address ownership information available as a tool-tip anywhere on site.


Your suggestions for features or statistics you would like to see are welcome!!!!

Nice. I only skimmed through the paper, but even without thorough analysis you can guess that X11 wasn't exactly designed for cryptographic security

The way I see it intuitively is that each of the 11 functions is a non-injective mapping (many-to-fewer), basically by the definition of a hash. So when you feed one hash to the next function, you get a many-to-very-few mapping, i.e. much more potential for collisions.

Also, if you find a collision for the first function, it just carries over to the end. So if you want to hedge your bets, you need some other combination besides this linear chain.

There doesn't seem to be any cryptographic design behind X11 etc., they just wanted a new PoW function for a temporary monopoly. While PoW isn't about exact collisions, they probably go hand in hand -- you're looking for a partial collision with that row of zeros.

(Temporary ASIC resistance is often mentioned. If X11 is truly ASIC resistant, then surely there's no need to develop X13 and the like. OTOH, if there's an X11 ASIC, then it won't be that hard to make an X13 ASIC.)

Hence I think most coins with new hashes are just a waste of resources. Making hashes particularly slow like Scrypt and Cryptonight is just annoying when updating a wallet. This is one area where Blake wins.

As for papers on hashes, here's a less mathematical one: Boolberry's fast but memory-hard algo.

here is a paper on the HAsh Iterative FrAmework (HAIFA) and explains the improvements over the Merkle–Damgård construction method
http://eprint.iacr.org/2007/278

some of the multi hash algo's like x11, x13 are unproven in security terms as there is very little if any research on them, still lots of algo's in crypto coins just claim to be more secure or more efficient without any sort of proof or independent research I think it is very misleading yet they do get away with it  

it is also funny with some of the coin algo's when they use the 512bit+ size hash but just pad the data or trim the result which is known to be insecure to some attacks  

fast, simple, efficient while maintaining the same security as Bitcoin is the way to go imho I guess time will tell  

I am glad to have other people who are involved or supporters of the project that also appreciate and understand the technical merits  

Blue, you should be a teacher, your short to the point math breakdown was perfect,  would have taken me 3 pages to explain it and not near as good.
What he explained in simple and complex terms for those who understand the mathematics is why the blake 256 system is superior to all others presently available. 

As a curiosity i have fooled around with testing cryptonote code base and builds , test coin ect....  the ram necessary is really a lot. I am not saying it is a bad design just quite different from anything that is based off of bitcoin. 

While Kramble and others brought up the x11 x13 items i would like to point out a paper and some research that is often overlooked.

Somehow people got the idea that multiple hash algorithms are better than a single hash algorithm.

The truth is actually in reverse. They are less secure from a mathematical standpoint.   Ok I know the chance of a 'colission' is like less than being hit with an asteroid and a baseball at the same time ,......still who knows what future technology will bring.

Remember , in the 1980's 8 bit encryption was used (yes prime numbers 8 digits long) 

Today a smart kid with a rooted phone could crack 8 bit encryption like an egg.

We know not what future technology will bring but if we are to design systems that will out last us and go down in history we can at least pay attention to known facts.

So for those who think x11 x13 x23 x55 x99 is better see here please

http://ai.stanford.edu/~xb/crypto06b/blackboxhash.pdf

Thanks for the explanations.

Cheers! Couldn't have said it better myself.  

Actually I'm pretty much finished with crypto on FPGA now. It is just not worth the investment of my time (and the frustration, see what Blue said about ISE). I did have a look at a couple of other algos (groestl, keccak) and got initial, rather poorly performing, builds working, but the GPUs perform far better. The only advantage for FPGA is power consumption.

As for X11/X13, I reckon it can be done on a LX150, but only via a soft-CPU optimized for hashing. A huge amount of work for a very poorly performing hasher. So I'm not going there.

Anyway, best of luck rupy.

And why not have world peace and ponies while he's at it? If you refer to the Cryptonight hash that most Cryptonote coins use, it's a combination of a few different hash/encryption functions and it needs a couple of megs of fast cache. It might fit on one of those big-ass FPGAs that cost thousands apiece. Conversely, Blake is a single, relatively simple hash, which is why it's great for practical FPGA implementations. And as BlueDragon747 already pointed out, even that hasn't been quite trivial.

In the software world, it's easy to make bigger and bigger programs for the same CPU/GPU, as long as you have more memory. The CPU is only running a small part of the program at any single time. This is why we've seen crazy PoW solutions like X11/13/15. But when you're doing something in hardware, as in FPGA, you basically have to fit everything on the chip at once. That's why FPGA/ASIC projects run into hard limits more easily than software ones.

Its an open source project why dont YOU port it, working with ISE its a PITA not fun at all

*you could even try to fit the tri core version for the Ztex and get a feel for what working in Xilinx ISE to get a high fmax bitstream is like and getting resource issues that during PAR make the design fail (weeks/months of running ISE to get designs built to bitstream is just not fun)

its not going to be easy and I feel sorry for anyone trying to do it would be lucky to fit a single core and the fmax will not be good

also as cinnamon pointed out its not same code base so may have other stuff in the way you mine with the wallet making the task quite hard work, maybe just for your gain from this as kramble does not have a ztex 1.15x as far as I know  

You should be asking the Cryptonote devs  

I think GPU's will be more suited to 14 round Blake-256 as its easier to change code than it is for FPGA but its still never going to be as fast on CPU/GPU/FPGA vs the 8 round version used for the merged Blake 256 Family of coins

ok, then it would be interesting if kramble could have a look at just adapting CryptoNote to the zTex?

I think it would make sense even if the synergies are lost between blakecoin and cryptonote!

You are welcome to get Xilinx ISE and build it yourself based on Krambles FPGA project getting a good high fmax design to bitstream is no easy task and the 14 rounds used by cryptonote for Blake will make it slower and harder to do as it will be larger and use more power and resources on chip!

also note that 14 rounds will never be as good hash/watt as using 8 and for a PoW system I see no advantage to using more than 8 as it gives minimum of 2²⁰⁰ best attack and 2²⁵⁶ for brute force  

*14 round is also the final submission of the Blake-256 algo to NIST for SHA-3 which it did not win because they wanted the sponge function, why the increase in rounds for Blake-256 was due to others saying Blake-256 was too fast but in a PoW system we want fast and less resources hence why I reduced it from the 10 rounds(round 1 Blake-256 SHA-3 candidate code was faster/better than final imho) to 8 rounds while keeping same security for brute force as SHA-256D (2²⁵⁵) vs 8 round Blake-256 (2²⁵⁶)

here is the independent proof of the security of 8 Round Blake-256 by one of the best academic teams in the world to show that I did not just make this up it is provable with academic papers about if you care to read them


*Other result and papers were about earlier than this but not specifically about 8 round Blake-256 I had estimated a figure of 2¹⁹² but it seems I was a little too pessimistic and actually 8 round Blake-256 is better than I first thought  

a Boomarang attack is not so relevant for a PoW based wallet where we are doing a brute force and for brute force Blake-256 is better than SHA-256D as that is a double SHA-256 and thus has an extra collision, to get length extension resistance with the Merkle–Damgård construction method Bitcoin used a double sha-256 but Blake-256 uses the HAIFA construction method that does not need a double hash to have same resistance to a length extension attack

also remember that the algo runs in wallet on CPU for regular function of receiving and checking of blocks, so faster and more efficient is better hence why Blake-256 was used for more than PoW in the Blake 256 Family of coin wallets then on top of the already extremely efficient system you should take into account the extra efficiency gained by merge mining 6 coins+

*yes the pool server can run more wallets due to the efficiency gained on the same server hardware/specification  

I personally think on a technical point view its hard to beat as 7 round Blake-256 is no good and only 2-3 other algos that are also academically provably secure and faster than 8 round Blake-256 are avalible and no one is using them as far as I know  

I just want to use my zTex 1.15x for coins that try to evolve crypto currencies as diversification and hedge.

cryptonote is a totally different based system unrelated to blake 256
 (not a fork of bitcoin at all and uses a totally different system)

if you want to make a cryptonote coin , fork their repo and follow thier clone guide
you will need at least 2 large servers to run the seed nodes/daemons with a lot of ram.

note it has no gui and is not for noobs, their work seems pretty good but is quite a way from being used by anyone other than an advanced user

a better idea is to mine the coins of the blake 256 family , you can merge mine 6 coins at one time and everything is open source

we have a strong development team and many future things in development

the technology is certainly on our side and miners are available for cpu, gpu , fpga so if you loo at it the blake 256 system offers the most of any alt coin  or set of coins right now, apologies to bluedragon for floating off topic here but to a casual observer I think it prudent to point out these things.

its not same 8 round Blake-256 as far as I know so it is incompatible 

Best to ask the cryptonote devs and not here as they have never contacted me!

Hey, what about a blake hash coin based on http://cryptonote.org? Or is that for CPU mining only?

I have:

Gigabyte ATI - 7870 2 GB - driver 14.7 - 1660 Mh/s
MSI ATI - msi r9 280x gaming 3g - driver 14.7 - 2670 Mh/s