Suggestions for pooled BTC mining?

[vess]

I was wondering today about how to get a pool of mining together: that is, users who wish to could all go in together on mining the next block. The actual block signer signs over the block to the group. Splitting could happen any number of ways.

This would really help new users who want to generate some BTC, a key problem for adoption right now. And, it would encourage slow-computer users to participate in block generation, something that is not very motivating right now for many.

Obviously, there's the 'cheater' problem: a user has no incentive to share once he/she has generated the block. I can't figure out how to solve that without a client that is patched.

Does anybody else have technical suggestions about accomplishing this? Even patched clients present some interesting problems: one thought I had is that you could include all the transactions to the group inside your block, but that would of course require you had 50+ BTC to start with, or the transactions would be invalid.

Of course, the client can just stay mum about generation until it's matured, then send it off, and you'd only know once you got your portion.

Thoughts?

[Ground Loop]

I'm puzzled.  Why would anyone do this?

Effectively, we're already pooled today.  Over the long haul, every 10 minutes, someone gets 50 bones, and it's apportioned based on CPU speed.

If a slow machine isn't worth running hot for months on end to search, then why would it be welcomed (at greater value) to a pool including faster machines?  Seems to me that if you found a group of like-minded honest individuals, you'd end up with a cluster of really slow machines, rarely finding a treat, and doling out pennies to each.  Further, anyone inclined to join the pool is already running their machine anyway.

I guess I'm missing the point.

[FreeMoney]

I'm puzzled.  Why would anyone do this?

Effectively, we're already pooled today.  Over the long haul, every 10 minutes, someone gets 50 bones, and it's apportioned based on CPU speed.

If a slow machine isn't worth running hot for months on end to search, then why would it be welcomed (at greater value) to a pool including faster machines?  Seems to me that if you found a group of like-minded honest individuals, you'd end up with a cluster of really slow machines, rarely finding a treat, and doling out pennies to each.  Further, anyone inclined to join the pool is already running their machine anyway.

I guess I'm missing the point.

Just to reduce the variance so that you can get 1BTC/day instead of 50 every 7 weeks. If there was an easy and secure way I guess I'd be a little interested.

[Olipro]

I'm puzzled.  Why would anyone do this?

for precisely the same reasons people run lottery syndicates.

problem is, in a lottery syndicate, obviously you will know who paid into the ticket fund and who didn't.

How do you plan to verify someone in the syndicate is actually trying to solve blocks?

The best way I can think of is by measuring their average number of hashes per second and then have a secondary target their client must achieve which acts as a proof of work for the syndicate to know that this person is dedicating their CPU resources to generation.

[aceat64]

About a week ago in IRC we had a discussion about how to do this, I believe mycroftiv is looking into implementing this kind of system.

It would be your basic client-server setup, the server sends each client a set of data to hash and a starting nonce. The data of course being the block header. The client would generate hashes as quickly as possible looking for a winner, but in order to keep the server informed about how fast it is working (so the BTC can be distributed by CPU-time) the client would create a hash of every 1,000 hashes and send these "meta-hashes" to the server. The server can randomly chose a meta-hash to check, it would then run the same 1,000 hashes and see if they generate the same meta-hash. If the meta-hashes don't match, then the client is lying. You don't have to worry about the clients stealing the winning block because the proxy transaction is already signed over to an address that only the server owns.

[vess]

Thanks, this is a great way to do this -- I'll look forward to hearing more about how it develops.

In answer to those who don't get "why?" -- go play farmville, or any other social networking game. Humans are wired to like slightly inconsistent, but frequent rewards.

When you could generate your first block in a day or so, the system created its own 'rewardiness' for people. This helped it become sticky.

This stickiness does not happen right now, unless you have a pretty hot computer or get lucky -- it's quite possible that someone could go weeks without generating a block. This is a real and present problem with adoption, and one that a pooling system would help solve without changing satoshi's desired 10 minutes-per-block pacing.

[Anonymous]

Thanks, this is a great way to do this -- I'll look forward to hearing more about how it develops.

In answer to those who don't get "why?" -- go play farmville, or any other social networking game. Humans are wired to like slightly inconsistent, but frequent rewards.

When you could generate your first block in a day or so, the system created its own 'rewardiness' for people. This helped it become sticky.

This stickiness does not happen right now, unless you have a pretty hot computer or get lucky -- it's quite possible that someone could go weeks without generating a block. This is a real and present problem with adoption, and one that a pooling system would help solve without changing satoshi's desired 10 minutes-per-block pacing.

What if the pool is just as unlucky as the individual?

[lfm]

I'm puzzled.  Why would anyone do this?
...
I guess I'm missing the point.

Just to reduce the variance so that you can get 1BTC/day instead of 50 every 7 weeks. If there was an easy and secure way I guess I'd be a little interested.

Do the arithmetic. 1BTC / day for 7 weeks = 49 BTC. This whole thing is set up for people who would rather have 49 BTC than 50!
I wonder who is pocketing the extra 1BTC.

[vess]

What if the pool is just as unlucky as the individual?

By definition the pool will work through its 'bad luck' faster, since it has more chances to.

That is, if 10% of the current computers generating bitcoin pooled, then on average right now they would generate a block every 100 minutes or so. Therefore you would get (50 BTC / pool size) every 100 minutes once the blocks had started to mature. If it's really unlucky and gets a block after 200 minutes, then obviously, everyone would wait. Regardless, BTC would start piling into your account -- at no faster rate than they would otherwise -- in small increments, and relatively soon.

You could make it more addictive by playing a little sound or animation when someone in the pool generated a block, and even more so when you generate one.

I'm assuming the comment about 1 BTC missing is a joke, but if not, the pool could designate a little bit to the pool server as compensation. I would think 1 BTC would be too much, though.

I was also thinking you could incent the winner by doubling their share: a nice psychological trick that shouldn't actually impact block generation or distribution of BTC over the long haul.

[RHorning]

Just to reduce the variance so that you can get 1BTC/day instead of 50 every 7 weeks. If there was an easy and secure way I guess I'd be a little interested.

Do the arithmetic. 1BTC / day for 7 weeks = 49 BTC. This whole thing is set up for people who would rather have 49 BTC than 50!
I wonder who is pocketing the extra 1BTC.

Why would somebody have to be pocketing the extra BTC?

I was wondering today about how to get a pool of mining together: that is, users who wish to could all go in together on mining the next block. The actual block signer signs over the block to the group. Splitting could happen any number of ways.

I don't know how you would assign a "fairness" metric to a pool like this, although I like the idea in principle.

How about this as a metric for determining participation in such a pool:  Computers in a "sub-net" (aka "the pool") would submit "candidate" blocks that would have about 1/10th (or some other faction) of the difficulty of the main Bitcoins target hash as a sort of "proof of work" that they are at least trying to find good candidates for the newly generated block.  Those who submit candidate blocks would get some of the coins of whatever block is generated eventually by the pool.  Network bandwidth would be limited to the sub-net of the pool itself, except for awarding the good-faith efforts as a transaction and any potential new blocks actually generated.

I do see some sort of "cheating" as a possibility with this scheme, where some computer that would generate a hash that meets the overall network fitness test would simply create that new block without submitting it to the "pool", but submit inferior blocks to try and collect coins from "suckers" who are submitting blocks to the pool for the greater good.  In other words, your "sub-net" is only as good as the least honest person in that pool.  There could be protocols set up to automatically kick people from the pool if they are sucking up too many coins and not contributing (aka "cheating"), but that seems to me as an overly complicated process that can only get worse over time if you open these "pools" to everybody.

What I agree with is that people would rather see something going into their wallets on a semi-regular basis (even 0.01 bitcoins every few minutes or hours) rather than having one huge lump show up every other month.  They want to see cash flow and it appeals to human greed too.  I don't know of an easy way to accomplish that sort of task other than a massive redesign of Bitcoins to encourage more frequently generated coin blocks or the pool method as suggested here.  Presuming that Bitcoins grows another 100x larger in terms of its user base, it certainly could be the case where a typical user would only generate one block per year or even less frequently.  It is a problem that might get even worse over time.

Mind you, I'm not necessarily saying that the current coin generation system is bad, other than the frequency of receiving generated coins is not the best feature of Bitcoins.

[Ground Loop]

It seems like this could be accomplished via UI change..

Instead of presenting 50.00 on generated block, compute how long it took and "trickle" the coins into the wallet to feel better about them for longer.

So once you generate a block, you would see pennies start appearing.  Hopefully they would trickle in for as long as it takes to generate your next block, more or less.



(I kid, I kid..)

[nimnul]

I think I found a solution for this fairness problem. It's the same proof of work as in main Bitcoin. Fortunately, many proofs-of-work can be computed at the same time at no cost.

The solution is this:

1) each slave generates blocks as before (is trying to solve its own blocks)
2) each slave reports its public key to the master
3) master maintains another difficulty, "syndicate difficulty"
4) if anyone gets hash below syndicate difficulty and reports to the master, she gets syndicate reward
5) if anyone gets hash below main difficulty and gets 50 BTC everyone else in the syndicate can check that
6) the syndicate difficulty can be automatically adjusted so new syndicate reward is paid out to someone every X minutes
7) the syndicate reward can be automatically adjusted to the total amount of coins generated by syndicate, so syndicate can never spend all coins it generated by paying syndicate rewards

What are possible attacks?

[Insti]

What are possible attacks?

The public key I use on the coins I actually generate is different from the one I provide to you, which will never generate.

Edit: Hmm. This would require generating a separate hash. And it would seem silly to throw away a winning hash to spite the group. I should think more before posting.

What about: once I generate a block I leave the syndicate without paying my 50 in?

[Inedible]

Perhaps this might help:

I you go it alone, you are competing against a massive amount of CPU power. If you join a group, the combined CPU power gives you a greater probability of getting coins.

E.g. Go it alone
0.001% probability of getting a larger number of bitcoins

Joining a group
3% of getting a share of any bitcoins.

What this means is that if any bitcoins are generated, you'll get a share (I would think proportional to the effort you put in). Sure, it's much smaller but at least you get something.

So your choice is, a very tiny probability of getting a large amount of bitcoins or a small amount of bitcoins for any work you put into the group.

That's the difference.

Some say there is no difference and if you generated for long enough (proportional to the total amount of CPU going into global generation) then the outcomes will be the same but I suspect that bitcoins will hit the 21M limit well before we see that statistical situation arise.

[nimnul]

What are possible attacks?

The public key I use on the coins I actually generate is different from the one I provide to you, which will never generate.

Edit: Hmm. This would require generating a separate hash. And it would seem silly to throw away a winning hash to spite the group. I should think more before posting.

What about: once I generate a block I leave the syndicate without paying my 50 in?

"Never generating" (just hoarding winning hashes) is a possible attack. While attacker doesn't get any profit from throwing a hash away, she may want to perform such attack out of an irrational motive to undermine the whole idea of syndication. If he does this throwing away for ling time and with considerable CPU power, automatically adjusted syndicate rewards approach zero and less people become interested in syndicating.

"Leaving after first generation" is a feasible attack too. It can be avoided by asking for 50 BTC to enter syndicate. These BTC will be paid back if a person leaves syndicate, but a few blocks later than person tells you she wants to leave. She cannot get her 50 btc back before she spends her winning cache, as waiting a few blocks will invalidate it. And if she spends the hash before asking it's seen by other people as cheating and 50 are never paid back.

This 50 BTC payment will preclude novices from entering syndicate though.
 

[FreeMoney]

How is leaving after first generation an attack?

[nimnul]

It's an attack because it's possible to exploit it get twice more money than your computation power would normally allow. At the cost of other pool members

[vess]

Leaving early is not an attack. Consider:

You are in the pool, and one minute in to the block, you find the winning hash. There are 4 other pool members, each with equal strength computers.

You get 10 BTC on maturation, like each pool member.

The pool immediately goes to work on the next block. If you leave, the pool strength drops by 20%. The member's BTC shared increases by 20%. They are not worse off without you.

Now, imagine the 'winning' hash gets a 2x share: for each future block all participants' expected value of BTC is the same as it would be going it on their own. "Leaving early" is a little bit like taking your money out at the casino whenever you're up. You're up, good for you, but your odds going forward are the same as they were, and the same as everyone else's.

Playing to 'get lucky' like this is probably not the motivation for such a pooling arrangement once pool members > 10 or so.

Finally, asking people for 50 BTC upfront is absolutely contrary to the reason you would want to pool initially -- getting a few BTC flowing in half an hour or so from download of the application.

p.s., This also begs the central question -- how do you know how fast / strong people are? You could sit around working on other non-pooled hashblocks and just give a 1,000 hash block anytime the server asked you for one. I'm not sure how to probabilistically determine speed and deal with cheaters.

[nimnul]

If you give generated coin to pool and leave pool it's not an attack.

But it's an attack if you keep your generated coin and leave.

You can join the pool again and leave again after first generation without giving anything.

If you repeat this forever, you will be getting 2x more coins a month than without pooling. Or you can participate in N different pools at the same time and get N+1 times more money than would be possible.

First, if there are 5 members in the pool, you don't get 10 coins each time a coin is generated - you get a share proportional to your CPU power share in the pool. Your share is measured by "pool proof-of-work" as I explained earlier.

Let all pool generated 50 easy blocks, and you generated 10 and then generated one hard block. So you get 10 coins from pool and 50 coins from your own generation.

If everyone else behaves like you, pool will not work as nobody will give any bitcoins to the pool.

[Insti]

If you give generated coin to pool and leave pool it's not an attack.

But it's an attack if you keep your generated coin and leave.

You can join the pool again and leave again after first generation without giving anything.

If you repeat this forever, you will be getting 2x more coins a month than without pooling. Or you can participate in N different pools at the same time and get N+1 times more money than would be possible.

First, if there are 5 members in the pool, you don't get 10 coins each time a coin is generated - you get a share proportional to your CPU power share in the pool. Your share is measured by "pool proof-of-work" as I explained earlier.

Let all pool generated 50 easy blocks, and you generated 10 and then generated one hard block. So you get 10 coins from pool and 50 coins from your own generation.

If everyone else behaves like you, pool will not work as nobody will give any bitcoins to the pool.

I don't understand this post. Are you trying to explain how leaving early is an attack?

_{Edit: I do think leaving early is an attack.}