 Show Posts
|
|
Pages: [1] 2 3 »
|
|
1
|
Bitcoin / Pools / Re: [70+PH] KanoPool kano.is 0.9% PPLNS US,DE,SG,JP,NL,NYA 🐈
|
on: June 01, 2017, 10:24:35 PM
|
|
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.
|
|
|
|
|
2
|
Bitcoin / Hardware / Re: [Help]S9 hashing power droping to 0ths or 8 ths
|
on: May 06, 2017, 03:56:58 AM
|
|
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.
|
|
|
|
|
3
|
Bitcoin / Hardware / Re: Foxminers?
|
on: April 25, 2017, 04:31:47 AM
|
Did you go to the address behind McDonalds as well? That's the one they list in their footer. |
|
|
|
|
6
|
Bitcoin / Pools / Re: [30+PH] KanoPool kano.is 0.9% PPLNS US,DE,SG,JP,NL,NYA
|
on: April 03, 2017, 06:19:13 AM
|
You can't.
A share is associated with a work item - and it can't pretend to be associated with a different one.
That work item has a difficulty that the pool assigns.
The work item is of course also unique per 'worker'.
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. |
|
|
|
|
7
|
Bitcoin / Pools / Re: [30+PH] KanoPool kano.is 0.9% PPLNS US,DE,SG,JP,NL,NYA
|
on: April 03, 2017, 06:12:05 AM
|
...
The stolen shares are, in most cases, far above.. NOT below the current difficulty. Think about it. If you found a share that was hundreds of times the current difficulty, wouldn't you want to save it ?
...
Lulz no idea what you been smoking to confuse you, but a share is only worth the value of the work it was generated for, and a valid block share is only worth a block no matter what difficulty it is (as long as it's a block). ... and if a block is not submitted immediately, it's worth nothing if someone else finds a block while you procrastinate, so no you wouldn't save it - that's stupid. If a share is worse than the requested work difficulty, it's worth nothing. If a share is better than or equal to the requested work difficulty, it's only worth the requested work difficulty. 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. |
|
|
|
|
8
|
Bitcoin / Mining software (miners) / Re: CKPOOL - Open source pool/database/proxy/passthrough/library in c for Linux
|
on: March 29, 2017, 01:04:10 AM
|
|
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.
|
|
|
|
|
9
|
Bitcoin / Hardware / Re: Throttling back miners with motion sensor
|
on: March 27, 2017, 07:51:59 PM
|
|
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.
|
|
|
|
|
10
|
Bitcoin / Mining software (miners) / Re: CKPOOL - Open source pool/database/proxy/passthrough/library in c for Linux
|
on: March 15, 2017, 08:00:09 PM
|
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. [2017-03-15 18:11:57.400] Proxy:{"current": 0, "active": 3, "total": 3}
[2017-03-15 18:12:34.834] Proxy 1:0 stratum+tcp://stratum.kano.is:3333 failed to read_socket_line in proxy_recv
[2017-03-15 18:12:34.834] Proxy 1:0 stratum+tcp://stratum.kano.is:3333 epoll hangup in proxy_recv
[2017-03-15 18:12:34.834] Proxy 1:stratum+tcp://stratum.kano.is:3333 failed, attempting reconnect
[2017-03-15 18:12:39.010] Found notify for new proxy 1:0 with enonce 159c0d5d nonce2len 8
[2017-03-15 18:12:39.010] Got updated subscribe for proxy 1
[2017-03-15 18:12:39.010] Upstream pool stratum+tcp://stratum.kano.is:3333 1 extranonce2 length 8, max proxy clients 4294967296
[2017-03-15 18:12:39.010] Stratifier setting active proxy to 1
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? |
|
|
|
|
13
|
Bitcoin / Pools / Re: [25+PH] KanoPool kano.is 0.9% PPLNS US,DE,SG,JP,NL,NYA 🐈
|
on: March 05, 2017, 06:50:23 PM
|
if they toss back to back that is 1 in 10000 chance my guess is the pool has
bad code
bad server
bad internet
or bad gear mining on it.
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. Do you remember which pool? 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. |
|
|
|
|
15
|
Bitcoin / Mining software (miners) / Re: CKPOOL - Open source pool/database/proxy/passthrough/library in c for Linux
|
on: March 05, 2017, 09:16:23 AM
|
Tried to set up ckproxy on a Raspberry Pi. Threw these errors while making stratifier.c: In function ‘read_userstats’:
stratifier.c:5126:2: warning: passing argument 1 of ‘json_get_int64’ from incompatible pointer type [enabled by default]
ckpool.h:371:6: note: expected ‘int64_t *’ but argument is of type ‘__time_t *’
stratifier.c: In function ‘read_workerstats’:
stratifier.c:5179:2: warning: passing argument 1 of ‘json_get_int64’ from incompatible pointer type [enabled by default]
ckpool.h:371:6: note: expected ‘int64_t *’ but argument is of type ‘__time_t *’
stratifier.c: In function ‘read_poolstats’:
stratifier.c:8487:2: warning: passing argument 1 of ‘json_get_int64’ from incompatible pointer type [enabled by default]
ckpool.h:371:6: note: expected ‘int64_t *’ but argument is of type ‘__time_t *’
Then when run it complains thusly [2017-03-05 01:13:19.278] ckproxy stratifier ready
[2017-03-05 01:13:19.397] Invalid json line:1 col:14 pos:14 text: NULL string argument from generator.c send_subscribe:1485
[2017-03-05 01:13:19.400] Failed to json decode subscribe response in update_subscribe (null)
[2017-03-05 01:13:19.403] Invalid json line:1 col:4 pos:4 text: NULL string argument from generator.c send_diff:1251
[2017-03-05 01:13:19.406] Failed to json decode in update_diff
[2017-03-05 01:13:19.409] Invalid json line:1 col:4 pos:4 text: NULL string argument from generator.c send_notify:1278 with errno 11: Resource temporarily unavailable
[2017-03-05 01:13:19.412] Failed to json decode in update_notify
[2017-03-05 01:13:19.414] Invalid json line:1 col:4 pos:4 text: NULL string argument from generator.c send_diff:1251 with errno 11: Resource temporarily unavailable
[2017-03-05 01:13:19.417] Failed to json decode in update_diff
the NULL errors keep repeating every few seconds. Is it a lost cause due to the yasm requirement? |
|
|
|
|
16
|
Bitcoin / Pools / Re: [25+PH] KanoPool kano.is 0.9% PPLNS US,DE,SG,JP,NL,NYA 🐈
|
on: March 05, 2017, 06:05:46 AM
|
if they toss back to back that is 1 in 10000 chance my guess is the pool has
bad code
bad server
bad internet
or bad gear mining on it.
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. I'd also have to somehow stop the person who found the block from knowing they found it on their miner  Now that would be a tricky thing to do unless Bitmain put something into their bmminer to hide blocks ... ... ... ... ... Low % blocks ... 3 in the last 100 are: 1.774% 1.175% 1.141% ... 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. |
|
|
|
|
17
|
Bitcoin / Pools / Re: [25+PH] KanoPool kano.is 0.9% PPLNS US,DE,SG,JP,NL,NYA 🐈
|
on: March 05, 2017, 12:42:11 AM
|
if they toss back to back that is 1 in 10000 chance my guess is the pool has
bad code
bad server
bad internet
or bad gear mining on it.
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. |
|
|
|
|
20
|
Bitcoin / Hardware / Re: DIY PCI-e cables for S5, S7, R4 and S7 ASIC
|
on: February 21, 2017, 07:27:42 PM
|
For a big order like that I can give a pretty good discount. Message me if you want to talk details.
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. |
|
|
|
|
