[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool

[RedBill]

Is there currently any problem with Slush? Front page is slugish and payout's not working (payout limit passed but still no payout).

Edit: site start to work normally. Still - payouts are not processed. Whats Your status?

+1

No payout. This is happening a lot recently, especially overnight in Europe.

Edit: OK now.

[1715155935]

1715155935

[1715155935]

1715155935

[vpasic]

need some help...
I'm using 2 x 60GH singles with BFGminer, all working fine but couple of hrs ago I start getting a lot of "accepted" in BFGminer (7-10//sec) and my rewards become much smaller (0.008-0.009).
usually it was like 1 or 2 "accepted" every 2-3 seconds and 0.012-0.014 rewards.
what the hell?? anyway I can set pool diff manually?

[gourmet]

need some help...
I'm using 2 x 60GH singles with BFGminer, all working fine but couple of hrs ago I start getting a lot of "accepted" in BFGminer (7-10//sec) and my rewards become much smaller (0.08-0.09).
usually it was like 1 or 2 "accepted" every 2-3 seconds and 0.012-0.014 rewards.
what the hell?? anyway I can set pool diff manually?

0.08-0.09 is not smaller than your usually 0.012-0.014.

[juhakall]

need some help...
I'm using 2 x 60GH singles with BFGminer, all working fine but couple of hrs ago I start getting a lot of "accepted" in BFGminer (7-10//sec) and my rewards become much smaller (0.08-0.09).
usually it was like 1 or 2 "accepted" every 2-3 seconds and 0.012-0.014 rewards.
what the hell?? anyway I can set pool diff manually?

0.08-0.09 is not smaller than 0.012-0.014.

That must be because slush removed the manual difficulty setting that was previously working just fine. It's now replaced with vardiff. When your connection resets the miner starts flooding low difficulty shares. All pools should really support a minimum difficulty setting, not doing so is just asking for problems like this.

[gourmet]

Could someone with a bit of knowledge of this pool explain to me a little about the API?
Im trying to monitor the generated BTC once an hour, and unlike most pools i'd use theres no total paid out value in there, and im struggling to understand which specific stats i want to be using to get an accurate measurement of income.

Currently im using 'confirmed rewards', and im running a check on the last db entry to see if that figure has decreased then it must have meant a payment has been sent, in which case i increase the db's total payout to += 'send_threshold'.

I thought that would be correct, however about 2hr ago my db stats went from:

16:00 UTC
Confirmed: 0.31413209
Total Payout: 0.00000000
Hourly update: 0.00000000 (no block solved)

17:00 UTC
Confirmed: 0.04204677
Total Payout: 0.25000000
Hourly update: -0.02208532

18:00 UTC
Confirmed: 0.13160902
Total Payout: 0.25000000
Hourly update: 0.08956225

Now, this has happened because rather than simply paying out based on the threshold, its paid more (0.31), however there doesnt appear to be anything in the API which tells me there has been any payment, and it means my attempt to code something in to respond to the fact that there isnt a total paid out statistic, is completely useless because if it sends 0.31btc i only know this by manually looking, and i have to go fumbling through the database to fix this.
Has anyone found a solution which allows for the funds to be properly monitored, i genuinely thought with the 'send_threshold' it'd work, but its not much use really, its just another snippet of information rather than being a valuable means of circumventing the lack of 'total_payout' on the account & API.

Threshold means nothing different but threshold. You couldn't suppose the payout amount will be equal to that number. When the threshold level is crossed, all confirmed reward is paid out.
You have probably lowered the threshold value manually at the beginning of your experiment, when there was 0.31 btc confirmed reward already, so that amount has been all paid out. No wonder. Everything is OK.

[Mudbankkeith]

need some help...
I'm using 2 x 60GH singles with BFGminer, all working fine but couple of hrs ago I start getting a lot of "accepted" in BFGminer (7-10//sec) and my rewards become much smaller (0.08-0.09).
usually it was like 1 or 2 "accepted" every 2-3 seconds and 0.012-0.014 rewards.
what the hell?? anyway I can set pool diff manually?

0.08-0.09 is not smaller than 0.012-0.014.

That must be because slush removed the manual difficulty setting that was previously working just fine. It's now replaced with vardiff. When your connection resets the miner starts flooding low difficulty shares. All pools should really support a minimum difficulty setting, not doing so is just asking for problems like this.

A challenge for Slush:-
To complement the "Vardiff" we need a user "Mindiff"

[vpasic]

need some help...
I'm using 2 x 60GH singles with BFGminer, all working fine but couple of hrs ago I start getting a lot of "accepted" in BFGminer (7-10//sec) and my rewards become much smaller (0.08-0.09).
usually it was like 1 or 2 "accepted" every 2-3 seconds and 0.012-0.014 rewards.
what the hell?? anyway I can set pool diff manually?

0.08-0.09 is not smaller than your usually 0.012-0.014.

My bad I meant 0.008-0.009

[gourmet]

need some help...
I'm using 2 x 60GH singles with BFGminer, all working fine but couple of hrs ago I start getting a lot of "accepted" in BFGminer (7-10//sec) and my rewards become much smaller (0.08-0.09).
usually it was like 1 or 2 "accepted" every 2-3 seconds and 0.012-0.014 rewards.
what the hell?? anyway I can set pool diff manually?

0.08-0.09 is not smaller than 0.012-0.014.

That must be because slush removed the manual difficulty setting that was previously working just fine. It's now replaced with vardiff. When your connection resets the miner starts flooding low difficulty shares. All pools should really support a minimum difficulty setting, not doing so is just asking for problems like this.

A challenge for Slush:-
To complement the "Vardiff" we need a user "Mindiff"

User adjustable lowest difficulty would be fine.
Currently, there's a setting of the VarDiff that sets the difficulty to 3 at the beginning. Then, the difficulty is set to a different value after some time interval, according to the number of shares obtained by the server during that time.  I.e. e.g. when no diff 3 shares arrive, the difficulty is set to 1. :-)

[Threader]

3 invalid blocks in less than 24 hours 

20538    2013-10-23 03:28:34    0:23:53    83222522    58748    0.01833783    265441    25.23686743    invalid

20534    2013-10-23 00:35:43    0:05:32    18859435    14630    0.01932590    265419    25.21232224    invalid

20521    2013-10-22 15:39:53    2:03:54    428492037    304742    0.01837904    265340    25.10731468    invali

Not liking it. Switched half my miners to another pool to balance.

If this continues I may have to leave completely until this is resolved.

[threedrules]

uhm invalid blocks happen because they are orphaned or someone else was first, not much can be done to resolve this

[eleuthria]

uhm invalid blocks happen because they are orphaned or someone else was first, not much can be done to resolve this

Better connected/faster servers reduce it a lot.  3 orphans in 24 hours is seems extremely high given the size of the pool.  Orphan rates should be <1%.  Obviously a given sample may have much more than 1% just due to lack of # of rounds being evaluated.  Maybe organofcorti can shed some light on the probabilities.

EDIT:  2 of the 3 orphans were never even seen by Blockchain.info...that points to serious server issues.  These blocks were either never broadcast, or were broadcast well after the prior block (meaning no connected peers accepted it and rebroadcasted).  The timestamp on 265441 was more than 1 minute after the competing block was seen by Blockchain.info.  The timestamp on 265419 was almost 4 minutes after.  This may not be the real delay due to ntime rolling/slush's poold configuration/where the table get it's timestamp from.  But those are both blocks that were not even seen by the rest of the network apparently.

[VeeMiner]

uhm invalid blocks happen because they are orphaned or someone else was first, not much can be done to resolve this

Better connected/faster servers reduce it a lot.  3 orphans in 24 hours is seems extremely high given the size of the pool.  Orphan rates should be <1%.  Obviously a given sample may have much more than 1% just due to lack of # of rounds being evaluated.  Maybe organofcorti can shed some light on the probabilities.

EDIT:  2 of the 3 orphans were never even seen by Blockchain.info...that points to serious server issues.  These blocks were either never broadcast, or were broadcast well after the prior block (meaning no connected peers accepted it and rebroadcasted).  The timestamp on 265441 was more than 1 minute after the competing block was seen by Blockchain.info.  The timestamp on 265419 was almost 4 minutes after.  This may not be the real delay due to ntime rolling/slush's poold configuration/where the table get it's timestamp from.  But those are both blocks that were not even seen by the rest of the network apparently.

Darn

[zvs]

uhm invalid blocks happen because they are orphaned or someone else was first, not much can be done to resolve this

Better connected/faster servers reduce it a lot.  3 orphans in 24 hours is seems extremely high given the size of the pool.  Orphan rates should be <1%.  Obviously a given sample may have much more than 1% just due to lack of # of rounds being evaluated.  Maybe organofcorti can shed some light on the probabilities.

EDIT:  2 of the 3 orphans were never even seen by Blockchain.info...that points to serious server issues.  These blocks were either never broadcast, or were broadcast well after the prior block (meaning no connected peers accepted it and rebroadcasted).  The timestamp on 265441 was more than 1 minute after the competing block was seen by Blockchain.info.  The timestamp on 265419 was almost 4 minutes after.  This may not be the real delay due to ntime rolling/slush's poold configuration/where the table get it's timestamp from.  But those are both blocks that were not even seen by the rest of the network apparently.

Yeah, none of them show up on my log. 

No clue what happened with those... from what I've seen over the last 18 months or so, Slush very rarely gets orphans.

I did notice this:

2013-10-23 19:22:43 received block 00000000000000051a828b0196663b7b82f33d9ec386e9da0a7d12c36f7c051b
2013-10-23 19:22:43 SetBestChain: new best=00000000000000051a828b0196663b7b82f33d9ec386e9da0a7d12c36f7c051b  height=265588  log2_work=73.094444  tx=25887076  date=2013-10-23 19:22:38 progress=0.999999
2013-10-23 19:22:55 received block 00000000000000051a828b0196663b7b82f33d9ec386e9da0a7d12c36f7c051b
2013-10-23 19:22:55 ERROR: ProcessBlock() : already have block 265588 00000000000000051a828b0196663b7b82f33d9ec386e9da0a7d12c36f7c051b
2013-10-23 19:24:29 received block 00000000000000051a828b0196663b7b82f33d9ec386e9da0a7d12c36f7c051b
2013-10-23 19:24:29 ERROR: ProcessBlock() : already have block 265588 00000000000000051a828b0196663b7b82f33d9ec386e9da0a7d12c36f7c051b

this earlier block is more like it usually is:

2013-10-22 15:59:49 received block 000000000000000a53c17f3837f4a9b058eff44a8e0691074253214db196496b
2013-10-22 15:59:49 SetBestChain: new best=000000000000000a53c17f3837f4a9b058eff44a8e0691074253214db196496b  height=265348  log2_work=73.054409  tx=25822202  date=2013-10-22 15:59:43 progress=1.000000
2013-10-22 15:59:50 received block 000000000000000a53c17f3837f4a9b058eff44a8e0691074253214db196496b
2013-10-22 15:59:50 ERROR: ProcessBlock() : already have block 265348 000000000000000a53c17f3837f4a9b058eff44a8e0691074253214db196496b

[Trongersoll]

Anybody has problem enabling payout address protection by two-factor authentication? I've tried more than once but still I get invalid token?

sorry if already answered but I've just skimmed through the last 5 pages and I didn't find anything.

I couldn't get it to work, I don't have a smart phone.

[kkurtmann]

I would rather use a YubiKey than Google Authenticator, not that I don't trust Google but...

[CMMPro]

What happened to 20553? I got nothing...my miner was running full tilt 280gh but it says I have no submitted shares for an hour?

Edit: Fixed itself....I should know better.

[sickpig]

I would rather use a YubiKey than Google Authenticator, not that I don't trust Google but...

don't use google auth, there are plenty of other solutions that implement two-factort auth

[sickpig]

Anybody has problem enabling payout address protection by two-factor authentication? I've tried more than once but still I get invalid token?

sorry if already answered but I've just skimmed through the last 5 pages and I didn't find anything.

I couldn't get it to work, I don't have a smart phone.

ROTFL

[sickpig]

another invalid 265711

http://blockchain.info/block/00000000000000077a9e21f7e41a3aa5008d843a438ef8952777b4c6ca3422fa?site=slush

[CMMPro]

I saw that too just now....what's with the invalid blocks lately?