Hello ckolivas, any chance to add native support for Stratum mining protocol? http://mining.bitcoin.cz/stratum-miningThere're already two pools supporting it (me and BtcGuild) and I expect that others will join us soon. I have also support from Python miners developers (poclbm and Guiminer) so we will add native support to their code. Unfortunately I'm not a C++ programmer, so I can give you only some consultations about the protocol itself but I cannot provide you any code. The major improvement in all this stuff is that miner can produce unique coinbases locally, so creating block headers is done locally, without asking the server. Also the network layer is improved significantly, so you need only up to 10kB/minute of bandwidth even for 18ExaHash/s (10**18) rigs. Basically you can just bundle mining proxy (pure python) which I provide together with cgminer and run it on the demand, but it is quite ugly solution and native support would be much better. Let me know what you think about it! And while you're at it, change the mining API to event-driven
|
|
|
I'll do it, Inaba_Josh. Send me a unit! I overhauled Luke-jr's BFL code to make it more robust, but also slight more efficent (cpu usage wise).
|
|
|
I also got told, that bfgminer has more fpga optimized code than cgminer right now? maybe run a compile of that one, should "behave" the same with api, config etc.? At least worth a try, im going to sleep now though.
I've compiled bfgminer and will run that for a couple of days. see what the results are. so far after 15hrs, my U is about 0.5 lower than cgminer, but still early to say.
|
|
|
Can you point me to a link to be able to setup my workstation to compile the cgminer git code for dd-wrt
At the bottom of the readme is a link to the compiler, and the option I built with. There's no guide on how to do it... there's not enough time in the world to write one! It took me a few weeks to get it all working and this is part what I do for a living.
|
|
|
Definitely an observable difference there. Mine blink slower then your unbuntu there, probably as slow as your e3200. I can say that's less then 100ms though, 100 would be quite clear. Guess this is simply the processing time of the router... not much you can do about that.
|
|
|
(bflsingles led going out for about 100ms to 300 ms.) I certainly don't see that. just a flicker for me. 300ms would be VERY noticeable. In my version of cgminer I run (home_brew in my git) I have timers around all the comms routines. Avg time is around 0.015s, max time 0.024s over the past 2 days with many, MANY throttles (been HOT here). The best way to check is to compare hash rates between systems over a day or so. Should be consistent.
|
|
|
The users are not blameless, provide something really secure and the vast majority of them will not use it.
They don't care about security until after they lose their coins. Until then they just want total convenience, the easier a hacker can get their coins the easier it is for them too, for example a password easy to brute-force is also easy to remember, and having to use a GPG encrypted message to order things done with your coins is not worth the few thousand coins at risk... until those coins go missing...
-MarkM-
Well that would result in the user losing their own coins, which is their own damn fault, not the exchange losing everything.
|
|
|
There was talk of an 'internal PSU' for the SC single.
I hope that each SC single does not need to be plugged directly into the wall and instead will take a 12v supply.
|
|
|
It's an economic problem. A startup company wants to reduce costs as much as they can. In the case of Bitcoin exchanges, that means forgoing security audits, insurance and bonding in order to get something out now. The users don't notice security problems because these involve back end processes that they never directly engage with. In any event, these startups are paying the price for cutting corners handling other people's money. And the users are paying the price for leaving significant sums of money in an account that has no auditing and no insurance.
'zactly. Vast quanties of Ineptitude.
|
|
|
Thought this was well written. (i.e. no bias against!)
|
|
|
One hack after another...
It's getting quite tiresome.
|
|
|
Oh, does it zero after a time? I was expecting it to maybe reset every round or something
|
|
|
Also trying the vardiff server. Seems to be working OK, but the avg diff readout has stopped working... stuck at 0.
|
|
|
It's a bit bigger then the original single...
|
|
|
I did a quick and dirty add column when I added a field to enter the config address. It's certainly quick to re-configure everything (dpending on how large your system is), but that's still greater than 0. Also, you have to delete the database first... login to mysql, enter commands...
|
|
|
For some reason I'm getting high reject rate on US2, 1.1% over the past couple of days. US1 however, has been almost 0. I run rotate every 20mins between a few pools.
If you run a regular rotate between the pools? are you not going to get a few naturally occurring rejects just because it can't submit a share to the pool it's connected to when it changes over. No, cgminer keeps the right shares in the right place. This is unique to US2 only.
|
|
|
For some reason I'm getting high reject rate on US2, 1.1% over the past couple of days. US1 however, has been almost 0. I run rotate every 20mins between a few pools.
|
|
|
A rather amusing thing is occurring to me on the webpage. If I go to the "Block Stats" page with Chrome I get:
"This page is in Estonian, would you like to translate it?"
Is this just me or is anyone else getting this as well? Just wondering...
Thralen
I've had that before, but not recently.
|
|
|
|