[POOL][Scrypt][Scrypt-N][X11] Profit switching pool - wafflepool.com

[Zoella]

I'm at 2% rejects after restarting last night (uswest). Used to average less than one on the main server. As soon as the minimum vardiff option goes live I'll restart again and see what happens.

As far as profits vs middlecoin, it has been pretty similar. I'm waiting for the fix on the website, but if the numbers are accurate, my wafflepool hash is doing better than my middlecoin hash for the first time. I've been testing off and on, but tomorrow will be my 6th payout here.

[chilin_dude]

The more new coins you add the better, I think that is what will set the best multipools out from the mediocre, ability to quickly adapt to maximise profit.

[chilin_dude]

Also are you currently only using one exchange? I think the sooner we get more active the better. There are a fair few now, some are slower than others but  I'm sure users are willing to sacrifice an hour or so wait for better btc/mh. https://www.coinmarket.io/ is one such recent exchange.

[phzi]

PoolWaffle: when you implement the ability to specify starting vardiff in the password field, can you please make it a minimum value.  e.g. I say d=512, and that means my vardiff should never change (because max is also 512).  This would be rather ideal for larger miners, as vardiff is quite useless to me, and is just causing rejected shares on occasion.  Having a fixed diff also makes certain rig stats easier to calculate.

[Malaga]

The more new coins you add the better, I think that is what will set the best multipools out from the mediocre, ability to quickly adapt to maximise profit.

Yes i think this too.
There are some altcoins more profitable, i think, than others added in the pool( kittehcoin for example? ), but we don't know if add a coin is so fast, and easy, as we can think.

[poolwaffle]

I have currently a mini-farm pointed to MiddleCoin with a good success rate of earnings.
What can i expect if i move my operation to this pool?

How are the earnings currently?

Obviously varies by day, but our stats page has each of the last 14x24hr periods listed on a per-day, and on a rolling total basis.

Rejected share diff xx/32 ... (Share is above target)
Rejected share diff xx/32 ... (Share is above target)
Rejected share diff xx/32 ... (Share is above target)

Looking at it further (and hearing that its happening more on uswest rather than main), my guess is its an odd interaction between coin switches (which are a bit more aggressive on new endpoints) and vardiff switches.  Just guessing because I haven't personally seen it here as it happens, but guess is that if a vardiff switch happens, and you'd normally be given a grace period of 30 sec, and then a coin switch immediately happens, that it might not be respecting the grace period.  The vardiff d=xxx option in auth will help, so I'll try to get that out today, as it seems like the quickest fix.

Also are you currently only using one exchange? I think the sooner we get more active the better. There are a fair few now, some are slower than others but  I'm sure users are willing to sacrifice an hour or so wait for better btc/mh. https://www.coinmarket.io/ is one such recent exchange.

A few others are in testing, but haven't been actively tested in the last few days since stuff has been coming up.  I was looking at coinmarket.io yesterday, but when I checked, they were down, and then turned into an email mailing list page.  I see they're up now, and I'll see what their API lets us do (see if it does everything we need).  I'd love to get a better exchange in than cryptsy, but every one that I've looked at either has really bad depth (poor prices), or doesn't have a realistic api (coinedup), or doesn't have a bunch of coins that we really need.  Long story short, on the list

PoolWaffle: when you implement the ability to specify starting vardiff in the password field, can you please make it a minimum value.  e.g. I say d=512, and that means my vardiff should never change (because max is also 512).  This would be rather ideal for larger miners, as vardiff is quite useless to me, and is just causing rejected shares on occasion.  Having a fixed diff also makes certain rig stats easier to calculate.

Yep, these will be hard locked to a few allowed values (don't want someone passing d=1 with a 10MH/s rig), probably allowing 128, 256, 512, 1024 to be passed.  Working on it today, might see some quick cutovers on the new endpoints as they add the functionality.

[poolwaffle]

Looking through the coinmarket thread/site, it doesn't look like they have any trade API available yet (point me in the right direction if I missed it).

Which brings up another question.  I'm OK (a bit hesitant) with adding those coins that have to be manually traded (only listed on exchanges without an automated api), but it is doable.  The problem with it is that I really wouldn't be able to trade them off more than once a day (lose too much working time constantly trading), which opens up a TON of market risk on those coins.  And since most of them (since they're not traded on larger exchanges) have low depth, the price change risk is a very real one.

How do you guys prefer to handle these?

[rallasnackbar]

Looking through the coinmarket thread/site, it doesn't look like they have any trade API available yet (point me in the right direction if I missed it).

Which brings up another question.  I'm OK (a bit hesitant) with adding those coins that have to be manually traded (only listed on exchanges without an automated api), but it is doable.  The problem with it is that I really wouldn't be able to trade them off more than once a day (lose too much working time constantly trading), which opens up a TON of market risk on those coins.  And since most of them (since they're not traded on larger exchanges) have low depth, the price change risk is a very real one.

How do you guys prefer to handle these?

I dont think its worth it, we are getting a nice btc per mhash atm, so i dont think its worth your time, or our hashing.


You didnt reply to my last question;

Wouldnt it be possible to make it so, before a payout, it converts the majority of the coins?  I missed a payout with 0.0005 because you moved the payout from 14:30 to 12:00, and had 0.007 unexchanged at the time.

[poolwaffle]

The unexchanged amount there was bugged due to casinocoin, they were literally coins that didn't exist (I had a banner up at the top of the site for a while, a block got processed incorrectly, but has been fixed).

I've been making sure that everything that can be exchanged is exchanged before we actually do a payout.  A lot of the time the unexchanged amount is just delayed by exchanges. Takes X number of confirmations, and that network is slow, or the exchange is slow (looking at you cryptsy), or in the case of some coins (mooncoin specifically), it takes (I think) 50 or 60 confirmations for a block to mature (before we can exchange it), and at 4min per block, you're looking at close to a day and a half before we can convert (and theres really nothing we can do about it).  Essentially, if unconfirmed values miss a payout, they'll be in the next one...

[rallasnackbar]

The unexchanged amount there was bugged due to casinocoin, they were literally coins that didn't exist (I had a banner up at the top of the site for a while, a block got processed incorrectly, but has been fixed).

I've been making sure that everything that can be exchanged is exchanged before we actually do a payout.  A lot of the time the unexchanged amount is just delayed by exchanges. Takes X number of confirmations, and that network is slow, or the exchange is slow (looking at you cryptsy), or in the case of some coins (mooncoin specifically), it takes (I think) 50 or 60 confirmations for a block to mature (before we can exchange it), and at 4min per block, you're looking at close to a day and a half before we can convert (and theres really nothing we can do about it).  Essentially, if unconfirmed values miss a payout, they'll be in the next one...

Ahh okay, didnt know that. Thanks.

[olrosseel]

This is what I have in cgminer, EU endpoint ...

 [2014-02-07 12:29:29] Accepted 1f92c5cb Diff 8/4 GPU 2 pool 0
 [2014-02-07 12:29:29] Accepted 1adee1bf Diff 10/4 GPU 2 pool 0
 [2014-02-07 12:29:29] Rejected 2d6f1652 Diff 6/4 GPU 2 pool 0 (Share is above target)
 [2014-02-07 12:29:29] Accepted 1c7ae39a Diff 9/4 GPU 2 pool 0
 [2014-02-07 12:29:29] Accepted 0af0a85b Diff 23/4 GPU 2 pool 0
 [2014-02-07 12:29:29] Accepted 1b456894 Diff 9/4 GPU 2 pool 0
 [2014-02-07 12:29:30] Rejected 2d98897e Diff 6/4 GPU 0 pool 0(Share is above target)
 [2014-02-07 12:29:30] Accepted 07ed7c28 Diff 32/4 GPU 0 pool 0
 [2014-02-07 12:29:30] Rejected 2154a7e9 Diff 8/4 GPU 0 pool 0 (Share is above target)
 [2014-02-07 12:29:30] Rejected 39e07b72 Diff 4/4 GPU 0 pool 0 (Share is above target)
 [2014-02-07 12:29:30] Accepted 152970be Diff 12/4 GPU 1 pool 0
 [2014-02-07 12:29:30] Accepted 10095ce9 Diff 16/4 GPU 1 pool 0
 [2014-02-07 12:29:30] Rejected 312081cf Diff 5/4 GPU 1 pool 0(Share is above target)
 [2014-02-07 12:29:31] Rejected 2b32f384 Diff 6/4 GPU 2 pool 0 (Share is above target)
 [2014-02-07 12:29:31] Rejected 242cc46a Diff 7/4 GPU 2 pool 0 (Share is above target)
 [2014-02-07 12:29:31] Rejected 2845b4f6 Diff 6/4 GPU 2 pool 0 (Share is above target)
 [2014-02-07 12:29:31] Accepted 15fe3d1b Diff 12/4 GPU 2 pool 0
 [2014-02-07 12:29:31] Rejected 35dac92c Diff 5/4 GPU 2 pool 0 (Share is above target)
 [2014-02-07 12:29:31] Accepted 07aab01d Diff 33/4 GPU 2 pool 0
 [2014-02-07 12:29:31] Accepted 0806df53 Diff 32/4 GPU 0 pool 0
 [2014-02-07 12:29:31] Accepted 05c58882 Diff 44/4 GPU 0 pool 0
 [2014-02-07 12:29:31] Rejected 386cc2ad Diff 5/4 GPU 0 pool 0 (Share is above target)
 [2014-02-07 12:29:31] Rejected 3be1d053 Diff 4/4 GPU 0 pool 0 (Share is above target)
 [2014-02-07 12:29:31] Rejected 242e8c71 Diff 7/4 GPU 1 pool 0 (Share is above target)
 [2014-02-07 12:29:31] Rejected 3912b06a Diff 4/4 GPU 1 pool 0 (Share is above target)
 [2014-02-07 12:29:31] Accepted 1d6db3b7 Diff 9/4 GPU 1 pool 0
 [2014-02-07 12:29:31] Rejected 265b7a23 Diff 7/4 GPU 1 pool 0(Share is above target)
 [2014-02-07 12:29:31] Accepted 041a6f78 Diff 62/4 GPU 1 pool 0
 [2014-02-07 12:29:31] Accepted 11646a78 Diff 15/4 GPU 1 pool 0
 [2014-02-07 12:29:31] Rejected 3bdcc63b Diff 4/4 GPU 1 pool 0 (Share is above target)
 [2014-02-07 12:29:32] Rejected 336e1a01 Diff 5/4 GPU 2 pool 0 (Share is above target)
 [2014-02-07 12:29:32] Accepted 07fd5419 Diff 32/4 GPU 2 pool 0
 [2014-02-07 12:29:32] Accepted 1b8082e4 Diff 9/4 GPU 0 pool 0
 [2014-02-07 12:29:32] Rejected 315a31d3 Diff 5/4 GPU 0 pool 0(Share is above target)
 [2014-02-07 12:29:32] Accepted 0564c9b3 Diff 47/4 GPU 0 pool 0
 [2014-02-07 12:29:32] Accepted 16a140ba Diff 11/4 GPU 0 pool 0
 [2014-02-07 12:29:32] Accepted 1aa2be0f Diff 10/4 GPU 0 pool 0
 [2014-02-07 12:29:32] Rejected 25fdb301 Diff 7/4 GPU 0 pool 0 (Share is above target)

[poolwaffle]

Working on the new difficulty locking/hinting on the new endpoints as we speak (couple hours or so).

In the meantime, can someone seeing this issue ("share above target") restart a miner that normally has a reasonably high difficulty (128+), and try their best to get a log of what time the difficulty adjustment is requested, and what time it takes before the miner starts using the new work difficulty?

Should see something like:
xxx Accepted X/64
xxx Accepted X/64
xxx Accepted X/64
AAA Difficulty changed to 128
xxx Accepted X/64
xxx Accepted X/64
BBB Accepted X/128

I'm looking for the timestamps listed as "AAA" and "BBB" above (when we request a change, and when that change gets applied).  Also, in the same post, cgminer/bfgminer + version + command params (intensity, etc) would be super helpful

[olrosseel]

Working on the new difficulty locking/hinting on the new endpoints as we speak (couple hours or so).

In the meantime, can someone seeing this issue ("share above target") restart a miner that normally has a reasonably high difficulty (128+), and try their best to get a log of what time the difficulty adjustment is requested, and what time it takes before the miner starts using the new work difficulty?

Should see something like:
xxx Accepted X/64
xxx Accepted X/64
xxx Accepted X/64
AAA Difficulty changed to 128
xxx Accepted X/64
xxx Accepted X/64
BBB Accepted X/128

I'm looking for the timestamps listed as "AAA" and "BBB" above (when we request a change, and when that change gets applied).  Also, in the same post, cgminer/bfgminer + version + command params (intensity, etc) would be super helpful

cgminer 3.7.2
"intensity" : "20"
"worksize" : "512"
"gpu-engine" : "1000"
"thread-concurrency" : "32765"
"gpu-memclock" : "1500"

I think here are some timestamps ...

 [2014-02-07 12:46:46] Stratum from pool 0 detected new block
 [2014-02-07 12:46:58] Pool 0 difficulty changed to 128
 [2014-02-07 12:46:58] Accepted 2d8eba23 Diff 1.44K/256 GPU 2 pool 0
 [2014-02-07 12:47:03] Accepted cd2c2c1a Diff 319/256 GPU 0 pool 0
 [2014-02-07 12:47:04] Accepted 7554ee68 Diff 559/256 GPU 1 pool 0
 [2014-02-07 12:47:05] Accepted 1c980d3b Diff 2.29K/256 GPU 0 pool 0
 [2014-02-07 12:47:10] Network diff set to 10
 [2014-02-07 12:47:10] Stratum from pool 0 detected new block
 [2014-02-07 12:47:14] Accepted 01a6860f Diff 155/128 GPU 0 pool 0
 [2014-02-07 12:47:14] Accepted e3e28e1d Diff 288/128 GPU 2 pool 0
 [2014-02-07 12:47:14] Accepted 01df652b Diff 35K/128 GPU 2 pool 0
 [2014-02-07 12:47:16] Network diff set to 10
 [2014-02-07 12:47:16] Stratum from pool 0 detected new block
 [2014-02-07 12:47:18] Stratum from pool 0 requested work restart
 [2014-02-07 12:47:18] Pool 0 stale share detected, submitting as user requested
[2014-02-07 12:47:18] Pool 0 difficulty changed to 512
 [2014-02-07 12:47:18] Accepted 01d617b5 Diff 139/128 GPU 1 pool 0
 [2014-02-07 12:47:23] Rejected 8cb7f85f Diff 466/128 GPU 1 pool 0 (Share is above target)
 [2014-02-07 12:47:29] Rejected 010fa33d Diff 241/128 GPU 1 pool 0 (Share is above target)
 [2014-02-07 12:47:30] Accepted 0b0703ce Diff 5.94K/128 GPU 0 pool 0
 [2014-02-07 12:47:38] Rejected 016b1ed2 Diff 180/128 GPU 1 pool 0 (Share is above target)
 [2014-02-07 12:47:39] Rejected 01ee94fd Diff 133/128 GPU 2 pool 0 (Share is above target)
 [2014-02-07 12:47:46] Accepted 11d084a2 Diff 3.68K/128 GPU 2 pool 0
 [2014-02-07 12:47:47] Accepted 1128e02e Diff 3.82K/128 GPU 0 pool 0
 [2014-02-07 12:47:57] Accepted 2504ddba Diff 1.77K/128 GPU 0 pool 0
 [2014-02-07 12:47:57] Rejected 01e948a9 Diff 134/128 GPU 1 pool 0 (Share is above target)
 [2014-02-07 12:48:08] Rejected f699ddb9 Diff 266/128 GPU 0 pool 0 (Share is above target)
 [2014-02-07 12:48:11] Rejected 91481fd8 Diff 451/128 GPU 2 pool 0 (Share is above target)
 [2014-02-07 12:48:12] Rejected 01e97de1 Diff 134/128 GPU 1 pool 0 (Share is above target)
 [2014-02-07 12:48:12] Rejected 01702e2d Diff 178/128 GPU 1 pool 0 (Share is above target)
 [2014-02-07 12:48:15] Rejected 01a9b102 Diff 154/128 GPU 2 pool 0 (Share is above target)
 [2014-02-07 12:48:16] Rejected 013723ca Diff 211/128 GPU 2 pool 0 (Share is above target)
[2014-02-07 12:48:25] Accepted 3ae92a4c Diff 1.11K/512 GPU 1 pool 0
 [2014-02-07 12:48:38] Accepted 13a12c10 Diff 3.34K/512 GPU 1 pool 0
 [2014-02-07 12:48:41] Accepted 72cfa1a3 Diff 571/512 GPU 2 pool 0

[poolwaffle]

Definitely think it has something to do with coin switches at the same time as diff switches (during the grace period).

That said, 2 new password features have been added and spooled up on NEW endpoints (not on old endpoints, they're being phased out in a day or so).

On the new endpoints (useast, uswest, eu), you can now set your password as "d=XXX" or "h=XXX".

XXX being the difficulty you'd like to use.  In the case of "d=" it is a hardcoded value, and your difficulty should never change (hard-locked difficulty), in the case of "h=" it is given as a HINT, instead of starting at the server default on start (16), you'll start at the XXX, but still use vardiff.  "h=" uses vardiff, "d=" does not.

Valid values for XXX are 64, 128, 256, 512, 1024.  Don't want to add lower to avoid flooding with tons of low difficulty shares.

A good rule of thumb for difficulties (rough values) for mining speeds:
0kH-500kH: default
500kH-1MH: 64
1-2MH: 128
2-3MH: 256
3-5MH: 512
5+MH: 1024

Let me know if these are working for you guys.

[rallasnackbar]

Definitely think it has something to do with coin switches at the same time as diff switches (during the grace period).

That said, 2 new password features have been added and spooled up on NEW endpoints (not on old endpoints, they're being phased out in a day or so).

On the new endpoints (useast, uswest, eu), you can now set your password as "d=XXX" or "h=XXX".

XXX being the difficulty you'd like to use.  In the case of "d=" it is a hardcoded value, and your difficulty should never change (hard-locked difficulty), in the case of "h=" it is given as a HINT, instead of starting at the server default on start (16), you'll start at the XXX, but still use vardiff.  "h=" uses vardiff, "d=" does not.

Valid values for XXX are 64, 128, 256, 512, 1024.  Don't want to add lower to avoid flooding with tons of low difficulty shares.

A good rule of thumb for difficulties (rough values) for mining speeds:
0kH-500kH: default
500kH-1MH: 64
1-2MH: 128
2-3MH: 256
3-5MH: 512
5+MH: 1024

Let me know if these are working for you guys.

Just updated my worker with the new h= data, and eu server. So good it looks fine.

[poolwaffle]

Sorry for posting multiple in a row, just a decent number of things happening at a time, and don't want to keep you guys in the dark

Later tonight (6hrs from now or so) we'll start removing some coins (see previous post for reasons: https://bitcointalk.org/index.php?topic=433634.msg4976961#msg4976961).

The expected coins to be removed, unless someone has a good reason not to (please post!):
Coin, Removal Likeliness, Reason:
Fastcoin, extremely, block times are too fast to do with any latency whatsoever - pooling pretty much kills it.
Galaxycoin, extremely, hasn't been profitable since Jan 5th, diff retarget way too fast to actually switch to it...
Hobonickles, extremely, fast block times, rarely profitably by more than a slight margin when it is, daemon is very heavy (huge blockchain)
Emerald, extremely, very fast block times (20s), difficult to pool mine...
Bitbar, very, hasn't been profitable since Jan 15th
Casinocoin, very, fast block times (30s) and highest orphan rate that we have (12%)
Feathercoin, very, hasn't ever been profitable (since pool up) - unlikely to change
Worldcoin, moderate, fast block times (30s) and 2nd highest orphan rate (10%)
Litecoin, moderate, hasn't ever been profitable (since pool up) - unlikely to change, can add back if it does

Comments?  Reasons I shouldn't remove any of these?

[skabbo]

Sorry for posting multiple in a row, just a decent number of things happening at a time, and don't want to keep you guys in the dark

Later tonight (6hrs from now or so) we'll start removing some coins (see previous post for reasons: https://bitcointalk.org/index.php?topic=433634.msg4976961#msg4976961).

The expected coins to be removed, unless someone has a good reason not to (please post!):
Coin, Removal Likeliness, Reason:
Fastcoin, extremely, block times are too fast to do with any latency whatsoever - pooling pretty much kills it.
Galaxycoin, extremely, hasn't been profitable since Jan 5th, diff retarget way too fast to actually switch to it...
Hobonickles, extremely, fast block times, rarely profitably by more than a slight margin when it is, daemon is very heavy (huge blockchain)
Emerald, extremely, very fast block times (20s), difficult to pool mine...
Bitbar, very, hasn't been profitable since Jan 15th
Casinocoin, very, fast block times (30s) and highest orphan rate that we have (12%)
Feathercoin, very, hasn't ever been profitable (since pool up) - unlikely to change
Worldcoin, moderate, fast block times (30s) and 2nd highest orphan rate (10%)
Litecoin, moderate, hasn't ever been profitable (since pool up) - unlikely to change, can add back if it does

Comments?  Reasons I shouldn't remove any of these?

Personally I'm fine with these choices, but I've seen a few people giving reasons for keeping LTC in the equation.  It's never the most profitable, but it tends to stay at its middling profitability even when everything else drops, so on dismal days (like last weekend) it might be the lesser of two evils.  That's its only use I can see though - as a fallback. 

[Zoella]

Sorry for posting multiple in a row, just a decent number of things happening at a time, and don't want to keep you guys in the dark

Later tonight (6hrs from now or so) we'll start removing some coins (see previous post for reasons: https://bitcointalk.org/index.php?topic=433634.msg4976961#msg4976961).

The expected coins to be removed, unless someone has a good reason not to (please post!):
Coin, Removal Likeliness, Reason:
Fastcoin, extremely, block times are too fast to do with any latency whatsoever - pooling pretty much kills it.
Galaxycoin, extremely, hasn't been profitable since Jan 5th, diff retarget way too fast to actually switch to it...
Hobonickles, extremely, fast block times, rarely profitably by more than a slight margin when it is, daemon is very heavy (huge blockchain)
Emerald, extremely, very fast block times (20s), difficult to pool mine...
Bitbar, very, hasn't been profitable since Jan 15th
Casinocoin, very, fast block times (30s) and highest orphan rate that we have (12%)
Feathercoin, very, hasn't ever been profitable (since pool up) - unlikely to change
Worldcoin, moderate, fast block times (30s) and 2nd highest orphan rate (10%)
Litecoin, moderate, hasn't ever been profitable (since pool up) - unlikely to change, can add back if it does

Comments?  Reasons I shouldn't remove any of these?

I have no real reason not to remove any, but it seems like a large percentage of coins to remove at once. Why not remove the "extremely" now, then give it a week or two before removing the "very".

Just restarted with h=128 on uswest. Will probably test 256 and p=128/256 over the coming days depending on reject %.

Thanks for the updates!

[ycsi]

The expected coins to be removed, unless someone has a good reason not to (please post!):
Coin, Removal Likeliness, Reason:
.
.
.
Litecoin, moderate, hasn't ever been profitable (since pool up) - unlikely to change, can add back if it does

Comments?  Reasons I shouldn't remove any of these?

Would leaving LTC on the list affect negatively anything in the pool?
It's probably better to leave it on for those odd days when all other currencies collapse...

[Zamboniman]

Looks like there's still some glitches with the new difficulty settings.

I used h=64 on uswest, but right now it's at difficulty 32. I thought it wasn't supposed to go lower than the "h=xx" setting?

EDIT: Now it's back up to 64, so it didn't stay on 32 very long, but it was there for a few minutes.