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

Ok I will definitely keep that in mind. This was also an interesting read:

Many thanks


Just some threads I recall reading some months back. The problem is more acute with bitcoin but it's worth bearing in mind for blakecoin too. Some crooks have built enormous rainbow tables of brainwallet addresses and are monitoring the blockchain just waiting for these addresses to appear, then instantly sweep the coin into their own accounts. So using any simple combination of words, or a well known phrase (say from a book, or song lyrics), risks losing your coin. It's a big risk for novices, less so if you know what you are doing and select a good passphrase (though there is the matter of "entropy", which basically says you need a long passphrase to match the security of the 160 bit address hash).

Googling "brainwallet security" (without the quotes) brings up some good links. This is a good discussion.

It works great, thank you!

Any links to information that explains your stance on brainwallets being very dangerous? I wonder if there is something I need to be aware of besides the need for an extremely strong passphrase.

Donation sent to your BLC address. Thank you for all of your effort.

Thanks. I was just curious as to why the original vanitygen did not work for blake with the -X 26 version byte. It was just a matter of using blake hash instead of sha256d for the base58 checksum, plus a change to the privkey version byte. Also using compressed rather than uncompressed addresses, hence the fork from WyseNynja rather then samr7's original.

Anyway I've just updated the github (it's slightly less of a horrible hack now, the previous version completely broke vanitygen for anything other than -X26 blakecoin). I've also put up my blake brainwallet python script for Ignatius. It's based on JackJack's pywallet and is very helpful for understanding the address generation process (which is why I wrote it way back for bitcoin).

Awesome looks cool  

Ah, maybe my comment in the README was a bit confusing. I said the valid range was BT to Bs (I worked this out by trial and error), but only part of BT and part of Bs are usable. You can generate any address from BU, BV, BW, BX, BY, BZ and Ba, Bb, Bc to Bq, Br (excluding Bl since lowercase l is not part of the base58 character set). For example I've been running:
./vanitygen -F compressed -X 26 -ik -o outkram.txt bkram

Brainwallet is easy. I have a python script that I can trivially modify to do that. I'll sort something out tomorrow (its getting late here). Doing it in C will be a bit more difficult (and a web version is quite beyond my ability, sorry). Not that I'd recommend brainwallets, they are really very dangerous unless you know exactly what you are doing.

With merged mining being a primary goal here, I was wondering if anyone capable of doing so would be willing to implement this idea. It Would be helpful to have a multicoin wallet for the merged mineable coins. Perhaps using electrum as a base since that would also remove the need to download the block chains for every coin. Any thoughts on this suggestion?

Thank you for this. I actually took a brief look at the source before and failed to get a blake version going. If you have extra time and find the desire, please create a blc brainwallet program.


I can't seem to generate addresses, likely due to my lack of understanding of required blc prefixes.

Edit: Yes this works, thanks & sorry.

I'm right out of time, but I've pushed the source up to github anyway
https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/experimental/DE0-Nano

Its possible that the problem is not with the TCL mining script but with the actual implementation of the algorithm (this was a very early version of the code). I'll get it debugged properly next week.

And as a little present to the BlakeCoin community (it's a crude hack, see the README).
https://github.com/kramble/FPGA-Blakecoin-Miner/tree/master/vanitygen

I think you're going to be rather disappointed with the performance.

I've just run a test and it's only reporting 2MHash/sec (though that may just be due to mis-calibration), but it took 5 minutes to find a share and the pool rejected it !!

I'm only clocking at 50MHz though, so it should go a bit faster, but the DE0-Nano voltage regulators are running quite warm even at this clock speed, so it will need some additional fan cooling. I'm a bit reluctant to put up a faster-clocked bitstream, though of course if you compile your own, you can clock it as fast as you dare.

HMM, got a second share rejected by the pool, so something is a bit off. I've not used the getwork pool (eu1.blakecoin.com:8337) before, so I'm may be doing something wrong.

PS This is weird (and a heads-up for BlueDragon). The pool seems to be sending an extra byte in the getwork data (129 bytes rather than 128), and expects the same in return. The python miner seems to cope with this, but the TCL one does not (they manipulate the hex strings slightly differently). I've hacked the TCL miner to fix it (I think, as my TCL coding skillz are even worse than my python). Except it's still not working and waiting up to half ah hour for a share makes debugging it rather slow. It looks like it won't go up today after all as I'm running out of time here.

Cool! I used the FPGA bitcoin miner last year!

-Lyddite

OK, will do. I only used the DE0-Nano for my early tests, so the performance is not great. Also it uses the Altera TCL mining scripts (derived from the Open Source Bitcoin Miner), so it will only work solo or with a getwork pool, not Stratum.

I'll just need to tidy it up a little and check its still working, so give me a few hours and it will go up.

Hi,

I have a couple DE0-Nano boards that aren't doing anything at the moment. Would you upload the code to github?

-Lyddite

Photon

https://bitcointalk.org/index.php?topic=478136.0;all


https://cryptocointalk.com/forum/944-photon-pho/

If you check out one of the mining pools that supports btc/nmc/etc merged mining you can get an idea of what it means. The hashes generated from cgminer can be used for both or several different blockchains since the mining protocols are compatible. The code for implementing merged mining is on the pool end, since the pool is what generates work input for your miners. The blockchains are still separate from each other in every way, except that their network hashing power is combined. That is why it will provide vastly superior security; imagine if all the miners for all the scrypt clones where sharing resources to secure all the blockchains simultaneously. It is perhaps uncertain how this will affect the prices of each individual coin involved. However, the combined hashing power will increase the difficulty, and thus decrease the payout of mined coins. On the other hand you will get multiple types of coins from mining so it should balance out. Also, the values of each separate type of coin would be independent, based on its own characteristics such as # of coins in circulation, reward structure, utility and popularity. Another great advantage is that since the Blake256 merged mining pools will each support several blockchains, it should provide a larger number of pools splitting the load for each blockchain, which reduces risk of 51% attack or other abuses.

the miner will not need to make changes apart from having a wallet for each merged coin and you will only get paid for your shares on each block find this could be all coins merged or just one, all pools should get replaced once I have the code working and the shares/payouts/block find 100%

Thanks. The --ztex-clock code is implemented in exactly the same way as the icarus options, so that makes sense. What I don't know is if the boards will always be detected in the same order, though I guess plugging them in one at a time should ensure this.

I think the ztex boards have a firmware ID string which could be used to identify them (I vaguely remember seeing some reference in the java SDK), if anyone wants to have a look at writing a better cgminer driver (unlikely I know )

It must be common knowledge that the Ztex FPGA frequency adjustment is not perfect, but here's another anecdote. I recently got an original 1.15y board where two of the chips are impossible to run without forced clock limits. Basically, they start giving lots of HW errors at 188 or 192 MHz, and they end up SICK. After setting an upper limit of 184, they run fine, with zero HW errors. It's as if the HW vs. frequency is an extremely steep function for these chips.

The board runs SHA-2 code fine at nearly 220 MHz, though the two chips are the slowest of the bunch. I also have other 1.15y/x boards where Blake runs fine with the default adjustment on cgminer 3.1.1

To answer a question in the README,
I got the freq limits working for two boards using

All in all, this is not a bug report or anything, but an interesting finding. I've tried both of the currently available bitstreams with similar results.

So what does merged mining mean? You get double the coins for your hashing? Will the blakecoin pools automatically switch to this, or do we need to do something?

Photon is a blake256 coin and will probably be the first to support merged mining. I believe united federation coin is blake256 but the dev made changes that will make it unlikely to support merged mining. Bryce Weiner is also working on some blake256 coins that will be merged mineable