[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool
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 monitoringadvanced security with 2FA and payout address lockingservers in Europe, North America and Asiafree withdrawals above 0.01 BTCOvert AsicBoost compatible Start mining on Slush Pool
Basic Mining SetupAdvanced Mining Setupplease note only cgminer and BFGminer are supported ATM 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?
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) +
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.
Quote 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.
Quote from: satoshi on November 28, 2010, 4:03:30 PM UTCNew 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.