Are pools more efficient?

[btc_artist]

Finding Bitcoin blocks is a lottery.

I'm still in learning mode here.

So this means that technically, I could turn on gen=1 in bitcoin.conf so the client tries to generate bitcoins, and if I were extremely lucky, there's a tiny chance I could solve a block 5 minutes later, right?

[DeathAndTaxes]

Finding Bitcoin blocks is a lottery.

I'm still in learning mode here.

So this means that technically, I could turn on gen=1 in bitcoin.conf so the client tries to generate bitcoins, and if I were extremely lucky, there's a tiny chance I could solve a block 5 minutes later, right?

There is a chance you could solve a block w/ a single hash.  There is also a chance you would solve every single block for the day with only an Atom CPU as your mining hardware.

There is always a chance (however remote).

[btc_artist]

Okay, I just wanted to make sure I understood how it works.  Thanks.

[teukon]

Okay, I just wanted to make sure I understood how it works.  Thanks.

Yep.  You can think of mining like repeatedly rolling a die.  If you roll a 1 you generate a block (and score 50 BTC).  This sounds easy until you realise that the die has about (2^32 * [Bitcoin difficulty]) sides.  No matter how high the difficulty, you could still get a 1 on your first try!

A CPU thread rolls a die repeatedly but fairly quickly.  A GPU rolls more slowly but is able to roll hundreds or even thousands of dice at a time!

A pool works by giving you the usual dice to roll but paying you a small amount whenever you roll a number less than about [Bitcoin difficulty].

[DrHaribo]

Two things that make pools more efficient than a (naive) solo mining setup:

• Long polling (don't continue checking old "lottery tickets" after they expire, get new ones instead)
• Merged mining (get free namecoins while you work on making bitcoins)

If I was going to solo mine, I think I'd get some of the free pool software and set that up, even if it was just for myself. If you solo mine directly against the bitcoin program, you are losing money.

[DeathAndTaxes]

Two things that make pools more efficient than a (naive) solo mining setup:

• Long polling (don't continue checking old "lottery tickets" after they expire, get new ones instead)
• Merged mining (get free namecoins while you work on making bitcoins)

If I was going to solo mine, I think I'd get some of the free pool software and set that up, even if it was just for myself. If you solo mine directly against the bitcoin program, you are losing money.

Good points.  Never thought about it but lack of LP is going to cost you 1% to 5% depending on card speed. 
cgminer helps reduce that somewhat.  It does independent checking for block changes and when it detects a block change will empty the queue and request a new getwork().

[Transisto]

To sum up, 
Advanced pool software = more efficient / reliable
Mining in group = not more efficient.

[teukon]

• Long polling (don't continue checking old "lottery tickets" after they expire, get new ones instead)

Is that right?  I thought long polling was all about helping the mining software and bitcoind communicate and thereby reducing the proportion of invalid shares.  If both pieces of software are on the same private network such communication should be a non-issue.  To me, the interesting communication problem is the broadcasting of a new block to all existing bitcoind nodes.

Could someone explain long polling or give me a link?  Particularly I'd like to know whether or not it improves on bitcoind's current block broadcasting and, if so, how?

[DrHaribo]

Could someone explain long polling or give me a link?  Particularly I'd like to know whether or not it improves on bitcoind's current block broadcasting and, if so, how?

bitcoind doesn't broadcast out new work. Workers poll for new work when they run out or run low on work.

Long poll is a technique for letting a server push data to a client with HTTP which doesn't really support server push. This way the server can give new work to the miners when a block change happens which invalidates all the old work the miners have. Then miners immediately start on the new work instead of doing useless work on old data, finding proofs or work that are useless and sending them to the server only to have them get registered as rejected proofs of work, aka. "stales".

Unfortunately bitcoind doesn't support long poll or any other kind of push or notification to clients that anything has happened. But pools do.

Edit:
more about long polling in general: http://en.wikipedia.org/wiki/Comet_%28programming%29
more about bitcoin getwork with long poll: https://en.bitcoin.it/wiki/Getwork

[gmaxwell]

Good points.  Never thought about it but lack of LP is going to cost you 1% to 5% depending on card speed. 

Just set your maximum scan time to 1 second. This means you'll lose a maximum of ~144 seconds of mining a day or 0.166%. You'll usually lose  more effort than that from pools due to other issues (stales, bugs, network latency).

Pools can't do this because all the users would slam them. But it's a perfectly reasonable thing when running on your own. (not that running pushpool with LP locally is much of an issue).

[teukon]

Good points.  Never thought about it but lack of LP is going to cost you 1% to 5% depending on card speed. 

Just set your maximum scan time to 1 second. This means you'll lose a maximum of ~144 seconds of mining a day or 0.166%. You'll usually lose  more effort than that from pools due to other issues (stales, bugs, network latency).

Pools can't do this because all the users would slam them. But it's a perfectly reasonable thing when running on your own. (not that running pushpool with LP locally is much of an issue).

That seems sensible to me.  Long polling shouldn't be necessary for a local network at all (not that it hurts).  I would argue that, even with long polling, pool miners will have more of a stales problem than solo miners.