BitcoinTalk

[2.5+ EH] Slush Pool (slushpool.com); World's First Mining Pool

250
Satoshi-only
BitcoinTalk
#1
From:
slush
Subject:
[2.5+ EH] Slush Pool (slushpool.com); World's First Mining Pool
Date:




News | Pool Statistics | Block History | Help Center | Demo Account

We are the world's first cryptocurrency mining pool founded in 2010.
Since then we have together mined over 1 million BTC.

Reasons to mine on Slush Pool

  • low flat fee of 2 % (network fees are shared with miners!)
  • stable income thanks to our significant network share (~ 15 blocks a day)
  • neat interface with dashboard and worker monitoring
  • advanced security with 2FA and payout address locking
  • servers in Europe, North America and Asia
  • free withdrawals above 0.01 BTC

Start mining on Slush Pool


Support

  • Create a ticket in our support system, if you have any issues or questions.
  • We will get back to you as soon as possible, usually within 24 hours.
  • We cannot guarantee answering questions posted elsewhere. Thank you for understanding.

Follow us: Twitter | Facebook | Blog

Original post:
Once people started to use GPU enabled computers for mining, mining became very hard for other people. I'm on bitcoin for few weeks and didn't find block yet (I'm mining on three CPUs). When many people have slow CPUs and they mining separately, each of them compete among themselves AND against rich GPU bastards ;-), because everybody counts sha256 hashes from the same range. Two separate CPUs with 1000khash/s isn't the same as one 2000khash/s machine!. But new feature of the official bitcoin client called 'getwork' now enables work of many computers together, so they don't compete. Because there is now standalone CPU miner (thanks to jgarzik!) and 'getwork' patch is in official client now, I have an idea:

Join poor CPU miners to one cluster and increase their chance to find a block!

How that should work? There will be web page where you can register, enter your wallet address and get URL and your personal rpcuser/rpcpassword for your CPU/GPU miners. When you start own miner with these credentials, server will send you work which was not calculated yet by other members of cluster.

But when your client find winning hash, you do not get full reward for block (50BTC right now), but only proportional part, which you calculate. When you offer 1000khash/s for one day and whole cluster performance will be 20000khash/s and it takes two days to find a block, your reward will be (50/20/2=)1.25BTC.

Advantages? When you have poor standalone computer, you need to wait many weeks or even months for finding full 50BTC reward. When you join cluster like this, you will constantly receive small amount of bitcoins every day or week (depends on full cluster performance).

Disadvantages? You need to trust in central authority (me) that I don't steal block for myself. But I'm goofing around for few week and I'm amazed with bitcoin idea, so I don't plan to steal anybody right now :-).

Another possible problem is that somebody will ask for new work very often, but in fact he will not count real hashes. In this case it will look like he has very strong CPU and he should get big part of reward if cluster find a block. But there is a simple defense against cheaters: Central server sometimes send work which leads to 'winning' hash. Worker which don't return this hash as matching will be permanently banned (login/password and IP address). This was succesfully solved by letting miners calculate proof-of-work. It is not anymore possible to be a part of cluster and not count hashes.

Are you interested in?
BitcoinTalk
#2
From:
ribuck
Subject:
Re: Cooperative mining
Date:
Quote from: slush on November 27, 2010, 01:45:41 PM
Two separate CPUs with 1000khash/s isn't the same as one 2000khash/s machine!
Actually, they are equal. The low-power machines aren't "racing" against the high power machines. For any given difficulty level, it doesn't even matter how many other machines are generating. If all the other machines dropped off the network, it wouldn't increase the number of blocks you generate (until the next difficulty level adjustment).

The only thing that counts significantly is the difficulty level and your khash/s. There are some relatively minor effects due to network latency, but they're not a big deal.
BitcoinTalk
#3
From:
td
Subject:
Re: Cooperative mining
Date:
I will offer a Six-Way AMD Processor to the Cooperative Mining Group. I tried generating for weeks on it to no avail. I have given up in the mean time and have instead purchased coins for use. I would love to turn the value of my tiny 9,000/k/hash/s into something productive. If nothing else as part of an experiment to make your software more secure. There is another thread already on the forum for the source code to Cooperative Mining but I am not sure that it was complete or successful. There appeared several people participating but no additional work from them. Perhaps it was so successful that they no longer wish to have additional participants into their group- I am unsure. My rate contribution may not win me blocks by myself but as a larger group hopefully I could be helpful. Please let me know if you move forward with this.
BitcoinTalk
#4
From:
BitLex
Subject:
Re: Cooperative mining
Date:
i always liked the idea of distributed mining,
with CPUs its actually the only chance you got to get some coins on a regular basis now and even using a GPU it already takes days to generate a block on your own, rising for sure.

call me in at least for beta-testing, there's always some cores around to share.
BitcoinTalk
#5
From:
bober182
Subject:
Re: Cooperative mining
Date:
Sure seems fair its better then waiting 1 year for 50 bitcoin. Now I wait 1/50 of a year for 1 bitcoin yay!
BitcoinTalk
#6
From:
slush
Subject:
Re: Cooperative mining
Date:
Quote from: ribuck on November 27, 2010, 02:35:56 PM
For any given difficulty level, it doesn't even matter how many other machines are generating.

You are true for long term. But I think many people with poor CPUs simply switch off their minings because they see it will take ages until they receive single bitcoin from that. When you are in cluster of cooperative miners, you will receive small amount (say 0.01 BTC if you contribute 0.02% to cluster performance) but more often. I feel that it may be a motivation for people to not shut down their miners.

I think it is extremely important for bitcoin economy to diversify mining across whole network and not leave mining on few lucky guys with fast GPUs.

Quote
The only thing that counts significantly is the difficulty level and your khash/s.

Of course. The more khash/s in cluster, the more blocks found by cluster and more often payments to cluster members.
BitcoinTalk
#7
From:
FreeMoney
Subject:
Re: Cooperative mining
Date:
Quote from: slush on November 27, 2010, 04:20:26 PM
Quote from: ribuck on November 27, 2010, 02:35:56 PM
For any given difficulty level, it doesn't even matter how many other machines are generating.

You are true for long term. But I think many people with poor CPUs simply switch off their minings because they see it will take ages until they receive single bitcoin from that. When you are in cluster of cooperative miners, you will receive small amount (say 0.01 BTC if you contribute 0.02% to cluster performance) but more often. I feel that it may be a motivation for people to not shut down their miners.

I think it is extremely important for bitcoin economy to diversify mining across whole network and not leave mining on few lucky guys with fast GPUs.

Quote
The only thing that counts significantly is the difficulty level and your khash/s.

Of course. The more khash/s in cluster, the more blocks found by cluster and more often payments to cluster members.

I like the idea, but your rhetoric is awful.

Lucky guys with GPUs? Do you think those are distributed via lottery or something?
BitcoinTalk
#8
From:
grondilu
Subject:
Re: Cooperative mining
Date:
Isn't cooperative mining a form of communism ?

Personnaly I gave this a thought and I think it's useless and much harder to do than one might think.

First I thought it was a problem if only a few nodes were capable of mining.  Now I don't care anymore.  Even if only one was mining all new bitcoins, I wouldn't care much.  This node would do all the work recquired, and in the best way.   Plus, anyone can take its place if it can hash more.
BitcoinTalk
#9
From:
slush
Subject:
Re: Cooperative mining
Date:
Quote from: FreeMoney on November 27, 2010, 04:26:49 PM
Lucky guys with GPUs? Do you think those are distributed via lottery or something?

It is just my feeling of inferiority that I have few Mhash/s :-D

Don't take it personally, I'm OK with GPU miners. But I'd like to give real chance to get few btc for many users with poor computers. That's all.
BitcoinTalk
#10
From:
slush
Subject:
Re: Cooperative mining
Date:
Quote from: grondilu on November 27, 2010, 04:43:44 PM
Isn't cooperative mining a form of communism ?

Do you really think cooperation is communism? There is nothing as 'free bitcoins for everybody' in cooperative mining.
BitcoinTalk
#11
From:
FreeMoney
Subject:
Re: Cooperative mining
Date:
Quote from: grondilu on November 27, 2010, 04:43:44 PM
Isn't cooperative mining a form of communism ?

Personnaly I gave this a thought and I think it's useless and much harder to do than one might think.

First I thought it was a problem if only a few nodes were capable of mining.  Now I don't care anymore.  Even if only one was mining all new bitcoins, I wouldn't care much.  This node would do all the work recquired, and in the best way.   Plus, anyone can take its place if it can hash more.


There is nothing wrong with voluntary communism. Not sure if you were implying that there is or not. I think someone has worked out the details of making it work, but I'm not sure.
BitcoinTalk
#12
From:
BitLex
Subject:
Re: Cooperative mining
Date:
Quote
useless and much harder to do than one might think
i agree on the harder part, there'd be some problems to solve and hurdles to take,
but i don't think it's useless.

any bit of computing-power, be it from CPUs or GPUs, makes our network stronger.
it'll help even those that aren't generating at all, by protecting their coins.

people are willing todo lots of stuff, if you give them at least something in return.
currently you practically don't get anything for adding your cpu/s to the cloud, you probably have to pay for it, so why do it anyway?
most people won't, maybe they will if you give them just a few coins, or bitcents for what they do.

of course bitcoin in general is not about generating at all, but it's a nice way to attract it to a lot more people.
BitcoinTalk
#13
From:
farmer_boy
Subject:
Re: Cooperative mining
Date:
This is fundamentally flawed. I can join the "effort" and figure out how long it generally takes to perform one unit of work. After that time I send a message "ah, too bad I didn't find anything". Then someone does find an answer and I collect.

Now, if I find the answer, I would simply communicate that to the rest of the network (not the central server) and there is no way for you to figure out that I double crossed you.

The distributed method there is now is a good way to mine. Possibly it would be better if it was easier to solve and that you would get less bitcoins, OTOH, people are still generating coins.
BitcoinTalk
#14
From:
slush
Subject:
Re: Cooperative mining
Date:
Quote from: farmer_boy on November 27, 2010, 05:41:35 PM
This is fundamentally flawed. I can join the "effort" and figure out how long it generally takes to perform one unit of work. After that time I send a message "ah, too bad I didn't find anything". Then someone does find an answer and I collect.

Do you mean somebody can cheat by simply asking for work, but not counting hashes? I talked about it already - I will send task which leads to 'winning' hash and when worker does not return it, I will ban them.

Quote
Now, if I find the answer, I would simply communicate that to the rest of the network (not the central server) and there is no way for you to figure out that I double crossed you.

Also this kind of cheat will be detected by technique described above. You will succeed at most once before you will be banned by central server.

Quote
The distributed method there is now is a good way to mine. Possibly it would be better if it was easier to solve and that you would get less bitcoins, OTOH, people are still generating coins.

Partially agree. But until one mined block will be for more than 1 BTC, cooperative mining should be still better for slow computers, because possible reward in coop can be also in BTC cents or less.
BitcoinTalk
#15
From:
bitcoin2
Subject:
Re: Cooperative mining
Date:
puddinpop has released a Pooled/Remote Mining - client:
https://www.bitcoin.org/smf/index.php?topic=1458.0;all

Is this client gpu-ready?
BitcoinTalk
#16
From:
jgarzik
Subject:
Re: Cooperative mining
Date:
Quote from: bitcoin2 on November 27, 2010, 06:15:21 PM
puddinpop has released a Pooled/Remote Mining - client:
https://www.bitcoin.org/smf/index.php?topic=1458.0;all

Is this client gpu-ready?

Your answer is here in the thread where you originally posted this question.
BitcoinTalk
#17
From:
bitcoin2
Subject:
Re: Cooperative mining
Date:
Quote from: jgarzik on November 27, 2010, 06:20:29 PM
Quote from: bitcoin2 on November 27, 2010, 06:15:21 PM
puddinpop has released a Pooled/Remote Mining - client:
https://www.bitcoin.org/smf/index.php?topic=1458.0;all

Is this client gpu-ready?

Your answer is here in the thread where you originally posted this question.

The Remote mining in the official bitcoin release has no "send back" - function but we are searching a pooling-miner like puddinpops.
BitcoinTalk
#18
From:
ribuck
Subject:
Re: Cooperative mining
Date:
The cheating problem has a trivial solution.

The distributed miners work to find a hash at a difficulty level that is considerably lower than the network requires. Whenever they find one, they send it back. When one of those hashes is difficult enough to meet the needs of the network, it generates 50 bitcoins which are distributed to those who have been sending in hashes at the easier level.

There's no way to look for easy hashes without also having a chance to find the occasional difficult hash. And when you find a difficult hash, there's nothing better to do with it than to send it back to the mining co-ordinator (because it's a hash that pays them 50 bitcoins, not one that pays you 50 bitcoins).

With this scheme there is no incentive to cheat, and no need for "banning".
BitcoinTalk
#19
From:
slush
Subject:
Re: Cooperative mining
Date:
Quote from: ribuck on November 27, 2010, 06:47:46 PM
And when you find a difficult hash, there's nothing better to do with it than to send it back to the mining co-ordinator (because it's a hash that pays them 50 bitcoins, not one that pays you 50 bitcoins).

Oh, so when I got work from coordinator which leads to winning hash, I cannot send it to bitcoin network as "my own" hash? I don't think so. I thought it is possible to not return hash to coordinator and put it directly to bitcoin network in own transaction...
BitcoinTalk
#20
From:
ribuck
Subject:
Re: Cooperative mining
Date:
Quote from: slush on November 27, 2010, 06:58:19 PM
Oh, so when I got work from coordinator which leads to winning hash, I cannot send it to bitcoin network as "my own" hash?

In a pooled mining situation, the winning hash cannot be used as "your own".

The hash incorporates all of the transactions in the block, including the one that pays 50 BTC to the generator.

If you are hashing for pooled generation, the winning hash is only useful to the pool.

If you are hashing for yourself, then obviously the winning hash is useful to you. But in that case the "low-difficulty" hashes that you generate are useless to the pool, so the pool will not pay you a share of the generated 50 BTC.

It is a solved problem to prevent cheating with pooled generation.

BitcoinTalk
#21
From:
puddinpop
Subject:
Re: Cooperative mining
Date:
Quote from: bitcoin2 on November 27, 2010, 06:32:42 PM
The Remote mining in the official bitcoin release has no "send back" - function but we are searching a pooling-miner like puddinpops.

Is there a particular reason that the pooled miner I created is not sufficient?  It has the basics there already.  It checks the best hash from each client to make sure the clients are doing the work they say, and it distributes the generated bitcoins based on the calculated hash rate of each connected client.  I just updated this thread with the latest source and binaries for pooled mining.
BitcoinTalk
#22
From:
farmer_boy
Subject:
Re: Cooperative mining
Date:
How can the server create winning hashes? Winning hashes are by definition hard to compute objects that are all shared as soon as they are known. In fact, you can cheat by simply having a fake miner on a bunch of different IPs (via ipv6 you can have millions) with one real miner. The real miner remembers all the previously hard to compute objects and does hard work so has the same information as the server. If the server sends a unit of work to a fake miner, the fake miner forwards the request to the real miner and otherwise does nothing.

Your assumption about IP addresses is also invalid, btw. People still have dynamic ip addresses.

I would be interested in the concept, but I don't think there is a solution.
BitcoinTalk
#23
From:
grondilu
Subject:
Re: Cooperative mining
Date:
To me it seems that cooperative mining is a tough task, because the honnesty of participants has to be checked.  What's preventing someone to run a modified version of the client, that would just keep generated bitcoin for himself, while receiving bitcoins from others ?

I wonder if it wouldn't be simpler to just rent processing power.  For instance by renting a ssh access to each machine.

The price could be directly proportionnal to the total number of computed hashes.
BitcoinTalk
#24
From:
FreeMoney
Subject:
Re: Cooperative mining
Date:
Quote from: puddinpop on November 27, 2010, 09:17:19 PM
Quote from: bitcoin2 on November 27, 2010, 06:32:42 PM
The Remote mining in the official bitcoin release has no "send back" - function but we are searching a pooling-miner like puddinpops.

Is there a particular reason that the pooled miner I created is not sufficient?  It has the basics there already.  It checks the best hash from each client to make sure the clients are doing the work they say, and it distributes the generated bitcoins based on the calculated hash rate of each connected client.  I just updated this thread with the latest source and binaries for pooled mining.


Can't they just send all except the winning ones? Maybe I don't understand though.
BitcoinTalk
#25
From:
ribuck
Subject:
Re: Cooperative mining
Date:
Quote from: grondilu on November 27, 2010, 10:21:27 PM
To me it seems that cooperative mining is a tough task, because the honnesty of participants has to be checked.  What's preventing someone to run a modified version of the client, that would just keep generated bitcoin for himself, while receiving bitcoins from others ?

<sigh>

Either I haven't been very good at explaining why there's no possibility to cheat, or I'm wrong. But if I'm wrong, no-one has posted a specific objection. So I'll try to explain it again, by presenting a specific design to show that a dishonest client cannot cheat.

Suppose I operate a pooled mining server, and I recruit some clients who wish to pool their mining.

My server asks each client to do some hashing for it. It asks each client to submit any hashes they find that are above a certain threshold of difficulty. The server chooses a difficulty that is one-fortieth (1/40th) of the current "official" difficulty level.

My server gets a constant trickle of candidate hashes sent back by the remote mining clients. Every now and then, one of those hashes meets the official difficulty level and my server can generate a block, which earns my server 50 bitcoins.

I now distribute bitcoins to the remote mining clients, at the rate of one bitcoin for each hash that was submitted for the current block that was at or above 1/40th of the official difficulty level.

In the long run, I would expect to distribute 40 coins out of every 50 that my server generates, although there will be some fluctuation from block to block. Nothing in this scheme requires the clients to be honest, because there is no way that a dishonest client can cheat!

The client is calculating hashes that will generate 50 BTC for my server. Those same hashes are not of any use to a dishonest client. They cannot be used to generate 50 BTC for the dishonest client, because a different hash code is needed to encode the payment of the generated bitcoins to someone else. And if the dishonest client tries to cheat by generating hashes that will pay the generated bitcoins to themselves, then the hash codes they submit won't validate at my server and I won't distribute any share of the payouts to them.

So this scheme requires absolutely no trust of the client.

This scheme also does not require the mining client to have faith that the server is honest. If the server advertises that it is paying out 1BTC for each hash that is at least 1/40th of the official difficulty level, then every client that submits an "easy" hash for a block that was generated can check that they received their bitcoin. Any fraud would show up immediately.
BitcoinTalk
#26
From:
grondilu
Subject:
Re: Cooperative mining
Date:
Quote from: ribuck on November 27, 2010, 11:04:02 PM
Either I haven't been very good at explaining why there's no possibility to cheat, or I'm wrong. But if I'm wrong, no-one has posted a specific objection. So I'll try to explain it again, by presenting a specific design to show that a dishonest client cannot cheat.

Sorry, your system seems quite well thought, indeed.  I hadn't been paying enough attention.

Still, I keep thinking that renting ssh access would be much simpler a solution.
BitcoinTalk
#27
From:
FreeMoney
Subject:
Re: Cooperative mining
Date:
Ribuk, thank you for explaining again. I get it now. It wasn't sinking in that the miners were working on a block for which they couldn't take the reward, seems obvious now.
BitcoinTalk
#28
From:
QuantumMechanic
Subject:
Re: Cooperative mining
Date:
It sounds like pooled mining would either flood the network with tiny transactions, or be unfeasible due to transaction fees.  So the server would therefore have to keep accounts for users which they could withdraw from once their balance gets large enough.

I guess it would probably be best then if the server required the miners to have MyBitcoin accounts, or something similar.  It'd be nice if MyBitcoin offered a pooled mining service; they've got all the accounting infrastructure in place, and it could be a nice additional source of revenue for them.

Very elegant solution, Ribuck.
BitcoinTalk
#29
From:
RHorning
Subject:
Re: Cooperative mining
Date:
Quote from: ribuck on November 27, 2010, 11:04:02 PM
My server asks each client to do some hashing for it. It asks each client to submit any hashes they find that are above a certain threshold of difficulty. The server chooses a difficulty that is one-fortieth (1/40th) of the current "official" difficulty level.

One of the potential problems I can see is that you may have to tweak the "reduced" difficulty level in some way so that it really is about a 1 in 40 chance of getting a successful hash.  It would seem to me that a reduction of even a couple of bits in the expected hash would have major consequences in terms of how many "reduced difficulty hashes" are created and it is possible that reducing the difficulty to 1/40th of the "official" difficulty level may create many more "successful" reduced difficulty hashes than 40, perhaps even to a higher order of magnitude.  This is something to test with a successful experiment of this idea to see just how it might turn out.

Furthermore, it is also going to be random in terms of how many reduced hashes are going to be created per successful hash cycle, as you are dealing with probability here and not mathematical certainty in terms of how many are going to be generated by the "farm" even if it does produce in this example on average about 40 "reduced difficulty hashes".  It may still be worth the effort if it turns out that on average that is all you have to spend for an increase in successful blocks created, but it will be some blocks where the hash farm server makes a bunch of coins for the server operator and other times it may be at least temporarily a loss.

Another potential problem I also see is if you happen to be requesting hashes where you've received a couple dozen reduced hashes and then the network has a huge spike in difficulty.  This is a potential liability issue so far as the "owner" of the hash farm server is concerned, as it would substantially impact the "profit margin".  Think of it this way:  If the current difficulty is at say 800 and you've received 30 hashes with a difficulty level of 20 (1/40th of the difficulty, as you suggested here), then the difficulty increases to 1600, it is very likely that you may have to plow through another 30-40 hashes at the new higher difficulty level of 40 before you get a successful block into the chain mining the coins.  If in this example you are still paying out 1 BTC per reduced hash, it could get very costly for the person running the hash farm in this case.  It may wipe out any profit earned and certainly is another potential liability issue to think about.  I'd have to think through the statistical probability on an increase of difficulty some more in terms of giving some hard numbers, but it is something that should be accounted for.

Then again, difficulty could drop brining in at least statistically more money to the server operator.  The current tendency is for increases of difficulty, however.

Otherwise, I think the basic concept as outlined here is pretty sound and would tend to work rather well.  Almost too well as I could see this being put into a botnet and having the computers in the botnet be sending back potential hashes without having to worry about any payments.  Network bandwidth would be trivial and almost unnoticed, and you could even "throttle" the CPU bandwidth or throw it onto the GPU instead.  I have no doubt that eventually somebody is going to build one of these botnets if it hasn't already been built for Bitcoins.
BitcoinTalk
#30
From:
ribuck
Subject:
Re: Cooperative mining
Date:
Quote from: RHorning on November 28, 2010, 07:11:33 AM
... if you happen to be requesting hashes where you've received a couple dozen reduced hashes and then the network has a huge spike in difficulty.  This is a potential liability issue so far as the "owner" of the hash farm server is concerned, as it would substantially impact the "profit margin"

Sorry, you misunderstand. The server operator only pays out to easy hashes that were submitted for a block that is won. There's no payout for easy hashes that were submitted for a block that someone else generates.

The difficulty can't change in the middle of a block. It always changes at a known time, and you always know exactly what the difficulty is, so there's no risk here.

Quote
...you are dealing with probability here and not mathematical certainty...

That's absolutely true, but over time probability tends towards mathematical certainty. If the server operator is getting a few percent of the generated bitcoins, it doesn't take long to become virtually guaranteed profit.
BitcoinTalk
#31
From:
asdf
Subject:
Re: Cooperative mining
Date:
This is brilliant!

In the future, when bock sizes are huge, this will save a lot of bandwidth and storage. Only one "server" node needs the blockchain and the fat bandwidth required to receive the flood of transactions. Many clients can then contribute to bitcoin without the need to pay for all that infrastructure multiple times. This means that small players can stay in the market and kind of solves the whole scaling problem. Awesome!
BitcoinTalk
#32
From:
grondilu
Subject:
Re: Cooperative mining
Date:

Am I the only one who thinks it would be way more simple to just rent distant shell access ??
BitcoinTalk
#33
From:
FreeMoney
Subject:
Re: Cooperative mining
Date:
Quote from: asdf on November 28, 2010, 02:44:58 PM
This is brilliant!

In the future, when bock sizes are huge, this will save a lot of bandwidth and storage. Only one "server" node needs the blockchain and the fat bandwidth required to receive the flood of transactions. Many clients can then contribute to bitcoin without the need to pay for all that infrastructure multiple times. This means that small players can stay in the market and kind of solves the whole scaling problem. Awesome!

Oh, I didn't even realize this. But it is correct I think. Only the header needs to be hashed. So this scheme has benefits beyond reducing the variance in generating. Very nice.
BitcoinTalk
#34
From:
farmer_boy
Subject:
Re: Cooperative mining
Date:
I think I initially misunderstood the blocks in that the hashes that we compute are independent of the address. Now, I believe that we are looking for something like sha256 (bitcoint address + amount (I am not sure whether the value is implicit, so this value might not be there)  + <answer>) with some desired properties (of which the number of final zeros is an approximation), where + means some concatenation operator of bits.

If the computation is like that, _then_ it might work, but I don't see why someone cannot just only send you the worthless hashes (for you) and don't send those that are useful to you. By this mechanism they can bankrupt you. Anyway, I think it is a bad way to communicate with natural language only about these topics. Just write out the computations that you intend to do on the server and the client and then we can see whether it is a brilliant idea or a flawed one. Annotations on the computations as to which goal they intend to achieve is also useful for communication.

Forcing cooperation out of nodes is not easy.
BitcoinTalk
#35
From:
satoshi
Subject:
Re: Cooperative mining
Date:
ribuck's description is spot on.

Pool operators can modify their getwork to take one additional parameter, the address to send your share to.

The easy way for the pool operator would be to wait until the next block is found and divy it up proportionally as:
user's near-hits/total near-hits from everyone

That would be easier and safer to start up.  It also has the advantage that multiple hits from the same user can be combined into one transaction.  A lot of your hits will usually be from the same people.

The instant gratification way would be to pay a fixed amount for each near-hit immediately, and the operator takes the risk from randomness of having more or less near-hits before a block is found.

Either way, the user who submits the hit that solves the block should get an extra amount off the top, like 10 BTC.

New users wouldn't really even need the Bitcoin software.  They could download a miner, create an account on mtgox or mybitcoin, enter their deposit address into the miner and point it at anyone's pool server.  When the miner says it found something, a while later a few coins show up in their account.

Miner writers better make sure they never false-positive near-hits.  Users will depend on that to check if the pool operator is cheating them.  If the miner wrongly says it found something, users will look in their account, not find anything, and get mad at the pool operator.