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

[rupy]

if you mod the algo dynamically like you are saying its not going to be power efficient as you are trying to create resistance  

and if you can put it on FPGA then some part of it could be put into silicon!

Yes, but if you modify the bitstream you would have to make a new ASIC. So I suggest inventing a new hashing algo that requires a new bitstream every difficulty change (or so) not like quark (that uses a set of known algos) but a totally new and fundamentally dynamic algo.

[rupy]

Blakecoin is listed on cryptocoincharts.info

http://www.cryptocoincharts.info/#jump-BLC-BTC

nice this one is good too
http://www.cryptocoincharts.info/v2/pair/BLC/BTC/atomic-trade

So the more exchanges, the lower the price?

[BlueDragon747]

if you mod the algo dynamically like you are saying its not going to be power efficient as you are trying to create resistance  

and if you can put it on FPGA then some part of it could be put into silicon!

Yes, but if you modify the bitstream you would have to make a new ASIC. So I suggest inventing a new hashing algo that requires a new bitstream every difficulty change (or so) not like quark (that uses a set of known algos) but a totally new and fundamentally dynamic algo.

quark uses an awful waterfall method for its algo's its terribly inefficient!  

try building the bitstream from source via Xilinx ISE and then think about it again

takes days/weeks to get a good fmax build  

[BlueDragon747]

Blakecoin is listed on cryptocoincharts.info

http://www.cryptocoincharts.info/#jump-BLC-BTC

nice this one is good too
http://www.cryptocoincharts.info/v2/pair/BLC/BTC/atomic-trade

So the more exchanges, the lower the price?

not sure if you are looking at same graphs as me but the price is set by the market and atm it is super cheap!  

But I guess Bitcoin had this in the early days too 10k BTC pizza for example

[rupy]

if you mod the algo dynamically like you are saying its not going to be power efficient as you are trying to create resistance  

and if you can put it on FPGA then some part of it could be put into silicon!

Yes, but if you modify the bitstream you would have to make a new ASIC. So I suggest inventing a new hashing algo that requires a new bitstream every difficulty change (or so) not like quark (that uses a set of known algos) but a totally new and fundamentally dynamic algo.

quark uses an awful waterfall method for its algo's its terribly inefficient!  

try building the bitstream from source via Xilinx ISE and then think about it again

takes days/weeks to get a good fmax build  

See this is how I know this is a good plan, there is room for improvement. I don't even know if it's possible, but I have the feeling this is where crypto currencies could evolve towards! We need hashing, so we should improve hashing!

[BlueDragon747]

See this is how I know this is a good plan, there is room for improvement. I don't even know if it's possible, but I have the feeling this is where crypto currencies could evolve towards!

have you ever used Xilinx ISE to do a build for FPGA or do you use the pre-built bitstreams only?

crypto currencies should just stick to the work by academics in the field and try to use best practice if possible  

[rupy]

See this is how I know this is a good plan, there is room for improvement. I don't even know if it's possible, but I have the feeling this is where crypto currencies could evolve towards!

have you ever used Xilinx ISE to do a build for FPGA or do you use the pre-built bitstreams only?

No, only used pre-built stuff. That's why I don't know, if I knew I would have tried to build a "dynamic" hashing algo already.

But I can imagine you need some core elements, that could be provided as inputs to the "ASIC" to be required inside the "ASIC" for performance reasons.

"ASIC" = the bitstream

[BlueDragon747]

See this is how I know this is a good plan, there is room for improvement. I don't even know if it's possible, but I have the feeling this is where crypto currencies could evolve towards!

have you ever used Xilinx ISE to do a build for FPGA or do you use the pre-built bitstreams only?

No, only used pre-built stuff. That's why I don't know, if I knew I would have tried to build a "dynamic" hashing algo already.

good luck you are going to need it plus without independent test you could make an algo that is flawed

try building from source on FPGA before you get too exited about the wild idea

[rupy]

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

[BlueDragon747]

That's the thing, I don't have time 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

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

[kramble]

quark uses an awful waterfall method for its algo's its terribly inefficient!  

try building the bitstream from source via Xilinx ISE and then think about it again

takes days/weeks to get a good fmax build  

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.

[BlueDragon747]

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.

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

[rupy]

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

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?

[BlueDragon747]

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

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.

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

[rupy]

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

[BlueDragon747]

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

its not safe just resistant e.g 51% attack

[BlueDragon747]

some lag on eu1 going to try a restart

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

[Ignatius]

I've not able to even get the driver running need to retrace my steps again. might move to ubuntu if no luck still trying win764 and a x6500.

works a sha256 miner with cgminer. do ineed to unload something from that?

Let me know how it works for you on Linux.

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

[Jude Austin]

I've not able to even get the driver running need to retrace my steps again. might move to ubuntu if no luck still trying win764 and a x6500.

works a sha256 miner with cgminer. do ineed to unload something from that?

Let me know how it works for you on Linux.

I was unable to get things going on Windows 7. 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 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 miner.py.

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

Happy hashing

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.

[bzyzny]

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 :-)