When updating payment address if your forget the password it kind of silently errors out. You get the message "Payout Address Has Been Changed" and an email alerting you to the change, but it stays set to the old payout address since the password wasn't entered.

Seems to happen in 10-20% of them. Might be heat related, as it seems to happen more often when the intake air temp is higher. You don't have to do a hard powercycle to bring the board back up, just go to the mining configuration tab and hit the save & apply button. It will do its frequency self-test and start hashing again in a few mins.

Did you go to the address behind McDonalds as well? That's the one they list in their footer.

Damn, looks like people are paying them

https://blockchain.info/address/1Ko6n7hC9aiHqbTDnSemfzAkrLUfh7i84N

Edit: and more

https://blockchain.info/address/19hgd15L8ZKWGtngEAXmiu5hVSr4wwSD1R
https://blockchain.info/address/178PUWErgp8VoSksLjxpLjC3Na3hXxTSvN

They went all out on this one, even registered the LLC with the state of California. PR releases all over the last few days.

Edit: This looks like the LLC's registered agent: https://nuwber.com/person/563a4e4f7686b0176bddfbbf
Who's going to call her and see if she knows it's a scam?

Ah, I see. That's what I was wondering before, if there was something in the work items that was unique per connection/difficulty. Thanks.

I didn't see his full post, but what is to stop someone from opening multiple connections and submitting shares just above the work diff? Say you have a miner that avgs 10k diff, open two more connections to submit all work from 5k-9999 and four more connections for all work from 2.5k-4,999, etc. This miner would be making the same as an honest miner, in addition to all the proceeds from submitting his lower shares on the other connections.

Seems even easier to take advantage of on pools that allow you to set your own difficulty. Open up a bunch of ranges and get paid huge amounts for rarer high hashes, while still getting paid on as low hashes as your connection speed allows.

I asked about this before, but I think I confused the issue previously by asking about connection 'cookies' or individual connection nonces to try to prevent this.

It would be obvious from statistics of course, but it still seems ripe for exploit on pools that don't pay much attention.

Might have a memory leak when running ckproxy. Had a Pi start acting up this morning after running fine for about 3 weeks. Turned out it ran out of free memory and the watchdog had trouble killing it and killed some system processes instead. Checked the other Pis and the ckproxy process was using high amounts of memory. Percentage-wise the memory on most of them had gone over 60%, where on a fresh start it's more around 6-7%.

Edit: To note the Pi that locked up was also the one handling the highest hashrate, so that may be related. Since it ran out of memory while the lower hashrate Pis still had some free.

What about using the /cgi-bin/minerAdvanced.cgi page to underclock? Does that no longer work? Last time I tried it, it said something about taking multiple hours, but it was up and mining in the regular 5-10 mins.

My setup has slush, kano, & solo.ckpool as proxies 0,1, & 2 respectively. Kano lost connectivity or restarted the pool a few hours ago and the proxies switched to it and stayed there for a few hours until I noticed and restarted them.


Slush was still up and running fine the whole time judging by the logs. Is there a way to prevent this switch from happening on a pool restart?

Workers > Shift Graph   put "all" without quotes in input box, make sure it's checked and hit update

Edit: if you mean for the whole pool Pool > Graph

Seems to be working great on RPi3 running 64bit OpenSuse Leap - https://en.opensuse.org/HCL:Raspberry_Pi3

instead of apt-get just run

then follow the rest of the install instructions. Thanks ck!

I don't remember the name, but I think its website had a brownish color scheme. This was more likely late 2011, back when the common pool payout method was proportional (a few had PPS) and pool hopping was a thing. At the tail end of the GPU era with the first BFL FPGAs trickling out.

A few months before, someone (Meni?) had posted proof that hopping was much more profitable and so we were torturing the pools with essentially a miner DDoS right after they found a block to try and get a few shares in any short blocks. It was one of the 8-12 pools I would hop. There were grumblings about how this specific pool never seemed to have really short blocks, and someone looked at the stats to see that indeed there seemed to be a cutoff.

People kept hopping it for a few months and eventually the pool got hacked with it's source leaked showing they would set the payout address to their own on a block change and update it to the pools after some percentage of difficulty had been hashed.

Now this was all years ago and things were changing so fast back then that I'm sure some of the few details I remember are mashed up with other things or out of order. I'm almost certain it was the pool with the brown color scheme, there was another questionable pool that was white with lots of text and charts that was also shady, but lasted much longer.

Yep, this is an old 32 bit Pi. I'll give it a try on 64 bit model 3 with 64bit suse tomorrow and report back.

Tried to set up ckproxy on a Raspberry Pi. Threw these errors while making


Then when run it complains thusly

the NULL errors keep repeating every few seconds.

Is it a lost cause due to the yasm requirement?

Wasn't accusing you specifically, was just commenting on another reason a pool might see horrible luck. I'd venture to guess many miners don't check every piece of hardware for block found counts, and a bmminer restart or hardware reboot will wipe those stats.

It was easier to get away with back when the found block notification would scroll off the screen when you weren't looking.

Or the pool owner decided to snag a block reward for themselves. I hazily recall a pool getting caught out for the statistical improbability of their never finding extremely lucky blocks back around 2012. Turned out the owners were taking all the blocks the pool found below a certain share threshold.

PM me a shipping address and I'll try to get them out Monday or Tuesday.

I've got four S5's sitting in the garage. I think one board was down on one of them but it's been a while so I can't be positive. Are you wanting the whole thing, or just the boards from them?

On a related note, you didn't happen to find a source for the Dell Z750P backplane connectors that was cheaper than multiple dollars each did you?

I remember last time I looked they were wanting $7 a piece or somewhere along those lines and didn't have any in stock, with a backorder time of months.