Cooperative mining

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?

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.

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.

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.

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.

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.

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!

Am I the only one who thinks it would be way more simple to just rent distant shell access ??

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.

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.

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.

RQuote from: RHorning on November 28, 2010, 7:11:33 AM UTC

… 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.

I guess I do have a misunderstanding here, although there is another side effect in terms of hashes being made for blocks that aren’t won. Clearly that is a form of “proof of work” and at least represents effort being contributed to the pool and I guess I’m not convinced that “good faith efforts” to perform a hash ought to go unrewarded, but that clearly would be a part of the “rules” of the pool. As long as everybody is agreed ahead of time and this point is clear, I don’t see huge problems in that regard.

However, excluding potentially successful hashes would have the tendency of driving out weaker participants. I also think it would introduce a significant bias statistically toward the server operator as the number of successful blocks “won” compared to successful partial hashes for the current block would be considerably less than the 1/40 ratio. I envision a situation for pooling groups like this with more mundane clients where it would be common for only one person to get rewarded for a successful block hash using these rules. Or to put it in another context, on average there would be no benefit at all for somebody to join into such a pool with such rules where they would simply be more effective generating coins with the network itself.

Again, I’d like to see some statistics of this in practice, as all I’m making here is a conjecture based upon my own understanding of statistics.

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.

In terms of verifying a “near hit”, it would be verified against current rules but for a reduced difficulty. There is a statistical probability that such a near hit may even be a successful hash. Some “client” of the coin farm who is consistently reporting “false positive” on a hit would be almost instantly verified as such and be considered a troll where certainly they would not be rewarded or even recognized, and it would be in the interest of the server operator to simply blacklist those clients altogether or at least dump the connection.

Still, I get what you are saying here Satoshi in terms of the miner writers not producing something which produces these false-positives. This is something that ordinary economic theory would resolve so far as those mining clients are concerned. Somebody who comes up with a software package which only contains the communication protocol but doesn’t produce results would be quickly discarded by its users.

I love the idea here that somebody could install a miner on their computer without even installing the Bitcoins software itself. This implies that perhaps you could even put a miner on a cell phone or some other device if you cared (but of course chewing up battery life as a consequence). It does open up a whole bunch of potential ways to mine coins and expand the pool of potential CPUs engaged in this activity.

Oh, thank you ribuck, I definitely catched all your ideas. I’m happy that transaction to pool operator is already included in hash data, so cheating is practically impossible in that way. Now I have to solve only situations with false positives.

I think I definitely have enough information to knock up pool software now. Give me a time, I’m working on ;-).

Cooperative miner is almost ready. It is already working and pretty fast. Tested on ‘testnet’, my Intel Atom can manage clients >500Mhash/s without any significant load. There is just need for some web UI for users and a lot of code cleanup.

It is working with jgarzik’s cpuminer, m0mchil’s python miner and Diablo’s java miner pretty well. But I found one problem in comparing targets. As I understand their codes well, they don’t fully compare found hashes with target. So if I set difficulty pretty low, because I want many low-difficulty blocks for fair accounting, miners simply does not return correct hashes (hashes corresponding current target).

For example DiabloMiner. Even if I set target to ‘ffff..ffff00’, miner does not return hashes with less than eight zeros on the end. Am I wrong or miners really need patches to work correctly with low-difficulty targets?

When I set target with eight zeros on the end (so all tested miners work correctly with that target), computer with ~2mhash/s gives around 2 blocks per hour, which is IMHO too little for fair short-term distribution.

Hi all, I just started my own bitcoin mining server on http://mining.bitcoin.cz . Server was heavily tested on Testnet, but it is still beta stage software. But there is already ~600000khash/s of power and more will come tomorrow.

Server is based on principle which is discussed above and which satoshi accepted as possible. Server works with all CPU/GPU miners following standard getwork() interface - jgarzik’s CPU miner, m0mchil’s and Diablo’s GPU miners. All needed information are on site homepage.

Sending rewards - when block found, 50BTCs are written to server’s wallet, not on miner’s wallets. Every miner can specify own ‘sending treshold’, which is minimum amount to send to his wallet. This should help with sending 0.0001 BTCs and so on. Currently the cron script for sending is disabled, I will process few first payments manually - just to be sure that everything is working fine.

If you are interested, please open account, enter wallet address, register own workers and start mining! Also report all troubles, I will work on them ASAP! Please be patient with short server outages in this stage. In the most cases, miners will solve that by restarting itself.

First block found at 8:16 CET! (It reminds me I have to add timezone calculating or at least UTC times to statistics). Once bitcoins will be in the wallet, the first bitcoins will be sent :-). But you already see yours calculated reward on profile page. 4898 shares was needed to find the block.

yay, seems like we already solved our 2nd block.

are worker-stats updated when generations are matured? cuz they still show 0 found blocks.

yay, seems like we already solved our 2nd block.

are worker-stats updated when generations are matured? cuz they still show 0 found blocks.

Yes, we found second block at 16:10, see http://blk.bitcoinwatch.com/b?h=97886. First one from 07:16 is http://blk.bitcoinwatch.com/b?h=97834.

“Blocks’ in worker details are only valid block found by this worker. So currently only two workers have  ‘1’ in Block column. All stats are realtime.

I just sent first rewards! Please check your wallets and confirm if transfer was succesfull!

2010-12-17 01:38:22.037611
Testnet: False
Send 16.71 to 1CHwovmchLYrw9gAL7DUHnReDwyKySGjqg
Send 8.92 to 124TQXntz7akAYCrUxDjLuVg7fLGTJqcgt
Send 7.92 to 1JdEn5LeMREmAjcAi4KWf8EX6zkubqGn55
Send 1.66 to 13TSBH4wdchsMqFTwqyLjvPES99sZ96MaP
Initial balance: 50.0, sent total 35.21 for 4 people, time 0.3 sec

In system is 10 more people which send treshold is above their current reward. Sending script looks fine, so I will setup automatic transfering during Friday.