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

[bobR]

Let's discuss about bitcoinpool.org on it's own thread, thank you.

Btw you can use fairuser's miner with my pool too. It is m0mchil's miner with few bullshits around. Then you can achieve the same 'high efficiency' also with my pool. But I don't recommend this to anybody not because I'm jealous to fairuser's pool, but simply because it is bad for YOU and using this modified miner, you are shooting to your leg. It is mathematically approved.

Like taking from early shares to correct a PROBLEM is right
and What happened to the only 1% charge
free & equal seems better to me

[1714784100]

1714784100

[1714784100]

1714784100

[1714784100]

1714784100

[1714784100]

1714784100

[BitterTea]

Devil is in the details. http://bitcoinpool.com/faq.php

Q: What happens if we solve a block with transaction fees on it? [TOP]

We keep them. Transaction fees are generally fairly small, and since we don't charge donations, we feel it's a small sacrifice to make in order to keep things Free™

I'm pretty sure all mining pools keep the transaction fees. Compared to the 50 BTC payout, they are basically nothing.

Like taking from early shares to correct a PROBLEM is right
and What happened to the only 1% charge
free & equal seems better to me

You're free to use any one of the other pools. Also, you still make as little sense as I remember.

[Anonymous]

The 2% donation is better than the other pool's 3% donation. We have competition!

We do not force donations on bitcoinpool.com.  That's a big 0%. 

You get what you pay for.....

[slush]

I'd like to announce new experimental feature, which is available on pool from today: long polling

Current "getwork" protocol is not effective enough - every miner is polling pool for new jobs once per few seconds. More frequent requests makes unnecessary network overhead and may slow down overall hashing speed because of network latency. On other side, longer "ask rate" leads to more stale shares (shares, which cannot be valid blocks, because in meantime new bitcoin block appeared on network).

Long polling is simple extension on top of current getwork protocol. Miner opens second connection to pool and pool keeps this request until new block on bitcoin network come (or up to 60 second timeout). Pool then immediately broadcast new jobs to miners in HTTP response of this "extra" connection. Thanks to this improvement, frequent "ask rate" is not necessary; with long polling mode enabled, miner can crunch hashes for whole nonce range (or 60 second timeout, which come first). This leads to higher mining efficiency, less network overhead and less pool load.

Updated miner software is everything you need to enjoy this feature. Currently, only m0mchil's poclbm miner has long polling support and there are also some known (minor) bugs. Please consider this as public beta testing and report all troubles to me or to m0mchil. Please note that pool is already sending special customized getwork response to support long polling by default, but latest poclbm cannot switch modes from command line yet, so you have to use older poclbm (version before 12/03/2011) to disable long polling feature.

Also all miner developers are welcome to support long polling in their software - it can brings crucial improvement especially for CPU mining.

[urizane]

OK, I've switched over to m0mchil's OpenCL miner.  Being an nVidia owner, this sets me back only by 3 MHash/s from puddinpop's CUDA RPC miner.

[Dude65535]

poclbm is showing several instances of invalid or stale shares 4-25 seconds after a "long poll: new block" message. I assume that shouldn't be happening? I also have cases of a valid share as soon as 1 second after a long poll message.

[slush]

poclbm is showing several instances of invalid or stale shares 4-25 seconds after a "long poll: new block" message. I assume that shouldn't be happening? I also have cases of a valid share as soon as 1 second after a long poll message.

Yes, I discovered problem in long polling loadbalancer, it unfortunately sometimes serve jobs from wrong backend (and then submitting those shares to correct backend leads to stale shares). I temporary turned long polling off and I will play with a configuration a little.

[urizane]

I have a question for slush.  I'm not sure if you're familiar with rpcminer-cuda and its console output, but I'm beginning to wonder if I'll never see a message similar to m0mchil's OpenCL miner relating to stale shares.  The only messages I see are similar to:

Sending to server: {"method":"getwork","params":["<insert insanely long hex blob here>"],"id":1}
Server sent: {"result": true, "id": "1", "error": null}

Is the fact that I'm never seeing "result": false indicating that I don't produce stale shares or is the miner just not telling me about them?  (What I don't know won't hurt me, right?)

Also, since long polling got pulled (no pun intended) I've gone back to the CUDA miner as you can probably tell.  I've changed the ask rate from 4 seconds to 8 seconds and I'm still not seeing any stale messages.

[slush]

Sending to server: {"method":"getwork","params":["<insert insanely long hex blob here>"],"id":1}
Server sent: {"result": true, "id": "1", "error": null}

I'm not familiar with this miner, but this dump looks fine for me. Yes, result: false means stale share, so if you don't see them, everything is fine.

With getwork protocol, some rate of stale shares is normal. You can calculate expected share ratio by taking average time between bitcoin blocks and your typical ask rate. Then askrate/avgblocktime = probability to hit stale share. So if you're using default settings, it should be typically something like 5/600 = 0.8%. But this may slightly differ time to time. For example, with current difficulty and hash rate, average time between blocks is longer than 600 seconds (thanks to recent operation of "mystery miner"), which also leads in slightly lower stale rate.

[urizane]

OK, well the upshot is that I'm producing valid shares, which is great.  I'm just not sure that I've ever seen anything except a valid share running this miner on my machine, even now that I've changed the ask rate to 8 seconds.  Maybe it's just sooo unlikely that I never see it.  Maybe the next time I restart these two miners, I'll dump the output to a text file and search for false.

Also, I'm not too sure I get the "mystery miner" bit, but I have noticed a chunk of time just under 2 hours where 18 blocks were found.  If it keeps up, 2000 blocks might happen really soon.

EDIT: Not long after I posted this, BAM!  I found ONE.

Code:

Sending to server: {"method":"getwork","params":["0000000142c744096ad91d977e2211
b86c8008a4453e8568ab7438f00000705e0000000035cdacbf9cbe69e72df8655d731382a4761630
561eda1ea1c8e6ce45092d9ce94d7b7ce21b00dc313af37b13000000800000000000000000000000
000000000000000000000000000000000000000000000000000000000080020000"],"id":1}
Server sent: {"result": false, "id": "1", "error": null}

It happend at 14:02:17, immediately following a block found at 14:02:11.  I guess that's the proof I was looking for.

[slush]

Also, I'm not too sure I get the "mystery miner" bit, but I have noticed a chunk of time just under 2 hours where 18 blocks were found.  If it keeps up, 2000 blocks might happen really soon.

Yes, there was peak in network hashrate last week, somebody pulled ~400Ghash/s into the network. This lead to higher difficulty. Now the network hashspeed is back to lower value, so difficulty is higher than should be for this week. It means that average time between two block is higher than 600 seconds so stale percentage is a bit lower.

EDIT: Not long after I posted this, BAM!  I found ONE.

Yes, in fact it is quite common .

[snedie]

Hey Slush,

Just started mining today I heard your pool was apparently the best to be in.

Do you have any tips for new time miners? 

[xenon481]

poclbm is showing several instances of invalid or stale shares 4-25 seconds after a "long poll: new block" message. I assume that shouldn't be happening? I also have cases of a valid share as soon as 1 second after a long poll message.

Yes, I discovered problem in long polling loadbalancer, it unfortunately sometimes serve jobs from wrong backend (and then submitting those shares to correct backend leads to stale shares). I temporary turned long polling off and I will play with a configuration a little.

Is long polling still off or is it back on? I haven't gotten a single stale since I installed the latest poclbm over 12 hours ago. I had been seeing them about 1/hour before.

[slush]

Is long polling still off or is it back on? I haven't gotten a single stale since I installed the latest poclbm over 12 hours ago. I had been seeing them about 1/hour before.

Long polling is still off, hope today I'll make a fix for the LP issue. You probably seen more "stale" shares before, because I did some tweaks during those two days and every time I restart server, it refuses currently opened connections.

Do you have any tips for new time miners? 

Welcome on board :-). If is everything working for you, then just sit down and watch your wallet :-).

[snedie]

Hey Slush,

Been mining in your pool for about 19 hours and have close to 10 coins credited (Getting around 0.41785415.coins per block: Is this good/bad/avg?), how long on average is the confirmation time on the blocks before the coins become available for me to use?

[slush]

Is this good/bad/avg?

Depends on your hashpower . If you have 1Mhash/s CPU, it is quite impressive .

how long on average is the confirmation time on the blocks before the coins become available for me to use?

With typical network speed, it takes around 20 hours. You can see block confirmations on Stats page - when block become 'confirmed', your reward from that block is moved from 'unconfirmed' to 'confirmed' (it is recalculated by server once per hour).

[bitjet]

Is this good/bad/avg?

Depends on your hashpower . If you have 1Mhash/s CPU, it is quite impressive .

he;s about 1ghps

[snedie]

Thanks Slush.

I'm currently running at a peak of 1.2Ghash/s, with rates varying between 700Mhash/s to 1.1Ghash/s.

In your pool, am I understanding it correctly in that the longer a user stays connected and the more work the do, they higher the pay out?

[xenon481]

Thanks Slush.

I'm currently running at a peak of 1.2Ghash/s, with rates varying between 700Mhash/s to 1.1Ghash/s.

In your pool, am I understanding it correctly in that the longer a user stays connected and the more work the do, they higher the pay out?

All shares are worth something. The older that a share is, the more that it degrades in value. As such, the shares that are submitted right at the end of a round are worth the most.

Because the end of a round is indeterminate, there is little to no incentive for waiting to submit shares until towards the end of the round because you don't know when the end of the round will actually be. For all that you know, the round could end 30 seconds after it began. In fact, this has happened many times, even with high difficulty. A round could also take 9+ hours (this has also happened).

The odds that any single miner will find shares towards the beginning of the round or the end of the round are the exact same, regardless of the hashing power of that particular miner. You may find most of your shares at the beginning of this round, and then the next round you find most of your shares towards the end. It all evens out over time with statistical certainty.

It only takes ~1,000 shares (over the miner's entire lifetime, not just since it was last started) for the variance of this score based method to converge tightly with the variance of a standard share based method. For a CPU miner, that would take about 1 week. For a 5970, that could take less than 2 hours.

[slush]

I'm currently running at a peak of 1.2Ghash/s, with rates varying between 700Mhash/s to 1.1Ghash/s.

Then  your earnings are OK (I didn't recalculate it, but I'm 2.2 and have ~2x higher reward).

In your pool, am I understanding it correctly in that the longer a user stays connected and the more work the do, they higher the pay out?

Well, it is generally true for all current pools - you don't earn anything when you're disconnected .

But if you're asking to score based system - it works quite differently than other pools. Extremely shortly - when you disconnect, reward for your contributed shares is going slightly down (is halved every 5 minutes), but when you connect in, it goes also up faster. When you connect in the middle of the round, after few minutes your reward is almost same as if you connected on the round beginning. So the score based system only affect behaviour of connecting/disconnecting, but does not affect your final reward, at least in long term (1000+ shares contributed to the pool by your miner). As you have >1Ghash/s, this does not affect you at all. So don't be affraid with connecting/disconnecting to the pool as you want.

This works as (quite effective ) defense against some possible pool attacks. Thanks to score based system, pool can also offer all system statistics in realtime (round start, current shares in round etc). Drawback of this method is that it introduce some bigger variance in reward for CPU users (but in all cases, after 1000+ shares it is statistically without difference).

You can read more details & watch pretty graphs done by cosurgi in previous thread post.