When you are generating blocks, you use the pool's public key; it is not possible to insert your own key in your 'winning' block.

Oh, it's a great idea. I didn't think about this.

If only the pool owner has private keys, then leaving early is not an attack. But then we will need some kind of distribution of work to pool members so members don't calculate same hashes. The simplest way of such collision avoidance is to give each member different public key.

When you are generating blocks, you use the pool's public key; it is not possible to insert your own key in your 'winning' block.

This is a valid point. If you are hoarding the hashes that can result in a generated coin, they do you no good if you are using the public key intended for the network as a whole. Hoarding them only makes those hashes useless or you add that coin to the chain where the resulting coins are automatically presumed to be "owned" by the pool.

This still is a bit of a centralization effort, however, where whomever is administering the pool (and presumably holding the "private" part of the key) that can potentially cheat their users by collecting the "winning hashes" and keeping the coins for themselves, or skew the payoffs to the network members so they keep a larger amount for themselves. It moves the whole issue to setting up a trust relationship with the pool administrator and the "fairness" in terms of how payments are being made.

Even here, however, an audit trail can be made if the pool "proof of work" hashes are shared within the pool and available to all of the members of the pool... essentially an independent proof of work chain that is distributed within the network. This should include "successful" hashes that also become generated coins.

Could it be possible in this sort of situation where a collective pool chain is created where a successful coin generation is distributed to all contributors to the pool by each pool participant individually (based on the pool rules), or would this have to be done by a central administrator? Anything that could distribute the effort and decentralize this feature would be beneficial given the nature of this project.

a) Can secret sharing be incorporated into Bitcoin's scheme? I'm not sure of the technical pub/private key pairing that it uses.

b) I'm not sure it's an entirely appropriate solution -- Shamir had in mind a sort of 'info bank' or 'lockbox' when he constructed this system -- the payload was more likely imagined to be, say nuclear armament codes or wikileaks style information, not a bank account, as the system doesn't explicitly deal with the 'well, what do we do, now that we can decrypt the information?' question.

Thus, even if you had a shared key, say one that needed 1+n/2 to use their private key for access, all you would get back would be the shared private key -- then it would be a race to cheat with that key, or possibly the final party to apply their private key would get access. This still leaves a trusted party issue in the mix; I'd say the cheapest thing to do is trust the pooler. In this system, cheating is easily detected (e.g., your client knows it generated a winning block, but you never got a portion of it), trust is hard to repair, and recruiting people to your pool is likely to be far more work than 50BTC are worth in the near future.

I'm the CEO of CoinLab (www.coinlab.com) and the Executive Director of the Bitcoin Foundation, I will identify if I'm speaking for myself or one of the organizations when I post from this account.

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.

You guys are making the same mistake we did when working on this in the IRC chat. The system I outlined would work for distributed generating and allow you to determine how fast each of the nodes are generating hashes, allowing you to pay out based on how much work each user is putting into the pool.