|
Title: Pooled/Remote Mining - Open Source - Updated 2010-12-24 Post by: puddinpop on October 13, 2010, 11:27:32 PM Due to the small likelihood that an individual CPU miner will find a block in a reasonable amount of time, and the expectation from new users to see results quickly, I have developed a server/client for bitcoin that will allow many individual miners to cooperate on solving blocks. This will effectively aggregate their hashing speed, allow solving blocks faster than individually possible, and distribute the generated bitcoins weighted by the contributing node's hash rate. This can also be used by an individual who doesn't want to run the full bitcoin client on a computer, but would still like to generate blocks with it.
Here is a basic overview of how it currently works. Someone runs bitcoin as a server, with optional connection password, to accept connections from remote clients. The server creates a unique block per client, keeps it in memory, and sends it to the client to hash. The client then hashes the block, appends the first byte of the generated hash to a buffer, and creates a metahash of the buffer when it is full and sends it to the server for later verification. The client increases the nonce of the block after every hash, but does not modify the block timestamp. The server will periodically send new blocks for the client to hash, either every 2 minutes, or when the client requests a new block because the nonce is close to overflowing. Every 10 seconds, the server picks a client with the oldest verified metahashes and verifies the last metahash from that client. The server will also send status updates to every client every 10 seconds. Currently there are absolutely no built-in negative consequences for a client sending erroneous data, other than being disconnected for sending malformed packets. The debug log will contain information about misbehaving nodes though. However, at this early stage in development, it might be bugs causing the issues rather than malicious clients, so this should be taken into consideration. Some things to consider:
bitcoin server command line options
client command line options
There is one issue I haven't been able to resolve. The hashing functions seem broken in release builds in Microsoft Visual Studio. In particular, the midstate buffer contains a bogus midstate when sending to the client. I have checked for buffer issues, and initialization issues, but I can see none. Upon placing error checking code and logging AFTER the hashing takes place, the results come out correct. Removing the checking code causes the issue to reappear and the midstate to be erroneous. Go figure. Anyway debug builds do not exhibit this issue. There probably is a bug somewhere, so maybe someone else can spot it. Downloads (Updated 2010-12-24) Pooled Miner Server/Client source based on SVN 205 (http://www.mediafire.com/file/12zi3g2k2sy1wze/bitcoin-remote-rpc-20110122-src.zip) Windows Binaries (http://www.mediafire.com/file/0j6dbydld9yzvrw/bitcoin-remote-20101224-win32bin.zip) See the following thread for details on connecting the miner to a server run by doublec Join a pooled bitcoin mining effort (http://bitcointalk.org/index.php?topic=2027.0) Title: Re: Pooled/Remote Mining Post by: Anonymous on October 14, 2010, 01:53:03 AM I want a botnet army muwahahahah!!
I have a server collecting dust if you want to set this up dave. Do you still have the irc channel details I sent you? Title: Re: Pooled/Remote Mining Post by: puddinpop on October 14, 2010, 02:03:14 AM You're awesome too. No share is sent to you is there? ;) Unless you contribute of course haha. No, there is no code in there to send anything to anyone other than the remote clients and the left over coins from rounding errors to the server operator. Quote So, how do you determine how much someone is contributing? I assume you send this information, but since it is open source, what prevents them from taking that number and * 10? It is based on the rate that they send their metahashes back to the server over the previous 60 seconds. Since the server verifies that the metahashes are correct periodically, you can be reasonably sure that this rate is a good estimate of the client's hash rate. Quote The default bitcoin client will not show coins less than 0.01, but you should not send coins smaller than that because you will get charged a transaction fee of 0.01. You should round everything off to 0.01. Since the creator of a block determines the fees it wouldn't make sense to include fees for our own blocks. The distribution of bitcoins are actually included in the output of the generated block, so everyone gets their share as soon as the block is generated and no fees are needed. Code: const int64 RemoteClientConnection::GetCalculatedKHashRate(const int sec) const Change the last line to: return hash; and I just increased my share of the pie? That only affects the calculation on the server, and everyone will still end up with the same ratio of their khash over total khash. All the client can do to affect this calculation is send valid metahashes as fast as possible. If they send invalid ones they will be detected. If they send duplicates ones, they are ignored. Title: Re: Pooled/Remote Mining Post by: ribuck on October 14, 2010, 10:03:38 AM I would have thought that a better way than a metahash to ensure honesty is to get the remote miners to send back genuine hashes at a lower level of difficulty.
Because there is a known relationship between the ease of generating hashes at different levels of difficulty, you could be sure that a remote miner submitting regular hashes at lower levels of difficulty is doing its fair share of work towards finding hashes at the official level of difficulty. Title: Re: Pooled/Remote Mining Post by: tcatm on October 14, 2010, 11:26:23 AM You could even calculate the clients true hashrate from low-difficulty results.
Title: Re: Pooled/Remote Mining Post by: puddinpop on October 14, 2010, 12:01:40 PM You could even calculate the clients true hashrate from low-difficulty results. If you did that, the client would then only have to send low difficulty hashes as fast as possible. There would be no incentive to hash the actual block trying to be solved. In order to make sure the client is hashing what it is supposed to and know how fast the client is hashing, the metahashes must be derived from the actual block the client is attempting to solve. There might be other ways to do this, but I think this is the easiest and most convenient. Title: Re: Pooled/Remote Mining Post by: tcatm on October 14, 2010, 12:22:29 PM If you did that, the client would then only have to send low difficulty hashes as fast as possible. There would be no incentive to hash the actual block trying to be solved. In order to make sure the client is hashing what it is supposed to and know how fast the client is hashing, the metahashes must be derived from the actual block the client is attempting to solve. There might be other ways to do this, but I think this is the easiest and most convenient. By calculating low-difficulty hashes for a block it will eventually calculate a target difficulty hash. Why shouldn't it submit it? It'll make it win coins. Title: Re: Pooled/Remote Mining Post by: puddinpop on October 14, 2010, 12:42:16 PM If you did that, the client would then only have to send low difficulty hashes as fast as possible. There would be no incentive to hash the actual block trying to be solved. In order to make sure the client is hashing what it is supposed to and know how fast the client is hashing, the metahashes must be derived from the actual block the client is attempting to solve. There might be other ways to do this, but I think this is the easiest and most convenient. By calculating low-difficulty hashes for a block it will eventually calculate a target difficulty hash. Why shouldn't it submit it? It'll make it win coins. I see what you mean now. Sending hashes for the target block that are a low difficulty. Well that could work, but I see 2 issues immediately. The first is that these hashes may or may not be produced in a regular manner, and there is not even a guarantee a client would produce one. The calculated hash rate based on this metric would have to be taken from a large sample size. The second issue is that each miner would now need to check the calculated hash against the target after every hash. This is another operation the client must perform and it will slow down generation. Title: Re: Pooled/Remote Mining Post by: tcatm on October 14, 2010, 01:14:26 PM I was curious and read the source. Your metahash approach isn't using separate block as I first thought and it's actually pretty similar to my idea. Maybe you can get rid of the array and just sum all previous hashes to save memory. That might work better with GPUs with low memory (2^32 tried metahashes are ~17 Gbytes).
Title: Re: Pooled/Remote Mining Post by: Gavin Andresen on October 14, 2010, 01:49:06 PM I see what you mean now. Sending hashes for the target block that are a low difficulty. Well that could work, but I see 2 issues immediately. The first is that these hashes may or may not be produced in a regular manner, and there is not even a guarantee a client would produce one. The calculated hash rate based on this metric would have to be taken from a large sample size. The second issue is that each miner would now need to check the calculated hash against the target after every hash. This is another operation the client must perform and it will slow down generation. I bet you'd get a good approximation of hash rate if clients submitted their best (highest difficulty) hash every N minutes. Over a period of a few hours the average of all of those best hashes should be proportional to the client's hash rate (unless a client were somehow repeatedly very lucky or unlucky, but that would be extremely unlikely). Title: Re: Pooled/Remote Mining Post by: jimbobway on October 14, 2010, 04:27:11 PM This is awesome, I hope to become a zombie to a botnet server soon (since I don't think I have the hardware and bandwidth to support a super server).
Title: Re: Pooled/Remote Mining Post by: ByteCoin on October 14, 2010, 06:36:47 PM The distribution of bitcoins are actually included in the output of the generated block, so everyone gets their share as soon as the block is generated and no fees are needed. So just to clarify, you're saying that the coins created as a result of block generation can be spent in the transactions included in that same block. Won't the new block be rejected because the coinbase is not matured? See ConnectInputs. The lack of fees if fees are warranted could also be a problem as ConnectInputs checks for that too. ByteCoin Title: Re: Pooled/Remote Mining Post by: Martian on October 14, 2010, 06:41:00 PM This is definitely awesome. I wonder if medium businesses would run something like this on their corporate LAN once bitcoin takes off. Assuming it's worth the electricity costs, having company resources earn income while idle could be very attractive.
Of course, businesses tend to have terrible pcs, but quantity has a quality all of its own. ;-) One thing is slightly worrying though. If, say, there was a very large global pooled mining server with a majority of CPU power, wouldn't it be able to produce double spending blocks? Title: Re: Pooled/Remote Mining Post by: puddinpop on October 14, 2010, 10:34:25 PM I was curious and read the source. Your metahash approach isn't using separate block as I first thought and it's actually pretty similar to my idea. Maybe you can get rid of the array and just sum all previous hashes to save memory. That might work better with GPUs with low memory (2^32 tried metahashes are ~17 Gbytes). It's only 1 byte of the resulting hash, so 4GiB for 2^32 hashes, which a modern card can transfer to main memory faster than the hashes can be computed. Memory on the card wouldn't factor into it anyway as you just send the results back in small blocks. I see what you mean now. Sending hashes for the target block that are a low difficulty. Well that could work, but I see 2 issues immediately. The first is that these hashes may or may not be produced in a regular manner, and there is not even a guarantee a client would produce one. The calculated hash rate based on this metric would have to be taken from a large sample size. The second issue is that each miner would now need to check the calculated hash against the target after every hash. This is another operation the client must perform and it will slow down generation. I bet you'd get a good approximation of hash rate if clients submitted their best (highest difficulty) hash every N minutes. Over a period of a few hours the average of all of those best hashes should be proportional to the client's hash rate (unless a client were somehow repeatedly very lucky or unlucky, but that would be extremely unlikely). What's to stop a client from lying? They simply generate a few hashes just to send and tell the server, "These are the best hashes I came up with, honest." In reality the client is spending the rest of the time trying to generate his own block. There is absolutely no way to verify that the client is not lying this way. With the metahash approach, you can verify every individual hash a client has reported solving. If they are lying, even about 1 of those hashes, you will know because the metahash doesn't match. The distribution of bitcoins are actually included in the output of the generated block, so everyone gets their share as soon as the block is generated and no fees are needed. So just to clarify, you're saying that the coins created as a result of block generation can be spent in the transactions included in that same block. Won't the new block be rejected because the coinbase is not matured? See ConnectInputs. The lack of fees if fees are warranted could also be a problem as ConnectInputs checks for that too. ByteCoin The server creates the block, which obviously doesn't include transactions utilizing the coins that are generated by that same block, mainly because there are no transactions derived from the block since no one knows about the block yet except the server. Title: Re: Pooled/Remote Mining Post by: ByteCoin on October 14, 2010, 11:34:58 PM Your "metahash" method of measuring work, though more accurate than the probablisitic methods of gavinandresen and tcatm, is a major weakness of your method. In order to check a portion of a client's work, you have to duplicate it. This will not scale well to even tens of clients. An attacker submitting bad metahashes to earn coins without really doing the work will just shut down when found out and start a new client on a new IP.
You would have to exclude new clients until a certain proportion of their results have been checked and then it becomes a probability game where the attackers only falsify perhaps an increasing proportion of their results. More seriously, you exclude clients (and servers) which are not 100% reliable. I know from Mersenne prime testing that some computers occasionally produce bad results. You can run normal software for years without noticing an error rate of one mistake in every 2^40 ops but your metahash would be very sensitive to such errors. This would result in people running genuine clients on slightly imperfect machines getting annoyed. Note that these imperfect machines are fine for normal hash generation or the probablistic hash rate calculation. You seem to think that the probablistic hash rate measurement schemes are insufficiently accurate. You might wish to do some calculations to convince yourself otherwise. There's already lots of unavoidable unfair randomness in the amount of computation required to produce a new block. The second issue is that each miner would now need to check the calculated hash against the target after every hash. This is another operation the client must perform and it will slow down generation. Eh? This happens anyway! How else do you tell if you've got a winning hash? What's to stop a client from lying? They simply generate a few hashes just to send and tell the server, "These are the best hashes I came up with, honest." Nothing. But then the inferred hash rate is very low. To clarify - the hash rate is calculated from the quality and/or number of hashes and NOTHING ELSE. The client doesn't say that it's done a certain amount of work - just the hashes matter.The server creates the block, which obviously doesn't include transactions utilizing the coins that are generated by that same block, mainly because there are no transactions derived from the block since no one knows about the block yet except the server. Ah. I thought you and I were thinking along the same lines of an elegant payment method that requires no trust and cannot be scammed which is unfortunately forbidden by a fairly inessential and inelegant Bitcoin rule.You need to go into more detail about how payment works. The solutions I can think of require the client to trust the server and/or can be scammed. ByteCoin Title: Re: Pooled/Remote Mining Post by: puddinpop on October 15, 2010, 02:42:31 AM Your "metahash" method of measuring work, though more accurate than the probablisitic methods of gavinandresen and tcatm, is a major weakness of your method. In order to check a portion of a client's work, you have to duplicate it. This will not scale well to even tens of clients. An attacker submitting bad metahashes to earn coins without really doing the work will just shut down when found out and start a new client on a new IP. You would have to exclude new clients until a certain proportion of their results have been checked and then it becomes a probability game where the attackers only falsify perhaps an increasing proportion of their results. Obviously you don't compute every single metahash sent by the clients. You hash them periodically, and when an erroneous one is found, or you have a suspicious client, you check more of them. Quote More seriously, you exclude clients (and servers) which are not 100% reliable. I know from Mersenne prime testing that some computers occasionally produce bad results. You can run normal software for years without noticing an error rate of one mistake in every 2^40 ops but your metahash would be very sensitive to such errors. This would result in people running genuine clients on slightly imperfect machines getting annoyed. Note that these imperfect machines are fine for normal hash generation or the probablistic hash rate calculation. Erroneous results would be a factor for any method of client verification. The solution is to allow a certain amount of error. Quote You seem to think that the probablistic hash rate measurement schemes are insufficiently accurate. You might wish to do some calculations to convince yourself otherwise. There's already lots of unavoidable unfair randomness in the amount of computation required to produce a new block. Indeed, there is a lot of randomness involved, causing the block generation rate to vary widely. Smoothing the client's reported hash rate out would require averaging over an unacceptable long time period. This unfairly penalizes clients who wish to hash for short periods of time, requires complex calculation logic, and results at best in rough estimates. Quote The second issue is that each miner would now need to check the calculated hash against the target after every hash. This is another operation the client must perform and it will slow down generation. Eh? This happens anyway! How else do you tell if you've got a winning hash? You compare 1 byte of the hash and only if that byte is 0 do you fully check the hash. Quote What's to stop a client from lying? They simply generate a few hashes just to send and tell the server, "These are the best hashes I came up with, honest." Nothing. But then the inferred hash rate is very low. To clarify - the hash rate is calculated from the quality and/or number of hashes and NOTHING ELSE. The client doesn't say that it's done a certain amount of work - just the hashes matter.That's exactly how it is now. Quote The server creates the block, which obviously doesn't include transactions utilizing the coins that are generated by that same block, mainly because there are no transactions derived from the block since no one knows about the block yet except the server. Ah. I thought you and I were thinking along the same lines of an elegant payment method that requires no trust and cannot be scammed which is unfortunately forbidden by a fairly inessential and inelegant Bitcoin rule.You need to go into more detail about how payment works. The solutions I can think of require the client to trust the server and/or can be scammed. ByteCoin The server is capable of sending the block with all transactions to the client for verification. It does not do so now, but the code would not be too difficult to add. There is actually a comment in the code to add this feature later. This way the client can verify they will get their share. If you would like more detail, the code is the best source of detail you can get. I bet you'd get a good approximation of hash rate if clients submitted their best (highest difficulty) hash every N minutes. Over a period of a few hours the average of all of those best hashes should be proportional to the client's hash rate (unless a client were somehow repeatedly very lucky or unlucky, but that would be extremely unlikely). What's to stop a client from lying? They simply generate a few hashes just to send and tell the server, "These are the best hashes I came up with, honest." In reality the client is spending the rest of the time trying to generate his own block. There is absolutely no way to verify that the client is not lying this way. With the metahash approach, you can verify every individual hash a client has reported solving. If they are lying, even about 1 of those hashes, you will know because the metahash doesn't match. Maybe you don't get what he's saying. Let's look at a target hash say 10 characters, the more 0's at the front the better. A bitcoin block needs 9 zeros to get a 50 coin block. You ask for their best result every 10 minutes. If they work for 1 minute on an average machine, they give you a result with 2 zeros. If they work for the whole 10 minutes, they give you a result with 4 zeros. All the results that they are looking for, would be based on the current hash, so there is NO wasted work. They just store their best in the client for the current hash, and send it when the server requests it. Switch back to the way bitcoin works. Difficulty factor of 1398. Someone trying to cheat sends you back a has worth a difficulty of 1. A real client sends you back a difficulty of 7. Someone on a GPU machine sends you back a difficulty of 190. The better way to do it, would be to request their best POW for each block. You could take the time each block took, the hash that they were able to find (which verify very quickly on the server side) and come up with a formula of what share they would get. The formula may include smoothing out the high peaks and lows. It may be the most complicated method... but it sounds so far to me, like the most accurate way to get both a relatively honest answer, and have it be relatively hack proof. All the while generating an appropriate potential block. How do they hack finding the best hash? If they are finding a stronger hash, they very well could be finding an actual block. Nothing is wasted in this scenario. I understand what this suggestion is, but I don't see it as a reliable method. It assumes you will generate a specific difficulty at a specific hash rate in a set amount of time. We all know this doesn't happen. How do you factor in unlucky clients? What about the lucky ones? The best you can do is take an average over an unacceptably long period of time to smooth out the hash rate. I think this method is too imperfect, and has potential to penalize or over reward clients too easily. I certainly wouldn't want to be the client penalized because I couldn't generate a good hash in a given amount of time. Title: Re: Pooled/Remote Mining Post by: ByteCoin on October 15, 2010, 04:23:00 AM You seem to value the accuracy provided by your "metahash" scheme while apparently tolerating a significant amount of fraud in real-use scenarios. I believe that the probablistic schemes advocated by everyone else are sufficiently accurate, quite possibly fraud proof and result in essentially zero server load. If we can agree some plausible real world parameters beforehand and I crank through the maths I believe I can prove that the random errors produced by the probablistic rate measurement are considerably smaller than the distortions caused by inevietable fraud. Would you change your mind if I proved this?
Erroneous results would be a factor for any method of client verification. The solution is to allow a certain amount of error. This strikes me as tricky without using lots of bandwidth. Are you saying you do this at the moment or you plan to do it? How does it work? There remain a couple of issues from your previous posts which I queried but which remain unaddressed. The second issue is that each miner would now need to check the calculated hash against the target after every hash. This is another operation the client must perform and it will slow down generation. This was in response to a suggestion from tatcm for measuring the hash rate by counting low difficulty hashes. You seem to be suggesting that one drawback of tatcm's suggestion is that you need to compare the hash to the target. You imply that your method avoids this comparison and is superior on that basis. You furthermore imply that the comparison operation has a significant computational cost compared to the hash operation. In order for you not to be wrong you need to show 1) how your method avoids comparing the hash against the target. 2) that the comparison is not of an insignificant cost compared to the hash operation. I assert that you will be unable to do so and that therefore you should withdraw your "second issue" with tatcm's suggestion. What's to stop a client from lying? They simply generate a few hashes just to send and tell the server, "These are the best hashes I came up with, honest." You seem to be under the impression that the rate calculation can be tricked by sending a few presumably low quality hashes which are the result of an insignificant computational effort. I assert that this is not possible. You need to show why you think the client can lie about its computational effort in this fashion. Please let me know whether you will only be convinced by an explicit numerical demonstration of the superiority of the probablistic hash rate meaurement scheme and also your response to the two outstanding issues from your previous posts which remain unanswered which are outlined above. Also an explanation of how your metahash scheme can efficiently tolerate computational errors would be welcome. ByteCoin Title: Re: Pooled/Remote Mining Post by: ribuck on October 15, 2010, 05:03:07 AM One of the most important things about the pooled mining will be participating in trusted groups. I don't think that trusted groups are needed if the probabalistic scheme is used.Each client, modified or not, knows the difficulty of the hashes it has produced and can calculate its expected long-term earnings, although of course there will be short-term fluctuations. A dishonest server will get caught out (and quite soon if several of the clients choose to share their statistics). A dishonest client doesn't get more than its real share of the earnings anyway. Title: Re: Pooled/Remote Mining Post by: ByteCoin on October 15, 2010, 05:57:39 AM I don't think that trusted groups are needed if the probabalistic scheme is used. Agreed. {Deleted incorrect stuff about clients cheating. Thanks to ribuck for putting me right.} Server cheating schemes and their prevention: The server can say that a lot of of not quite good enough hashes were submitted by clients owned by the server operator. To prevent this, the server must publish all the hashes which were used in the work calculation. The server can take the proof of work hashes of one or more of the genuine clients and attribute them to a client owned by the server operator. To prevent this the clients sign their hashes with the public key of the address which they want to be credited with their portion of the pot. The hashes and signatures are all published by the server. The server can omit to publish the signed hashes of a subset of the clients which are not controlled by him and which did not find the winning hash. This enhances his share of the pot. To prevent this, the clients periodically send signed hashes to the server and the server signs a recipt and returns it to the client. The client checks the recipt is valid before continuing work. If the server omits to publish a subset of the signed hashes then the client has proof that the server recieved them and can publish this to discredit the server. If the server signature is invalid then the client stops work and the amount of computation wasted is limited. I imagine that gavinandresen's "best hash within a time limit" will be a low bandwidth and predictable method of measuring hash speed in this scheme. Finally, the server can fail to distribute the 50BTC to the clients. To prevent this I thought the cunning idea was to have as the transactions in the new bock include the distribution of the newly minted 50BTC coinbase to the participants. This would have also prevented all the above attacks in one step. The clients would stop working on hashing the block if the block transactions did not divide the proceeds in a fashion the client thought was fair. I believe standard Bitcoin software rejects blocks attempting to spend coinbase that hasn't matured. If this could be changed to allowing the spend but making those transactions 0/unconfirmed until the coinbase matures then the whole problem goes away and we're all very happy. If the server gives the clients credit transactions which don't involve the prospectively minted coinbase but instead some other source of money then the clients can just submit those transactions to the network and get the credit before doing all the work thereby defrauding the server. Otherwise the client just has to take the server's word for it that the merkle root they're using includes transactions crediting them appropriately. There's no way of proving it. This is a problem. There might be a solution involving nifty scripting. ByteCoin Title: Re: Pooled/Remote Mining Post by: ribuck on October 15, 2010, 06:07:56 AM The client can cheat if it generates the winning hash in a naive implementation by failing to transmit the winning hash to the server and just transmitting it directly like a normal Bitcoin client and taking the 50BTC for itself. No, I don't think so.The block being hashed includes the 50BTC transaction awarded to the generator. So a client must decide (before looking for hashes) whether it is hashing a block that will pay itself, or a block that will pay the server. It can't find a hash first, and then decide who it is for. So there's no risk of cheating. If the client is looking for hashes that will pay itself, it's not participating in the shared mining and won't have any low-difficulty results to send back to the server either. Title: Re: Pooled/Remote Mining Post by: theymos on October 15, 2010, 12:28:53 PM I believe standard Bitcoin software rejects blocks attempting to spend coinbase that hasn't matured. If this could be changed to allowing the spend but making those transactions 0/unconfirmed until the coinbase matures then the whole problem goes away and we're all very happy. I think it's possible to create a coinbase transaction with one generation input and several outputs. Title: Re: Pooled/Remote Mining Post by: ByteCoin on October 15, 2010, 02:05:27 PM Thanks to ribuck for putting me right about client cheating. I have deleted the incorrect section from my post.
I think it's possible to create a coinbase transaction with one generation input and several outputs. Magic! I've just looked at the code and it seems to agree. How did you know this esoteric fact? In this case the scheme runs as follows: The server publishes its bitcoin address. Any clients wishing to participate start work hashing a block with the coinbase partly crediting themselves and partly crediting the server - possibly half and half?. After some period of time or after a transaction is received, whichever comes first the clients send their best hash signed by the public key they want credited to the server which calculates their share of the hashing effort using the quality of their hash. The server then publishes all the signed best hashes and a new block to be hashed incorporating all the new received transactions (if any) and the coinbase split among the the clients according to their share of the work. The server possibly takes a cut. The clients verify all the published signed hashes and verify that the coinbase output credits them fairly. A winning client can distribute the winning hash block to the Bitcoin network itself. The server has to publish the signed hashes and or the new block in a fashion so that everyone can see that everyone else sees the same thing otherwise the following server fraud is possible. Suppose there are 2 normal clients A and B and one server owned client X. They all hash at the same speed so obviously the coinbase should be split into equal thirds. However the server sends signed hashes and new block targets to A, omitting B's signed hashes and similarly pretends to B that A doesn't exist. No matter who generates the winning hash, X walks off with half the coinbase instead of the third he deserves. ByteCoin Title: Re: Pooled/Remote Mining Post by: puddinpop on October 16, 2010, 07:00:21 PM The original post has been updated with the latest source.
I've added the best hash to the results when the client sends back the metahash, and as I thought, the results are highly erratic. Averaging over 10 minutes doesn't reduce the error to an acceptable level. Averaging over longer periods would either mean clients must stay connected longer, or the server must save the client's work between client connections, and I'm not prepared to write all the code involved in tracking and saving client state. I think a dual approach would work best. Use the metahash for accurate hash rate and complete verifiability of hashes reported by a suspicious client, and use the best hash to quickly check a client's work. This will allow both scalability of verification and accuracy of the hash rate. I've also added the full block to the message sent to the client when sending work for the client to do. This way the client can verify the block has an output to their address. Also, I've added the ability to ban clients by adding them to a file named banned.txt. As far as verifying that the server isn't lying, I don't think that's possible with a multi client, single server architecture. The server can lie about anything to any client, and each client will be none the wiser. The only way around that is if each client has perfect knowledge of the other clients connected to the server. One way to do this is setting up something similar to a torrent tracker, where the server and each client register with the tracker, and the clients can use the tracker to verify the work they are doing and verify the server is also accurately reporting the work other clients are doing. Title: Re: Pooled/Remote Mining Post by: Gavin Andresen on October 17, 2010, 01:11:24 AM I've added the best hash to the results when the client sends back the metahash, and as I thought, the results are highly erratic. Averaging over 10 minutes doesn't reduce the error to an acceptable level. Averaging over longer periods would either mean clients must stay connected longer, or the server must save the client's work between client connections, and I'm not prepared to write all the code involved in tracking and saving client state. So... have clients send back their best N hashes (and the average should be N times better).RE: detecting server cheating: Over a very long period of time, clients should be able to figure out approximately how many hash/sec the server's network is generating. So they should be able to detect blatant cheating. I should've taken statistics in college, seems like it'd be an interesting problem to work out the chances that a server is lying based on how many blocks it has generated over the last week... Title: Re: Pooled/Remote Mining Post by: puddinpop on October 17, 2010, 02:18:39 AM Toss up a couple of windows binaries and I'll host a server if anyone would like to join to test it out. The first post has been updated with binaries. Because of the issue I was having with the hash generation, I had to turn optimizations off for the bitcoin and bitcoind binaries. I've added the best hash to the results when the client sends back the metahash, and as I thought, the results are highly erratic. Averaging over 10 minutes doesn't reduce the error to an acceptable level. Averaging over longer periods would either mean clients must stay connected longer, or the server must save the client's work between client connections, and I'm not prepared to write all the code involved in tracking and saving client state. So... have clients send back their best N hashes (and the average should be N times better).Now you're getting closer to just sending every hash the client generates. I thought the argument was against that. Title: Re: Pooled/Remote Mining Post by: LZ on October 17, 2010, 03:53:29 AM Thank you, puddinpop! Someone succeeded to generate a block?
Title: Re: Pooled/Remote Mining Post by: doublec on October 17, 2010, 10:25:26 AM Thank you, puddinpop! Someone succeeded to generate a block? So far there are eight clients connected to my server. No blocks generated yet but I'll be interested to see what happens when a block does finally get generated. Title: Re: Pooled/Remote Mining Post by: ByteCoin on October 17, 2010, 09:01:01 PM As far as verifying that the server isn't lying, I don't think that's possible with a multi client, single server architecture. The server can lie about anything to any client, and each client will be none the wiser. If you publish the information on a web page then if the clients want to check they can get the webpage through a proxy server. You don't know which client is really asking for the information so you can't misrepresent the state on a per-client basis. This, coupled with my signature and recipt scheme above prevents server cheating. Now you're getting closer to just sending every hash the client generates. I thought the argument was against that. Suppose the default situation is to send the best hash out of four thousand million.There's a big difference between now sending the top 100 hashes out of four thousand million and sending the four thousand million hashes. I doubt you're seriously objecting to the extra bandwidth used by gavinandresen's proposal. ByteCoin Title: Re: Pooled/Remote Mining Post by: doublec on October 17, 2010, 10:58:12 PM Is there any way for the server to see about how many k/hashs the pool is generating combined? It would be nice if the standard 'getinfo' returned the combined k/hashs in some way. The clients seem to get the information. It periodically prints it to the console. Title: Re: Pooled/Remote Mining Post by: puddinpop on November 27, 2010, 09:10:59 PM I've updated the initial post with the latest binaries and source based on SVN 191.
Title: Re: Pooled/Remote Mining Post by: bober182 on November 27, 2010, 11:15:46 PM I'm down for joining this any one got a good tutorial to set this up on a windows PC.
Title: Re: Pooled/Remote Mining Post by: puddinpop on November 28, 2010, 08:27:11 PM I'm down for joining this any one got a good tutorial to set this up on a windows PC. It's not complicated at all. Someone sets up a server that is publicly accessible, and everyone else runs the miner client with the -server parameter set to the server's IP address. If the server operator wants to use a port other than the default, or have a password required for connection, you simply add those parameters as well when you run the client. Title: Re: Pooled/Remote Mining Post by: bober182 on November 28, 2010, 11:46:39 PM What is the IP?
I just really hope no one from the forums decides to start making teams and starts splitting up generation that would ruin the point of this. Title: Re: Pooled/Remote Mining Post by: doublec on November 29, 2010, 01:13:01 AM What is the IP? I have a server running you can connect to if you want to test it out. You can connect to it using the windows binaries in the original post. See http://www.bluishcoder.co.nz/bitcoin-pool/ for IP address and other details.I just really hope no one from the forums decides to start making teams and starts splitting up generation that would ruin the point of this. Title: Re: Pooled/Remote Mining Post by: bober182 on November 29, 2010, 02:15:21 AM Okay got it running
OS Vista Fully patched Ram 2.5GB CPU Intel Centrino 2 Dual Core Duo Normally I get 800~1200 khash/s but with this I get around 300,333,366,400,433 I'm assuming thats the weird way it shows speed. I noticed that it uses one core only can this be fixed. So I'm running 2 at a time to make up for that both at around 366+ this still adds up to the lower estimates of the normal client. Will this work on guest accounts then I could run it at school. Also how is the 50 BC split now. Title: Re: Pooled/Remote Mining Post by: doublec on November 29, 2010, 02:24:01 AM Okay got it running noticed that it uses one core only can this be fixed. So I'm running 2 at a time to make up for that both at around 366+ this still adds up to the lower estimates of the normal client. Will this work on guest accounts then I could run it at school. Also how is the 50 BC split now. Yes each instance of remoteminer only uses one core. The idea (I assume) is to run multiple instances for each core. It will always be a little slower than the normal client due to the communication overhead of talking to the remote server. It should work on guest accounts and the 50BC is split based on the khash contributed to the solution of each connected miner. puddinpop will be able to explain more on this since they wrote the code. I'll try and get a GPU miner connected to up the khash rate soon. Title: Re: Pooled/Remote Mining Post by: bober182 on November 29, 2010, 02:29:56 AM You guys say its split based on the rate. Will this not mean if I have connect and disconnect a lot with my super mega fast client I get more then a non stop small guy. It should be done by the amount of hashes you computed to the amount it too to solve the block.
Title: Re: Pooled/Remote Mining Post by: doublec on November 29, 2010, 04:32:00 AM puddinpop, there seems to be a typo in cmake-bitcoinr/CMakeList.txt. The references to 'bitcoind' in TARGET_LINK_LIBRARIES should be 'bitcoinr'.
Title: Re: Pooled/Remote Mining Post by: puddinpop on November 29, 2010, 02:18:20 PM Okay got it running OS Vista Fully patched Ram 2.5GB CPU Intel Centrino 2 Dual Core Duo Normally I get 800~1200 khash/s but with this I get around 300,333,366,400,433 I'm assuming thats the weird way it shows speed. I noticed that it uses one core only can this be fixed. So I'm running 2 at a time to make up for that both at around 366+ this still adds up to the lower estimates of the normal client. The calculated hash rate is averaged over a period of time, so it will start off low and increase until it approaches the actual hash rate. There is overhead in calculating the metahash, finding the best hash, and networking, so you won't get the hash rate you get with the vanilla bitcoin client. Quote from: bober182 Will this work on guest accounts then I could run it at school. As long as you can run random executables, have the firewall allow the traffic, and have the Visual C++ 2005 Runtime files installed it will work, but I don't suggest you run this anywhere you don't have permission to. Quote from: bober182 Also how is the 50 BC split now. It's based on the proportion of the contributing node's calculated hash rate to the total hash rate of all nodes. If you contribute 1000 khash/s and all other nodes contribute 4000 khash/s, you get 1/5 of the 50 BTC. You guys say its split based on the rate. Will this not mean if I have connect and disconnect a lot with my super mega fast client I get more then a non stop small guy. It should be done by the amount of hashes you computed to the amount it too to solve the block. The distribution of payment is determined by which clients are connected at the time the block is created. If you connect and disconnect multiple times, only the last active connection will be valid. In addition, because of the averaging of hash rate over a period of time, the client will start off with a low calculated hash rate after each connection. puddinpop, there seems to be a typo in cmake-bitcoinr/CMakeList.txt. The references to 'bitcoind' in TARGET_LINK_LIBRARIES should be 'bitcoinr'. Yes there is. All the bitcoind in that file should be bitcoinr. Title: Re: Pooled/Remote Mining Post by: bober182 on November 29, 2010, 10:22:24 PM When I got on at the beginning there was 2 others plus my two at around 2500khash then i later saw 6 at 3500khash and even 10 at 6000khash. Right now its 2 at 800 (only me).
Title: Re: Pooled/Remote Mining Post by: doublec on November 29, 2010, 10:47:16 PM @davidonpda, I ran it previously but stopped since no one was using it and the client got outdated. I restarted it with puddinpop's recent version yesterday when I posted the IP address. The number of clients, as bober182 noted, has ranged from 2 to 10.
What's needed is a larger number of people to contribute (and hopefully someone with a GPU) so that the lesser powered CPU clients can start getting some benefit from being involved. I'm not sure if that will happen though as the GPU clients are probably more likely to want to keep mining for themselves. Title: Re: Pooled/Remote Mining Post by: FreeMoney on November 30, 2010, 01:00:55 AM @davidonpda, I ran it previously but stopped since no one was using it and the client got outdated. I restarted it with puddinpop's recent version yesterday when I posted the IP address. The number of clients, as bober182 noted, has ranged from 2 to 10. What's needed is a larger number of people to contribute (and hopefully someone with a GPU) so that the lesser powered CPU clients can start getting some benefit from being involved. I'm not sure if that will happen though as the GPU clients are probably more likely to want to keep mining for themselves. Even GPU generators are beginning to be exposed to some high variance and that will only grow. Title: Re: Pooled/Remote Mining Post by: bober182 on November 30, 2010, 05:41:27 AM But in theory assuming the current difficulty does not rise.
50 bitcoins are generated per block for now. If your going at 1000khash and it takes 1 month to get the coins this sucks. Meanwhile, someone going at 4000khash will make 4 blocks before you make one. So 5 blocks have been made in one month and you have 50 bitcoins and your GPU nemesis has 200 bitcoins. If you use correct pooling that measures not speed at generation but how many hashes generated. After one week you may not find the winning hash but GPU will. You get 10 bitcoin he gets the other 40. After the month has ended and you and him generate 5 blocks together. You will still have 50 bitcoins and he will have his 200. All this does is divide the way bitcoins are generated to a quicker approach. A weak machine will only get its fair 50 after the time it would normally take to generate a coin. If every last bitcoin user joined in on a network bitcoins would tick in at a and even rate still giving GPU and server farms more coins then the rest but allowing CPU users to get a bit of coins before they die. I truly hope there wont be a competition with the pooled mining teams and that the server doesn't start taking fees. Title: Re: Pooled/Remote Mining Post by: da2ce7 on November 30, 2010, 05:46:15 AM My GPU mining computer melted... (stupid Aussie summer heat)... One I have it back running (1 week approx) I'll volunteer to join for debugging.
Title: Re: Pooled/Remote Mining Post by: bober182 on November 30, 2010, 05:53:51 AM Can someone edit the first post to include the server IP so we can all join in this.
Also if the IP owner doesn't want to keep running it I will see if I can take over. Does This app work with domains instead of IPs? Title: Re: Pooled/Remote Mining Post by: doublec on November 30, 2010, 08:48:53 AM Can someone edit the first post to include the server IP so we can all join in this. Also if the IP owner doesn't want to keep running it I will see if I can take over. Does This app work with domains instead of IPs? I'm fine with keeping it running. It runs on a VPS which isn't doing much else. I'll be monitoring the CPU usage and bandwidth but it looks like it doesn't use much. Title: Re: Pooled/Remote Mining Post by: doublec on November 30, 2010, 09:25:06 AM My GPU mining computer melted... (stupid Aussie summer heat)... One I have it back running (1 week approx) I'll volunteer to join for debugging. Unfortunately it seems there's no GPU enabled remote miner client. What is your GPU setup? CUDA or OpenCL? Windows, Linux or Mac?Title: Re: Pooled/Remote Mining Post by: doublec on December 01, 2010, 09:11:43 AM If you want people to connect to you, create a new thread stating such, in the main post give your IP address, and link the binaries and a simple how to. Keep it up-to-date if new releases come out. I started a webpage with details: http://www.bluishcoder.co.nz/bitcoin-pool/ Title: Re: Pooled/Remote Mining Post by: puddinpop on December 01, 2010, 10:40:48 PM I've updated the first post with the newest source and binaries.
The main changes are
Title: Re: Pooled/Remote Mining Post by: doublec on December 01, 2010, 11:47:09 PM I've updated the first post with the newest source and binaries. Thanks, I've updated the my pool server to use this. I like the extra information the remote client shows! Title: Re: Pooled/Remote Mining Post by: doublec on December 01, 2010, 11:59:11 PM Some changes I had to make to the latest source to get building on Linux:
1. I had to add the following lines to the end of cmake-bitcoinr/CMakeLists.txt IF(NOT WIN32) TARGET_LINK_LIBRARIES(bitcoinr pthread) ENDIF(NOT WIN32) It needed pthread to link on Linux. I made it 'NOT WIN32' in case it's needed on Mac too. 2. In src/remote/remotebitcoinheaders.h, removed the "../blah.h" includes and replaced them all with a single: #include "../headers.h" This got things included in the right order. Not sure if that's the optimal fix. Title: Re: Pooled/Remote Mining Post by: bober182 on December 02, 2010, 12:36:49 AM BUG
If I close all my miners and restart them I lose all the Coins from the current Block that i should have received. Maybe use a table or array to store address in memory so people on the go can use it or even if there internet goes out. Title: Re: Pooled/Remote Mining Post by: puddinpop on December 02, 2010, 11:12:19 PM BUG If I close all my miners and restart them I lose all the Coins from the current Block that i should have received. Maybe use a table or array to store address in memory so people on the go can use it or even if there internet goes out. That's not a bug, that is how it was designed to work, and you're not losing anything, as no blocks were generated while you were connected. You need to be connected and actively contributing to get a share of the coins. Now I am currently working on an alternate distribution method that would count all hashes sent to the server since the last solved block, and distribute based on that. The server operator will have to select which distribution method they want to use. Title: Re: Pooled/Remote Mining Post by: bober182 on December 02, 2010, 11:14:58 PM Is the other one not flawed then Assuming each block is generated every 10 minuets can I not connect a lot of C/GPU power for the final minuet and get a bigger share ever tho I did little work.
Title: Re: Pooled/Remote Mining Post by: puddinpop on December 02, 2010, 11:23:20 PM Is the other one not flawed then Assuming each block is generated every 10 minuets can I not connect a lot of C/GPU power for the final minuet and get a bigger share ever tho I did little work. I'm at a loss to understand why you think sending a deluge of valid hashes near the end of block generation, or any other time for that matter, would somehow result in a flawed implementation. The hashes are either valid or not. It doesn't matter how many are sent, or when they are sent. They are either valid and counted, or not valid and discarded. Title: Re: Pooled/Remote Mining Post by: bober182 on December 02, 2010, 11:27:34 PM Assuming blocks are generated roughly every ten minuets what I can do is generate a block by myself for the full 50 BTC for about 9 minuets then hop on to the server and pump a fast hash rate the server will calculate that I should get some bitcoins even tho I have not helped out a lot. If you count Hashes that are sent it will fix this. Also if some one disconnects 10 seconds before the block is found and they where the leading hash speed they get nothing and everyone else gets a lot more then they should.
Title: Re: Pooled/Remote Mining Post by: BitLex on December 02, 2010, 11:32:01 PM and why do you expect the pool to get "the next" block?
it's not only you and the pool on the network, there's others creating blocks all the time and you might get nothing for a very long time. not sure if i like the count-all-hashes-idea, it kinda erases the lottery-style of bitcoin. Title: Re: Pooled/Remote Mining Post by: puddinpop on December 02, 2010, 11:43:32 PM Assuming blocks are generated roughly every ten minuets what I can do is generate a block by myself for the full 50 BTC for about 9 minuets then hop on to the server and pump a fast hash rate the server will calculate that I should get some bitcoins even tho I have not helped out a lot. If you count Hashes that are sent it will fix this. Also if some one disconnects 10 seconds before the block is found and they where the leading hash speed they get nothing and everyone else gets a lot more then they should. If a client disconnects who was generating a large amount of hashes, and the block was subsequently solved, then he wasn't involved in the creation of the block at all. It doesn't matter if he provided 99.99% of all hashes up to that point if none of those hashes generated a block. One and only one client generates the block. You value total hashes contributed more than hash rate at a point in time, but others may not value this distribution method as much as the current method. Some may think one method is more fair than the other. Both methods will be available in the next release, and the server operator will need to decide what to use. not sure if i like the count-all-hashes-idea, it kinda erases the lottery-style of bitcoin. Well, as you can see, some people like the "count all hashes contributed" approach, and some prefer the "connected client hash rate" method. I'm in the process of uploading a new version which includes the new method. Title: Re: Pooled/Remote Mining Post by: puddinpop on December 02, 2010, 11:56:29 PM I've updated the first post with the latest release. This includes a backwards incompatible change. Clients and servers both need to run either the old version or this version. Otherwise the clients will hammer the server with connections, only to be disconnected over and over. I suggest server operators let everyone know the time they will be updating, and everyone else make their best effort to update their clients at that time.
Title: Re: Pooled/Remote Mining Post by: doublec on December 03, 2010, 04:30:26 AM I suggest server operators let everyone know the time they will be updating, and everyone else make their best effort to update their clients at that time. I will most likely be doing this after the weekend sometime. I'll post a more exact date/time later.I've been requested to set up a git repository with changes specific to getting the remote miner compiled on linux. I've done this and it's at: https://github.com/doublec/bitcoin-pool The 'master' branch should build the remote miner only on linux by running cmake followed by make. The 'bitcoin-remote-20101201' branch contains the source originally from puddinpop for that version with no changes. You can get a diff to see my (minor) changes to get things to build by diffing these two branches. Title: Re: Pooled/Remote Mining Post by: doublec on December 04, 2010, 06:41:31 AM For those not following the other thread, the pool generated its first block today:
http://blockexplorer.com/block/00000000000233334b157d901714baf59e5b9236227b2878844e52244da4195e Title: Re: Pooled/Remote Mining Post by: jon_smark on December 04, 2010, 09:41:19 PM Hi,
I get a compilation error when building under Ubuntu Lucid in an x86_64 arch. I just got the latest version from github, and the only modification I made was adding the following code to the end of cmake-bitcoinr/CMakeLists.txt as described previously in this thread. Code: IF(NOT WIN32) Anyway, though the invocation of 'cmake .' succeeds: Code: -- The C compiler identification is GNU the actual compilation fails: Code: smark@mymachine:~/software/bitcoin-pool$ make Any idea of what might wrong here? Thanks in advance! Jon. Title: Re: Pooled/Remote Mining Post by: matt on December 04, 2010, 11:59:26 PM Hi, I get a compilation error when building under Ubuntu Lucid in an x86_64 arch. I just got the latest version from github, and the only modification I made was adding the following code to the end of cmake-bitcoinr/CMakeLists.txt as described previously in this thread. Code: IF(NOT WIN32) Anyway, though the invocation of 'cmake .' succeeds: Code: -- The C compiler identification is GNU the actual compilation fails: Code: smark@mymachine:~/software/bitcoin-pool$ make Any idea of what might wrong here? Thanks in advance! Jon. I'm having identical issues trying to compile for an AMD64 server running Debian Lenny. :| Title: Re: Pooled/Remote Mining Post by: FairUser on December 05, 2010, 12:39:27 PM I just notice my bitcoinr log file showed the server was down for a few minutes, and now it shows the additional line:
0 blocks generated since 2010-12-05 12:16:18 UTC Thanks for the extra info. However, I've noticed my bitcoinr log also says "Server reports my khash/s as 566" very consistently. This use to say "Server reports my khash/s as 833" very consistently. I'm seeing the same behavior accross my 3 boxes I have running bitcoinr. I'm curious as to what changed on the server side, cause I didn't change a thing on my end and it seems to report less khash/s now than it did before the change. Title: Re: Pooled/Remote Mining Post by: doublec on December 05, 2010, 12:43:01 PM I just notice my bitcoinr log file showed the server was down for a few minutes, and now it shows the additional line: 0 blocks generated since 2010-12-05 12:16:18 UTC The server stopped for some reason. I've restarted it. However, I've noticed my bitcoinr log also says "Server reports my khash/s as 566" very consistently. This use to say "Server reports my khash/s as 833" very consistently. I'm seeing the same behavior accross my 3 boxes I have running bitcoinr. I'm curious as to what changed on the server side, cause I didn't change a thing on my end and it seems to report less khash/s now than it did before the change. The khash rate seems to be oscillating for me. It reports 400 khash/s then the next report it's 1600. The average of those 2 is 1,000 which is the normal rate for my cpu. Odd. The total combined khash rate is also oscillating. I think the server is overloaded. It's pegged at a 100% CPU right now with 143 clients. Title: Re: Pooled/Remote Mining Post by: FairUser on December 05, 2010, 12:45:57 PM Scratch that.
It seems to have come back around and seems a bit more normal the last few minutes. I just notice my bitcoinr log file showed the server was down for a few minutes, and now it shows the additional line: 0 blocks generated since 2010-12-05 12:16:18 UTC Thanks for the extra info. However, I've noticed my bitcoinr log also says "Server reports my khash/s as 566" very consistently. This use to say "Server reports my khash/s as 833" very consistently. I'm seeing the same behavior accross my 3 boxes I have running bitcoinr. I'm curious as to what changed on the server side, cause I didn't change a thing on my end and it seems to report less khash/s now than it did before the change. Title: Re: Pooled/Remote Mining Post by: FairUser on December 05, 2010, 12:53:10 PM Yeah, I'm starting to see that too. It's jumping between 433 and 1633 for me.
Should be averaging around 833 typically. Odd indeed. Title: Re: Pooled/Remote Mining Post by: FairUser on December 05, 2010, 01:14:59 PM Status update: Offline again. Traceroute seems fine though.
Title: Re: Pooled/Remote Mining Post by: doublec on December 05, 2010, 01:19:38 PM Status update: Offline again. Traceroute seems fine though. Yep, server died again. I'm looking into it. Title: Re: Pooled/Remote Mining Post by: FairUser on December 05, 2010, 01:24:30 PM You mentioned previously that your server was running 80-100% CPU. Is it possible that there could be too many clients now and the server is just under heavy load?
I saw the number of clients in the 180's earlier with the group doing ~200,000 khash/s. Title: Re: Pooled/Remote Mining Post by: doublec on December 05, 2010, 01:27:11 PM You mentioned previously that your server was running 80-100% CPU. Is it possible that there could be too many clients now and the server is just under heavy load? I saw the number of clients in the 180's earlier with the group doing ~200,000 khash/s. Yes, most likely. As a quick workaround I've brought a second server online. If the number of clients on one is greater than 100 I suggest connecting to the second instead. The second server is at IP address 173.255.205.10 so the client command is: remoteminer.exe -server 173.255.205.10 -address abitcoinaddress With 100 on each this will handle current load until I look into the issue. Title: Re: Pooled/Remote Mining Post by: doublec on December 05, 2010, 01:34:15 PM puddinpop, it'd be great to have a way to set a maximum number of clients and maybe have a message printed to the client trying to connect if that is exceeded. Any thoughts on how to decrease the CPU usage of the server?
Title: Re: Pooled/Remote Mining Post by: doublec on December 05, 2010, 01:48:38 PM Yes, most likely. As a quick workaround I've brought a second server online. If the number of clients on one is greater than 100 I suggest connecting to the second instead. The second server is at IP address 173.255.205.10 so the client command is: I've temporarily hacked in a hard coded limit of 102 clients. Any connects after that will fail. Unfortunately no message is printed to the client and it immediately retries but it beats the server crashing. Title: Re: Pooled/Remote Mining Post by: jon_smark on December 05, 2010, 03:35:21 PM So it seems I'm not the only one having trouble compiling the code on an x86_64 platform. Is it a known limitation that the code will only compile on 32-bit architectures? Or has someone managed to get it running on a 64-bit arch?
Cheers, Jon Title: Re: Pooled/Remote Mining Post by: puddinpop on December 05, 2010, 06:35:35 PM I've updated the first post with a new release. As before, the client and server must be at least the ones from 2010-12-02 to work with each other. This release should help alleviate the hash rate fluctuation, especially if it is caused by CPU usage on the server. The CPU usage itself won't be reduced, but it should be more stable. Also, there is an experimental remote CUDA client included in the release. Expect half the hash rate you get with the regular CUDA miner built into the standard client.
Please note that the way to specify options for the remote miner has changed. Now you use = instead of space between the option and the value. Title: Re: Pooled/Remote Mining Post by: doublec on December 05, 2010, 11:51:37 PM I've updated the first post with a new release. As before, the client and server must be at least the ones from 2010-12-02 to work with each other. This release should help alleviate the hash rate fluctuation, especially if it is caused by CPU usage on the server. The CPU usage itself won't be reduced, but it should be more stable. Also, there is an experimental remote CUDA client included in the release. Expect half the hash rate you get with the regular CUDA miner built into the standard client. Please note that the way to specify options for the remote miner has changed. Now you use = instead of space between the option and the value. I plan to switch the pool to this version at 5:00 am Monday 6 December UTC. That's 5 hours from the time I posted this. This will require contributers to update the miner software. I'll post here when the switch is done. The server will use the 'contributed' method. Title: Re: Pooled/Remote Mining Post by: FairUser on December 06, 2010, 12:50:09 AM puddinpop, what's the URL we can get this from?
Title: Re: Pooled/Remote Mining Post by: doublec on December 06, 2010, 12:54:09 AM puddinpop, what's the URL we can get this from? puddinpop updated the original post with source and binaries. I've also added it to my git repository in the 'bitcoin-remote-20101205' branch: https://github.com/doublec/bitcoin-pool I've just pushed to master the tweaks to build the miner only code on linux. Title: Re: Pooled/Remote Mining Post by: doublec on December 06, 2010, 03:09:24 AM I updated the server on 173.255.205.10 early since there were only 4 clients connected. Instructions updated here:
http://www.bluishcoder.co.nz/bitcoin-pool/ Basically you need the new client binary. The windows version is now called remoteminer-cpu.exe and the arguments to it require '=' instead of a space between the '-address' and its value (and '-server' and its value). There's also a remoteminer-cuda.exe for those with a cuda compatible GPU. Let see how well this handles load. If it's fine I'll take down the other server. Title: Re: Pooled/Remote Mining Post by: doublec on December 06, 2010, 03:25:59 AM puddinpop, when running this latest version I'm always seeing a message on the remote client saying that my address is not found in the block being solved. It doesn't show the share that I'd get that it used to. Is something broken or is there a change in the behaviour?
Title: Re: Pooled/Remote Mining Post by: pc on December 06, 2010, 03:30:36 AM I'm having a terrible time trying to get this running on my Mac. I think I've complied and installed the Boost library, and installed the CMake and CUDA library, which this seems to need, but I'm still getting the following when I try to make:
Quote Relm:~/Downloads/bitcoin-remote-20101205-src% make [ 8%] Building NVCC (Device) object cmake-bitcoinr/./bitcoinr_generated_bitcoinminercuda.cu.o Scanning dependencies of target bitcoinr [ 16%] Building CXX object cmake-bitcoinr/CMakeFiles/bitcoinr.dir/__/src/remoteminermain.cpp.o In file included from /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/remotebitcoinheaders.h:34, from /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remoteminermain.cpp:19: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../serialize.h: In function ‘void Unserialize_impl(Stream&, std::vector<T, A>&, int, int, const boost::true_type&)’: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../serialize.h:475: error: there are no arguments to ‘min’ that depend on a template parameter, so a declaration of ‘min’ must be available /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../serialize.h:475: error: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated) /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../serialize.h: In function ‘void Unserialize(Stream&, std::map<K, T, Pred, A>&, int, int)’: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../serialize.h:588: error: ‘pair’ was not declared in this scope /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../serialize.h:588: error: expected primary-expression before ‘,’ token /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../serialize.h:588: error: expected primary-expression before ‘>’ token /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../serialize.h:588: error: ‘item’ was not declared in this scope /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../serialize.h: In member function ‘void secure_allocator<T>::deallocate(T*, size_t)’: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../serialize.h:700: error: ‘allocator’ was not declared in this scope /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../serialize.h:700: error: expected primary-expression before ‘>’ token /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../serialize.h:700: error: ‘::deallocate’ has not been declared In file included from /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/remotebitcoinheaders.h:36, from /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remoteminermain.cpp:19: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h: At global scope: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:98: error: ‘u_int’ does not name a type /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h: In function ‘void Sleep(int64)’: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:106: error: ‘boost::thread’ has not been declared /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:106: error: ‘get_system_time’ is not a member of ‘boost’ /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h: At global scope: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:110: error: ‘myclosesocket’ declared as an ‘inline’ variable /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:110: error: ‘SOCKET’ was not declared in this scope /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:110: error: ‘hSocket’ was not declared in this scope /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:111: error: expected ‘,’ or ‘;’ before ‘{’ token /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:214: error: ‘boost::interprocess’ has not been declared /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:214: error: ISO C++ forbids declaration of ‘interprocess_recursive_mutex’ with no type /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:214: error: expected ‘;’ before ‘mutex’ /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h: In member function ‘void CCriticalSection::Enter()’: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:218: error: ‘mutex’ was not declared in this scope /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h: In member function ‘void CCriticalSection::Leave()’: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:219: error: ‘mutex’ was not declared in this scope /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h: In member function ‘bool CCriticalSection::TryEnter()’: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../util.h:220: error: ‘mutex’ was not declared in this scope In file included from /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/remotebitcoinheaders.h:37, from /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remoteminermain.cpp:19: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../bignum.h: In member function ‘void CBigNum::Unserialize(Stream&, int, int)’: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../bignum.h:355: error: ‘vector’ was not declared in this scope /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../bignum.h:355: error: expected primary-expression before ‘unsigned’ /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../bignum.h:355: error: expected `;' before ‘unsigned’ /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/../bignum.h:356: error: ‘vch’ was not declared in this scope In file included from /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remoteminermain.cpp:20: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/remoteminerclient.h: At global scope: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/remoteminerclient.h:118: error: ‘SOCKET’ does not name a type /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/remoteminerclient.h: In member function ‘const bool RemoteMinerClient::IsConnected() const’: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/remoteminerclient.h:44: error: ‘m_socket’ was not declared in this scope /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/remoteminerclient.h:44: error: ‘SOCKET’ was not declared in this scope make[2]: *** [cmake-bitcoinr/CMakeFiles/bitcoinr.dir/__/src/remoteminermain.cpp.o] Error 1 make[1]: *** [cmake-bitcoinr/CMakeFiles/bitcoinr.dir/all] Error 2 make: *** [all] Error 2 It's highly likely that I've screwed something up trying to get this to all work (my guess is Boost), but there's not really much in the way of direction. Can anyone give me a hand? Thanks. Title: Re: Pooled/Remote Mining Post by: puddinpop on December 06, 2010, 03:37:19 AM puddinpop, when running this latest version I'm always seeing a message on the remote client saying that my address is not found in the block being solved. It doesn't show the share that I'd get that it used to. Is something broken or is there a change in the behaviour? It will distribute the coins in the block the same as it did before. If you see the message that the address wasn't found after the client gets its second block, that means something isn't working quite right on the server. Check the bitcoin log file to see if there are any messages about clients failing metahash verification. Most likely, if you are compiling the server yourself, you ran into the same issue I have with release builds in Visual Studio. If this is the case, try to compile without optimizations turned on. I've tested with the binaries that I've uploaded, and I can confirm that they are working as they should be. Title: Re: Pooled/Remote Mining Post by: doublec on December 06, 2010, 03:54:43 AM It will distribute the coins in the block the same as it did before. If you see the message that the address wasn't found after the client gets its second block, that means something isn't working quite right on the server. Check the bitcoin log file to see if there are any messages about clients failing metahash verification. There are no failed hashes in the log. But there only seems to be one client passing: If I grep the log for "passed metahash" all I see is one client IP address listed. There are 16 clients connected to the server. Title: Re: Pooled/Remote Mining Post by: Moredread on December 06, 2010, 04:06:46 AM Hi puddinpop,
what's the status of your OpenCL implementation atm? I see you have begun a implementation although it is disabled currently. Title: Re: Pooled/Remote Mining Post by: BitLex on December 06, 2010, 04:19:57 AM the remotminer-cuda.exe seems to work already,
although it's still slower than standalone-versions. on my GTX260 i get standalone ~45M remote-cuda ~17M hopefully the "Address ... not found in block solved" thingie doesnt cause any bigger problems update: i just noticed that the remote-cuda.exe also has ~50% CPU usage, that's unpleasant. Title: Re: Pooled/Remote Mining Post by: doublec on December 06, 2010, 04:25:15 AM hopefully the "Address ... not found in block solved" thingie doesnt cause any bigger problems There might be some server up and down-age as I add some debugging to investigate this. Clients should reconnect gracefully. Don't panic if you see it :) Title: Re: Pooled/Remote Mining Post by: doublec on December 06, 2010, 04:36:33 AM puddinpop, there appears to be no call to SetLastVerifiedMetaHash in the current code, whereas there is in the last version. Is this a bug?
Title: Re: Pooled/Remote Mining Post by: inertia on December 06, 2010, 04:39:37 AM That was graceful. Nice!
Title: Re: Pooled/Remote Mining Post by: doublec on December 06, 2010, 05:22:05 AM I added a call to SetLastVerifiedMetaHash but that didn't fix the issue for the contributed distributed type. So I've switched back to 'connected' and this displays the address as being in the pool.
I'll switch back to 'contributed' if the issue is resolved. Title: Re: Pooled/Remote Mining Post by: FreeMoney on December 06, 2010, 06:23:37 AM I added a call to SetLastVerifiedMetaHash but that didn't fix the issue for the contributed distributed type. So I've switched back to 'connected' and this displays the address as being in the pool. I'll switch back to 'contributed' if the issue is resolved. Imagine there were multiple servers running the contributed method. Wouldn't the optimal thing for a miner to do to be to continually jump to the server that had most recently generated since the same power will be worth more there since you are sharing with fewer previous work units? Title: Re: Pooled/Remote Mining Post by: FairUser on December 06, 2010, 12:25:48 PM Q: How would one go about running their own mining server?
I read the readme and tried to setup my own mining server, but it doesn't seem to be acting like a server. I tried the "-remoteserver" flag, but it doesn't take it. Could someone please provide an example of what command and options I would use to start a mining server? Also an example of the what client's would have to run to connect to my server. Thanks! :) Title: Re: Pooled/Remote Mining Post by: kabo on December 06, 2010, 08:36:21 PM I'm also having issues building on Debian (Lenny).
Code: me@K230255:~ $ git clone git://github.com/doublec/bitcoin-pool Any ideas? Title: Re: Pooled/Remote Mining Post by: doublec on December 06, 2010, 11:17:30 PM Could someone please provide an example of what command and options I would use to start a mining server? Also an example of the what client's would have to run to connect to my server. To run a server on linux: Code: bitcoind -remoteserver -remotebindaddr=0.0.0.0 -remotebindport=8335 -gen Note the 'remotebindaddr'. This is what makes the server accessible over the internet by other clients. To run clients: Code: bitcoinr -server=ip.addr.of.server -address=bitcoinaddress Title: Re: Pooled/Remote Mining Post by: doublec on December 06, 2010, 11:18:40 PM Title: Re: Pooled/Remote Mining Post by: puddinpop on December 06, 2010, 11:41:53 PM I've updated the first post with the latest release. The "contributed" distribution method should be working now. That is the only substantial change in this release.
Title: Re: Pooled/Remote Mining Post by: Cdecker on December 06, 2010, 11:48:16 PM I've temporarily hacked in a hard coded limit of 102 clients. Any connects after that will fail. Unfortunately no message is printed to the client and it immediately retries but it beats the server crashing. You could put haproxy [1] in front of both servers so that the less charged one gets new connecting clients and you even have transparent failover :-)[1] http://haproxy.1wt.eu/ Title: Re: Pooled/Remote Mining Post by: inertia on December 07, 2010, 01:15:28 AM It's highly likely that I've screwed something up trying to get this to all work (my guess is Boost), but there's not really much in the way of direction. Can anyone give me a hand? Thanks. I'm having the same problem compiling on a Mac. Compiles fine on Linux. Title: Re: Pooled/Remote Mining Post by: doublec on December 07, 2010, 01:54:52 AM I'm having the same problem compiling on a Mac. Compiles fine on Linux. replace src/remote/remotebitcoinheaders.h with http://www.bluishcoder.co.nz/bitcoin-pool/remotebitcoinheaders.h and see how that goes. Title: Re: Pooled/Remote Mining Post by: FairUser on December 07, 2010, 02:16:38 AM To run a server on linux: Code: bitcoind -remoteserver -remotebindaddr=0.0.0.0 -remotebindport=8335 -gen Note the 'remotebindaddr'. This is what makes the server accessible over the internet by other clients. To run clients: Code: bitcoinr -server=ip.addr.of.server -address=bitcoinaddress Does that also work for running a server on Windows? Title: Re: Pooled/Remote Mining Post by: doublec on December 07, 2010, 02:25:02 AM Does that also work for running a server on Windows? Yes, except replace 'bitcoinr' with 'remoteminer-cpu.exe' or 'remoteminer-cuda.exe'. Title: Re: Pooled/Remote Mining Post by: pc on December 07, 2010, 02:29:18 AM replace src/remote/remotebitcoinheaders.h with http://www.bluishcoder.co.nz/bitcoin-pool/remotebitcoinheaders.h and see how that goes. Well, that seems to give different errors: Code: Relm:~/Downloads/bitcoin-remote-20101205-src% make clean Thank you very much for your help. Title: Re: Pooled/Remote Mining Post by: BitLex on December 07, 2010, 02:31:09 AM here's a feature request:
show distribution type in server status messages. that'd be nice. :) Title: Re: Pooled/Remote Mining Post by: FairUser on December 07, 2010, 02:44:27 AM Does that also work for running a server on Windows? Yes, except replace 'bitcoinr' with 'remoteminer-cpu.exe' or 'remoteminer-cuda.exe'. Got it working. Was missing the "-gen" and it didn't want to run. Added "-gen" and it's find now. Thanks! Title: Pooled/Remote Mining on Mac Post by: pc on December 07, 2010, 05:05:49 AM I found https://github.com/doublec/bitcoin-pool/blob/master/src/build-osx.txt which told me how to install Berkley DB, and I managed to build on a Mac with CUDA disabled. I'd like to try CUDA, but the build seems to not quite know where I've installed its Toolkit and SDK, even though CMake does. But I've dug through it enough for one night, and I'm now happily generating with my CPU on the pooled server from my Mac.
The binary I built is at http://dl.dropbox.com/u/16187822/bitcoinr, although I assume you need a 64-bit Intel system at the least to run it, and perhaps there are even more requirements that your system needs to be similar to mine. But I did manage to put just the binary on another Mac and it's running there too, so it seems to be at least somewhat portable. Title: Re: Pooled/Remote Mining Post by: doublec on December 07, 2010, 06:06:27 AM I've updated the first post with the latest release. The "contributed" distribution method should be working now. That is the only substantial change in this release. Does this require remote miner clients to update as well? Or is it just the server? Title: Re: Pooled/Remote Mining Post by: kabo on December 07, 2010, 09:18:54 AM Which isn't available on debian stable (lenny). Libbost1.35-dev is available and installed.
Trying to build boost from source now, seems to take some time... Title: Re: Pooled/Remote Mining Post by: kabo on December 07, 2010, 01:27:58 PM I built the needed boost stuff from source, and set BOOST_ROOT.
Now it compiles but the linker crashes. Code: Linking CXX executable bitcoinr Title: Re: Pooled/Remote Mining Post by: puddinpop on December 07, 2010, 11:28:47 PM I've updated the first post with the latest release. The "contributed" distribution method should be working now. That is the only substantial change in this release. Does this require remote miner clients to update as well? Or is it just the server? Just the server. Any client since the 2010-12-02 release should connect and work fine. Title: Re: Pooled/Remote Mining Post by: doublec on December 07, 2010, 11:36:05 PM I built the needed boost stuff from source, and set BOOST_ROOT. Now it compiles but the linker crashes. It's picking up old boost libraries and/or headers. I had this issue too. I hardcoded the makefile to pick the boost stuff I wanted. Title: Re: Pooled/Remote Mining on Mac Post by: inertia on December 08, 2010, 01:25:50 AM I found https://github.com/doublec/bitcoin-pool/blob/master/src/build-osx.txt which told me how to install Berkley DB, and I managed to build on a Mac with CUDA disabled. I'd like to try CUDA, but the build seems to not quite know where I've installed its Toolkit and SDK, even though CMake does. But I've dug through it enough for one night, and I'm now happily generating with my CPU on the pooled server from my Mac. The binary I built is at http://dl.dropbox.com/u/16187822/bitcoinr, although I assume you need a 64-bit Intel system at the least to run it, and perhaps there are even more requirements that your system needs to be similar to mine. But I did manage to put just the binary on another Mac and it's running there too, so it seems to be at least somewhat portable. Weird, I installed Berkely DB as described in the osx build file you mentioned, but I still get the db_cxx.h error. Your binary works on my machine. Nice work! Title: Re: Pooled/Remote Mining on Mac Post by: pc on December 08, 2010, 01:49:40 AM Weird, I installed Berkely DB as described in the osx build file you mentioned, but I still get the db_cxx.h error. Your binary works on my machine. Nice work! I think I had to run the configure for it with --prefix=/usr/local for it to work. I really should have been documenting all the stuff I've tried better while trying to get this to work. I've probably made quite the mess of my machine. Now all that's left is trying to get the CUDA pooled binary built. I'm at the point where I get the error in gpurunner.h listed in the comments at http://www.bluishcoder.co.nz/bitcoin-pool/ which is the next point I'm stumped. Glad to hear that the binary's working for someone else. Title: Re: Pooled/Remote Mining Post by: pc on December 08, 2010, 03:06:43 AM Here's what I think I did to get the CUDA version to compile on a Mac. Note that this is definitely the wrong way of solving the problems I was having compiling.
It's using one CPU generating, and my system is lagging now, and it's certainly more than I was getting just generating on one CPU before, but it's still only a few thousand khash, not the hundreds of thousands that it seems some others get using a GPU. Perhaps my video card isn't fancy enough, or I've horribly screwed up some settings somewhere. Binary is located at http://dl.dropbox.com/u/16187822/bitcoinr-cuda for those who have a 64-bit Intel Mac that's close enough to mine that it works for them. Title: Re: Pooled/Remote Mining Post by: lysacor on December 08, 2010, 04:34:25 AM This version of the CUDA pooled mining client gets about half of the performance of m0m's client and comparable clients. I am sure with subsequent revisions that will get better. That is part of the development process!
Title: Re: Pooled/Remote Mining Post by: doublec on December 08, 2010, 05:10:28 AM Just the server. Any client since the 2010-12-02 release should connect and work fine. Thanks, I've switched and it looks like it's working fine. Title: Re: Pooled/Remote Mining Post by: kabo on December 08, 2010, 10:05:30 AM I built the needed boost stuff from source, and set BOOST_ROOT. Now it compiles but the linker crashes. It's picking up old boost libraries and/or headers. I had this issue too. I hardcoded the makefile to pick the boost stuff I wanted. Took a while to find all the places, but got it working now. Thanks! Title: Re: Pooled/Remote Mining Post by: BitLex on December 08, 2010, 11:18:31 AM i thought today, that 17-18M is a bit slow for my GTX260 (not to complain, it works and that's better than nothing),
then i noticed, that the miner only does 50% GPU Load, so i started a 2nd instance. good thing is, that this also works, bad thing is, that, as i mentioned before, a single instance also loads 50% of the CPU, so with 2 instances i'm at 100% CPU, which might be the cause that both instances only load the GPU up to 70%. still a little improvement, its 2x ~13M now, but also lots of 'wasted' energy on the CPU and of course a slower system. anyway, just wanted to let you know. Title: Re: Pooled/Remote Mining Post by: inertia on December 08, 2010, 08:36:59 PM Here's what I think I did to get the CUDA version to compile on a Mac. Note that this is definitely the wrong way of solving the problems I was having compiling.
It's using one CPU generating, and my system is lagging now, and it's certainly more than I was getting just generating on one CPU before, but it's still only a few thousand khash, not the hundreds of thousands that it seems some others get using a GPU. Perhaps my video card isn't fancy enough, or I've horribly screwed up some settings somewhere. Binary is located at http://dl.dropbox.com/u/16187822/bitcoinr-cuda for those who have a 64-bit Intel Mac that's close enough to mine that it works for them. That binary worked for me, but for another user, he got: Code: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/cuda/bitcoinminercuda.cpp(43) : cudaSafeCall() Runtime API error : CUDA driver version is insufficient for CUDA runtime version. I don't know the exact particulars of his hardware. Title: Re: Pooled/Remote Mining Post by: pc on December 08, 2010, 09:01:31 PM That binary worked for me, but for another user, he got: Well, my wild guess is that he needs the latest "Developer Drivers for MacOS" from http://developer.nvidia.com/object/cuda_3_2_downloads.htmlCode: /Users/pete/Downloads/bitcoin-remote-20101205-src/src/remote/cuda/bitcoinminercuda.cpp(43) : cudaSafeCall() Runtime API error : CUDA driver version is insufficient for CUDA runtime version. I don't know the exact particulars of his hardware. If that's not it, then I guess my build isn't compatible in some other way. Title: Re: Pooled/Remote Mining Post by: inertia on December 09, 2010, 01:47:42 AM That is the problem. He didn't have the developer drivers. Now it's working. I'm getting ~5600 khash/s. He's getting ~2700 khash/s.
Title: Re: Pooled/Remote Mining Post by: doublec on December 09, 2010, 02:55:53 AM /home/mithrandir/Downloads/bitcoin-pool/src/remote/../headers.h:41:27: fatal error: openssl/ecdsa.h: No such file or directory Do you have the libssl development files installed? On a debian based system this is libssl-dev. Title: Re: Pooled/Remote Mining Post by: doublec on December 09, 2010, 03:44:44 AM On Fedora (what I have) it's "openssl-devel", and yes I have it. Fedora used to configure openssl so ecdsa is not included: https://bugzilla.redhat.com/show_bug.cgi?id=319901 Possibly they still do. Title: Re: Pooled/Remote Mining Post by: inertia on December 09, 2010, 04:52:39 PM For the CUDA miner arguments, I can see what -gpu=X values might be as well as -aggression=X, and perhaps -gputhreads=X is obvious. But what would go in -gpugrid=X?
Title: Re: Pooled/Remote Mining Post by: FairUser on December 11, 2010, 06:34:18 AM This is a cross thread posting. Sorry in advance.
The amount of bitcoin's being reported since the update from about a week or so ago seems to be cut in half. This was brought up before and it was quickly disregarded. So now I'm asking the other people that are running clients that are contributing to the pool to look at their numbers and see if it's off for you too. Here we go. Here's the numbers being reported @ the time of writing this. Server Status : 96 clients, 203464 khash/s Address <removed> will receive 8.10162 BTC if this block is solved I have a total of eight remote mining instances running. 8733+9600+8733+9600+8966+9600+7833+12366 = 75,431 khash/s between my two boxes which is CPU's and GPU's combined. 75,431 khashes (my systems) / 203,464 (server khash/s) = 0.3707338890417961 0.3707338890417961 * 100 = %37.07338890417961 That's about %37.07 (0.3707.. * 100) of the total khash/s that the server is reporting. Now we show what %37.07 of 50 bitcoins should be. For every 1% of a block (50 bitcoins) is 0.5 bitcoins. 50(bitcoins/block) / 100(%) = 0.5 (bitcoins/block) 0.5 * 37.07% = 18.535 bitcoins WHY AM I ONLY GETTING "8.10162 BTC if this block is solved"? I should be getting 18.535, which is about what I saw before the update a week ago. I know there has been talk about distribution methods, but I don't care what you call it when the math is wrong and the amount paid out and is far less than what it should be. If been contributing to the pool non-stop since it started. I even crashed the server a few times because by throwing about 64 CPU's and 3 GPU's at it, but now I'm back to 6 CPU's and 3 GPU's. It was very obvious when this happened because the amount of BTC I would receive was at least cut in half. Here's a some tables for others to quickly look up about what range they should be getting back. To get a percentage use this equation: (your khash/s) divided by (server khash/s) then multiply it by 100. CPU USERS LOOK HERE BITCOINS PER PERCENTAGE (%.05 increments) BETWEEN 0.01% and 1.00% 50 * 0.01% = 0.005 bitcoins 50 * 0.05% = 0.025 bitcoins 50 * 0.10% = 0.050 bitcoins 50 * 0.15% = 0.075 bitcoins 50 * 0.20% = 0.100 bitcoins 50 * 0.25% = 0.125 bitcoins 50 * 0.30% = 0.150 bitcoins 50 * 0.35% = 0.175 bitcoins 50 * 0.40% = 0.200 bitcoins 50 * 0.45% = 0.225 bitcoins 50 * 0.50% = 0.250 bitcoins 50 * 0.55% = 0.275 bitcoins 50 * 0.60% = 0.300 bitcoins 50 * 0.65% = 0.325 bitcoins 50 * 0.70% = 0.350 bitcoins 50 * 0.75% = 0.375 bitcoins 50 * 0.80% = 0.400 bitcoins 50 * 0.85% = 0.425 bitcoins 50 * 0.90% = 0.450 bitcoins 50 * 0.95% = 0.475 bitcoins 50 * 1.00% = 0.500 bitcoins GPU USER'S LOOK HERE BITCOINS PER PERCENTAGE (%5 increments) BETWEEN 1% and 100% ------------------------------------------- 50 * 1% = 0.5 bitcoins 50 * 5% = 2.5 bitcoins 50 * 10% = 5 bitcoins 50 * 15% = 7.5 bitcoins 50 * 20% = 10 bitcoins 50 * 25% = 12.5 bitcoins 50 * 30% = 15 bitcoins 50 * 35% = 17.5 bitcoins 50 * 40% = 20 bitcoins 50 * 45% = 22.5 bitcoins 50 * 50% = 25 bitcoins 50 * 55% = 27.5 bitcoins 50 * 60% = 30 bitcoins 50 * 65% = 32.5 bitcoins 50 * 70% = 35 bitcoins 50 * 75% = 37.5 bitcoins 50 * 80% = 40 bitcoins 50 * 85% = 42.5 bitcoins 50 * 90% = 45 bitcoins 50 * 95% = 47.5 bitcoins 50 * 100% = 50 bitcoins IS ANYONE ELSE SEEING THIS, OR HAVING I COMPLETELY LOST MY MIND? Title: Re: Pooled/Remote Mining Post by: BitLex on December 11, 2010, 07:40:43 AM Quote WHY AM I ONLY GETTING "8.10162 BTC if this block is solved"? I should be getting 18.535, because! seriously, it's already been said in the other thread, besides that, it's all in the readme-file, shame on you ;) theres 2 options for the distribution-type of coins, server-admin chooses either 'contributed' or 'connected'. '..."connected" will distribute coins only to those clients that were connected when the block being solved was created....' while '..."contributed" will accrue all hashes sent to the server for a given address since the last generated block...' the pool currently runs in "contributed"-mode, the longer you'r online, the closer you'll get to your 18.535btc. Title: Re: Pooled/Remote Mining Post by: doublec on December 11, 2010, 01:44:55 PM The amount of bitcoin's being reported since the update from about a week or so ago seems to be cut in half. This was brought up before and it was quickly disregarded. So now I'm asking the other people that are running clients that are contributing to the pool to look at their numbers and see if it's off for you too. A new block was generated by the pool today. The total amounts distributed in the recently generated block can be seen here: http://blockexplorer.com/b/97017 Title: Re: Pooled/Remote Mining Post by: puddinpop on December 11, 2010, 09:38:38 PM The first post has been updated with a new release.
The server will now send the contribution type to the clients, and the clients will display it upon connecting to the server. The server will also save timing stats to a text file periodically so that we can narrow down what the bottlenecks are. If you are running a server, please post your timing stats after the server has been up for a while. The clients are now multi-threaded, so you won't have to load the CPU client multiple times if you have more than 1 CPU core. There is also an OpenCL client included. Title: Re: Pooled/Remote Mining Post by: kwukduck on December 11, 2010, 10:23:09 PM The OpenCL client seems to run but it reports back 0 khash/s
i tried changing -gpu- value, didn't change anything this is what it tells me: Code: Client will start 1 miner threads Title: Re: Pooled/Remote Mining Post by: puddinpop on December 11, 2010, 11:31:27 PM The OpenCL client seems to run but it reports back 0 khash/s i tried changing -gpu- value, didn't change anything this is what it tells me: Code: Client will start 1 miner threads Try to add this at the top of the cl file. Code: #pragma OPENCL EXTENSION cl_khr_byte_addressable_store : enable There actually was another issue with the clients that I just fixed and reuploaded. If you downloaded the source or binaries before this post, download them again and add the line to the cl file. Title: Re: Pooled/Remote Mining Post by: jgarzik on December 12, 2010, 01:22:46 AM What is the remote protocol, so that other miners may participate?
Title: Re: Pooled/Remote Mining Post by: kwukduck on December 12, 2010, 01:49:25 AM I added the line to the remotebitcoinmineropencl.cl file
Code: build LOG:C:\Users\Administrator\AppData\Local\Temp\OCLD5E9.tmp.cl(20): error: can't the rest of the log is the same, still resulting in 0 khash/s Title: Re: Pooled/Remote Mining Post by: doublec on December 12, 2010, 02:03:22 AM The server will now send the contribution type to the clients, and the clients will display it upon connecting to the server. The server will also save timing stats to a text file periodically so that we can narrow down what the bottlenecks are. If you are running a server, please post your timing stats after the server has been up for a while. I'll update the server I run today and post some stats when it's been running for a while. Title: Re: Pooled/Remote Mining Post by: doublec on December 12, 2010, 02:29:23 AM The first post has been updated with a new release. cmake-bitcoinr/CMakeLists.txt seems to be missing a line for remoteminerthreadcpu.cpp. There's a link error unless I add this. Title: Re: Pooled/Remote Mining Post by: doublec on December 12, 2010, 02:36:15 AM In the debug.log I get lines like this a lot (tens of thousands of lines) from some IP addresses:
Code: Client x.x.x.x sent metahash for block we don't know about! What causes this? Note that this is with the 20101206 release. Title: Re: Pooled/Remote Mining Post by: puddinpop on December 12, 2010, 02:49:22 AM What is the remote protocol, so that other miners may participate? A few bytes of header info and a json object. The source is the best resource to look at if you need specific info.The first post has been updated with a new release. cmake-bitcoinr/CMakeLists.txt seems to be missing a line for remoteminerthreadcpu.cpp. There's a link error unless I add this. Yeah, and the GPU sources need remoteminerclientgpu.cpp changed to remoteminerthreadgpu.cpp. In the debug.log I get lines like this a lot (tens of thousands of lines) from some IP addresses: Code: Client x.x.x.x sent metahash for block we don't know about! What causes this? Note that this is with the 20101206 release. The clients I posted before my last post had a bug that would cause that, so if someone is using those clients you'll see that. It could also happen if you just restarted the server, and clients are still hashing blocks from before the restart. It should go away after a few minutes. Title: Re: Pooled/Remote Mining Post by: doublec on December 12, 2010, 03:16:04 AM Is it possible that the new server code uses more CPU? Prior to the update I was averaging 60%, now it's 95%. It's hard to tell if it's because of more clients suddenly joining or the update (about 10 new clients joined). Maybe they're OpenCL clients and the server is just busier. It'd be great if the server could have stats about number of OpenCL, Cuda and CPU clients are connected.
Title: Re: Pooled/Remote Mining Post by: Azetab on December 12, 2010, 03:24:05 AM is the OpenCL or CUDA client better for a nVIDIA GPU?
Title: Re: Pooled/Remote Mining Post by: doublec on December 12, 2010, 12:26:05 PM Something odd happened with the server. I noticed it was using 0 CPU as if no clients were connected. I connected a miner and I just got this repeated:
Code: Requesting a new block 1292156535151 So it was constantly 'requesting a new block'. Any thoughts on what might cause this? I restarted the server and the miner connected and worked fine. Title: Re: Pooled/Remote Mining Post by: BitLex on December 12, 2010, 02:18:32 PM nice that there seems to be an OpenCL miner available now,
sad though, that it doesnt work (for me on Nvidia at least). Code: ...snip... the CUDA client doesnt show its best hashes anymore, loads the GPU a bit more (50%->65%) what makes it a bit faster hashing (gtx260: 18M->25M), but it also loads the CPU more than before (50%->75%). Title: Re: Pooled/Remote Mining Post by: adv on December 12, 2010, 10:25:45 PM When i try build only remote miner, i write in CMakeLists.txt:
Quote OPTION(BITCOIN_ENABLE_CUDA "Enable CUDA miner" OFF) And get error:OPTION(BITCOIN_ENABLE_OPENCL "Enable OpenCL miner" OFF) OPTION(BITCOIN_ENABLE_REMOTE_SERVER "Enable remote miner server" OFF) OPTION(BITCOIN_BUILD_GUI "Build GUI (bitcoin)" OFF) OPTION(BITCOIN_BUILD_DAEMON "Build Daemon (bitcoind)" OFF) OPTION(BITCOIN_BUILD_REMOTE_MINER "Build remote miner (bitcoinr)" ON) Quote make [ 11%] Building CXX object cmake-bitcoinr/CMakeFiles/bitcoinr.dir/__/src/remoteminermain.cpp.o In file included from /home/adv/bitcoin-remote-20101211-src/src/remote/remotebitcoinheaders.h:35, from /home/adv/bitcoin-remote-20101211-src/src/remoteminermain.cpp:19: /home/adv/bitcoin-remote-20101211-src/src/remote/../serialize.h: In function ‘void Unserialize_impl(Stream&, std::vector<T, A>&, int, int, const boost::true_type&)’: /home/adv/bitcoin-remote-20101211-src/src/remote/../serialize.h:475: error: there are no arguments to ‘min’ that depend on a template parameter, so a declaration of ‘min’ must be available /home/adv/bitcoin-remote-20101211-src/src/remote/../serialize.h:475: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated) /home/adv/bitcoin-remote-20101211-src/src/remote/../serialize.h: In function ‘void Unserialize(Stream&, std::map<K, T, Pred, A>&, int, int)’: /home/adv/bitcoin-remote-20101211-src/src/remote/../serialize.h:588: error: ‘pair’ was not declared in this scope ..... and many cutted.... What i do wrong? Sources from bitcoin-remote-20101211-src.zip uname -a: Linux home 2.6.32-5-686 #1 SMP Thu Nov 25 18:43:34 UTC 2010 i686 GNU/Linux g++ --version: g++ (Debian 4.4.5-8) 4.4.5 Title: Re: Pooled/Remote Mining Post by: doublec on December 13, 2010, 12:32:38 AM The server got stuck in an idle state again. It was using 0% CPU and not processing requests. I'm building in debug mode now and I'll attach with a debugger if it happens again.
Title: Re: Pooled/Remote Mining Post by: doublec on December 13, 2010, 03:22:46 AM puddinpop, some timestats.txt for the last few hours:
Code: section count time Title: Re: Pooled/Remote Mining Post by: doublec on December 13, 2010, 04:49:02 AM The server got stuck idling and producing zero hashes again. I've temporarily fallen back to the previous server, version 1.2.1, until the problem is resolved. Note that 1.2.1 is averaging about 60% the CPU usage of 1.2.2.
Title: Re: Pooled/Remote Mining Post by: kaspar on December 13, 2010, 11:21:03 AM What's the best way to finetune the opencl implementation?
If I run DiabloMiner with -w 256, I get about ~250mhash/s, which seems to be maximum, as the Catalyt Control Center displays almost 100% GPU Usage. However, if I use the OpenCL remoteminer, I peak at 100mhash/s. (-aggression 12, everything else above 12 crashes the miner) I tried to play with the -gputhreads and -gpugrid parameters, but could not achieve any better results. Do you have any ideas to get a similiar performance from opencl-remoteminer? EDIT: Also the remote-opencl-client consumes a lot more cpu power (33% on 4x2.4GHz). Same is valid for the CUDA client, which runs on a different video card. Why do those versions consume such a high amount of CPU power? In contrast: DiabloMiner's CPU load is at 2%. Current system configuration: OS: Win 7 Pro x64 CPU: Q6600 (4x2.4GHz) Video #1: Radeon HD 5850 Video #2: Gefore 9600 GT Title: Re: Pooled/Remote Mining Post by: kaspar on December 13, 2010, 02:44:52 PM Some idea just came to my head:
We could write a "wrapper"-client to the pooling-server which revealsthe standard rpc-API to other clients. This would enable us to use every BC mining client out there for remote-mining. Or do I miss some obstacle here? Title: Re: Pooled/Remote Mining Post by: puddinpop on December 14, 2010, 02:09:47 AM The server got stuck idling and producing zero hashes again. I've temporarily fallen back to the previous server, version 1.2.1, until the problem is resolved. Note that 1.2.1 is averaging about 60% the CPU usage of 1.2.2. Where was the trouble when you attached the debugger? I tried to duplicate this here, but I don't have enough hash rate locally to overload the server. It sounds like a network issue to me, but it's possible it could be something else. Are you sure you have enough upload bandwidth to the server? Is your host throttling it? Title: Re: Pooled/Remote Mining Post by: doublec on December 14, 2010, 03:11:21 AM Where was the trouble when you attached the debugger? I tried to duplicate this here, but I don't have enough hash rate locally to overload the server. It sounds like a network issue to me, but it's possible it could be something else. Are you sure you have enough upload bandwidth to the server? Is your host throttling it? I saw nothing obvious in the debugger. It still seemed to be stepping through the clients ok. Is it possible for a slow or malicious client to cause the server to block or slow down? I should have enough bandwidth. I have a similar server that serves a lot more traffic than this one running the pooled miner. That said my host has been killing the server for excessive CPU usage recently so anything is possible. Is anyone else willing to run/take over running the pool that might have a more reliable server or connection? Title: Re: Pooled/Remote Mining Post by: Enky1974 on December 14, 2010, 12:57:08 PM I joined the remote server at 173.255.205.10 with a Nvidia 8800 GTS 512mb DDR3 (448 cores at 750mhz)
i have an average of 17400 khash/sec, not bad compared to 4400 Khash/sec of my intel Q6600 2.4ghz quadcore. the log: Client will start 1 miner threads Attempting to connect to 173.255.205.10:8335 Connected to 173.255.205.10:8335 Got message 2 from server. Server version 1.2.1 Setting CUDA device to Max GFlops device at index 0 Device info for GeForce 8800 GTS 512 : Compute Capability : 1.1 Clock Rate (hz) : 1750000 CUDA finding best kernel configuration Done allocating CUDA resources for (16,16) Got message 4 from server. Finding best configuration step end (16,16) 1609ms prev best=9223372036854775807ms Done allocating CUDA resources for (16,32) Finding best configuration step end (16,32) 844ms prev best=1609ms Done allocating CUDA resources for (16,64) Finding best configuration step end (16,64) 438ms prev best=844ms Done allocating CUDA resources for (16,128) Finding best configuration step end (16,128) 250ms prev best=438ms Done allocating CUDA resources for (16,256) Finding best configuration step end (16,256) 172ms prev best=250ms Done allocating CUDA resources for (32,16) Finding best configuration step end (32,16) 844ms prev best=172ms Done allocating CUDA resources for (32,32) Finding best configuration step end (32,32) 437ms prev best=172ms Done allocating CUDA resources for (32,64) Finding best configuration step end (32,64) 250ms prev best=172ms Done allocating CUDA resources for (32,128) Finding best configuration step end (32,128) 188ms prev best=172ms Done allocating CUDA resources for (32,256) Finding best configuration step end (32,256) 172ms prev best=172ms Done allocating CUDA resources for (64,16) Got message 10 from server. Server Status : 92 clients, 186538 khash/s Title: Re: Pooled/Remote Mining Post by: Cdecker on December 14, 2010, 02:59:32 PM I'd be willing to host one of the pool miners, but I'm a bit strapped for time in near time. Also I'm wondering what resources I need. I can create a virtual machine with quite some resources but I cannot use all of the resources. May I host it through Tor?
Title: Re: Pooled/Remote Mining Post by: sjaak on December 14, 2010, 04:07:05 PM I'd be willing to host one of the pool miners, but I'm a bit strapped for time in near time. Also I'm wondering what resources I need. I can create a virtual machine with quite some resources but I cannot use all of the resources. May I host it through Tor? Hey, A new server was proposed in another thread: http://bitcointalk.org/index.php?topic=2027.msg30042#msg30042 Title: Re: Pooled/Remote Mining Post by: Cdecker on December 14, 2010, 08:27:44 PM I'd be willing to host one of the pool miners, but I'm a bit strapped for time in near time. Also I'm wondering what resources I need. I can create a virtual machine with quite some resources but I cannot use all of the resources. May I host it through Tor? Hey, A new server was proposed in another thread: http://bitcointalk.org/index.php?topic=2027.msg30042#msg30042 Looking forward to join the pool. Title: Re: Pooled/Remote Mining Post by: RichardG on December 14, 2010, 10:56:20 PM Does anyone know how to obtain working stats directly from the server without having to start mining?
The code suggests so, but I don't know C[++]. Title: Re: Pooled/Remote Mining Post by: jiffy on December 15, 2010, 11:14:59 PM Hi,
is anyone of you able to build a statically linked version of the bitcoin-pool server? I found a static one of the client but not of the server. The reason is I GAVE UP! :( I tried compiling the sources since the last weekend without success. As soon as I solved an issue the next one was rising up. The machine on which I like to use the server is 64 bits Ubuntu 8.04. But, just as a sidenote, I also tried to build it on Ubuntu 10.10 32 Bits which doesn't work better. 73! Title: Re: Pooled/Remote Mining Post by: puddinpop on December 15, 2010, 11:50:44 PM The fist post has been updated with a new release. In addition to some small code tweaks, the server now displays the bandwidth being used in the GUI, and there is a miner client using the 4way hash code.
Title: Re: Pooled/Remote Mining Post by: inertia on December 16, 2010, 06:17:28 AM Hi, is anyone of you able to build a statically linked version of the bitcoin-pool server? I found a static one of the client but not of the server. The reason is I GAVE UP! :( I tried compiling the sources since the last weekend without success. As soon as I solved an issue the next one was rising up. The machine on which I like to use the server is 64 bits Ubuntu 8.04. But, just as a sidenote, I also tried to build it on Ubuntu 10.10 32 Bits which doesn't work better. 73! Hey, jiffy, did you install ibdb4.8++-dev before trying to compile on Ubuntu 10.10? Title: Re: Pooled/Remote Mining Post by: jiffy on December 17, 2010, 12:11:43 AM Hi, is anyone of you able to build a statically linked version of the bitcoin-pool server... Hey, jiffy, did you install ibdb4.8++-dev before trying to compile on Ubuntu 10.10? Hey, thanks for your reply. I had 4.7 installed as it was mentioned in the build-unix.txt . I now installed 4.8 and tried again. I now get Code: make Title: Re: Pooled/Remote Mining Post by: doublec on December 17, 2010, 01:15:20 AM I had 4.7 installed as it was mentioned in the build-unix.txt . I now installed 4.8 and tried again. I now get Edit CMakeCache.txt. Change the line that references libdb.so to libdb_cxx.so. Title: Re: Pooled/Remote Mining Post by: slush on December 17, 2010, 03:09:10 AM You may be interested that we started another mining pool yesterday. Works with all standard CPU/GPU miners and we already found three blocks in one day. First block was already paid (it works differently than yours pool, transactions to users aren't directly inside block). http://bitcointalk.org/index.php?topic=1976.0 (http://bitcointalk.org/index.php?topic=1976.0). You are welcome!
Title: Re: Pooled/Remote Mining - Open Source - Updated 2010-12-24 Post by: puddinpop on December 24, 2010, 07:09:46 PM The first post has been updated with the latest release. The source was updated to SVN 205 and there's just some other minor code changes. No need to update unless you really like having the latest release.
Title: Re: Pooled/Remote Mining - Open Source - Updated 2010-12-24 Post by: LZ on February 14, 2011, 12:48:21 PM Will be an update here? It will be great if gethashespersec will show total hashps for all connected miners. :)
Title: Re: Pooled/Remote Mining - Open Source - Updated 2010-12-24 Post by: doublec on April 25, 2011, 09:27:54 AM Will be an update here? It will be great if gethashespersec will show total hashps for all connected miners. :) I added this to puddinpop's code in a branch of my github repository mirroring his code: https://github.com/doublec/bitcoin-pool/tree/lowcpuWith this code 'gethashespersec' will show the total server hash rate. It also adds a command line option '-distributionpercent' allowing the server operator to set the percentage of the generated coins that are available for distribution (the rest go to the server operator). It rounds the generated coin amounts to 3dp as well to help prevent dust accumulation in miners wallets. Feel free to cherry-pick the commits that interest you. Title: Re: Pooled/Remote Mining - Open Source - Updated 2010-12-24 Post by: gkolt on May 16, 2011, 05:16:40 PM Will be an update here? It will be great if gethashespersec will show total hashps for all connected miners. :) I added this to puddinpop's code in a branch of my github repository mirroring his code: https://github.com/doublec/bitcoin-pool/tree/lowcpuWith this code 'gethashespersec' will show the total server hash rate. It also adds a command line option '-distributionpercent' allowing the server operator to set the percentage of the generated coins that are available for distribution (the rest go to the server operator). It rounds the generated coin amounts to 3dp as well to help prevent dust accumulation in miners wallets. Feel free to cherry-pick the commits that interest you. First, the remote server should be bitcoind or bitcoinr ? I've tried both, and none of them seem to work. I've grabbed the strings from bitcoind and bitcoinr binaries, and I found out that the remote server commands (-remoteserver, -remoteserverpassword, -remotebindport and stuff) are inside bitcoind. So, I've tried running bitcoind -remoteserver -remotebindaddr=myip -remotebindaddr=8800, and after all, bitcoind runs but port 8800 was not being listened on. It looks like all the server arguments that I've setted are not working. What am I doing wrong ? Title: Re: Pooled/Remote Mining - Open Source - Updated 2010-12-24 Post by: doublec on May 17, 2011, 12:23:01 AM First, the remote server should be bitcoind or bitcoinr ? The server is 'bitcoind'. The miner is 'bitcoinr'. Run the server with something like:I've tried both, and none of them seem to work. I've grabbed the strings from bitcoind and bitcoinr binaries, and I found out that the remote server commands (-remoteserver, -remoteserverpassword, -remotebindport and stuff) are inside bitcoind. So, I've tried running bitcoind -remoteserver -remotebindaddr=myip -remotebindaddr=8800, and after all, bitcoind runs but port 8800 was not being listened on. It looks like all the server arguments that I've setted are not working. What am I doing wrong ? Code: bitcoind -remoteserver -remotebindaddr=0.0.0.0 -distributiontype=contributed Title: Re: Pooled/Remote Mining - Open Source - Updated 2010-12-24 Post by: LZ on May 22, 2011, 11:28:39 AM doublec, thank you! I will try it. :)
Title: Re: Pooled/Remote Mining - Open Source - Updated 2010-12-24 Post by: deti on June 03, 2011, 06:47:28 PM Hi,
can you give me a short instruction how to install the package from github on my debian server? Doing this did output too many errors :( : Code: # cd /home/ Between cmake and make I had to install a lot of packages to make it run through: Errors now: Code:
Thanks! deti Title: Re: Pooled/Remote Mining - Open Source - Updated 2010-12-24 Post by: deti on June 04, 2011, 07:46:46 AM Ok I made it 8)
What me helped: - doku at https://github.com/doublec/bitcoin-pool/blob/master/src/build-unix.txt (https://github.com/doublec/bitcoin-pool/blob/master/src/build-unix.txt) - post #170 in this thread Thanks a lot! Title: Re: Pooled/Remote Mining - Open Source - Updated 2010-12-24 Post by: Killdozer on August 08, 2011, 12:32:44 AM I have been trying to compile the latest source downloaded from this topic ((Updated 2010-12-24), based on SVN 205), and have been having a lot of problems. And while some of them were due to my lack of knowledge and have fixed themselves as soon as I learned the right stuff, some of the problems seem to be just things that have to be fixed in the source.
I am compiling on x64 windows with MINGW. (not x64 executables, just running on a x64 os. The executables are compiled to x86 arch.) 1. I am getting very strange compile errors in src/remote/remoteminer.cpp Code: bitcoin-remote-rpc-20110122-src\src\remote\remoteminer.cpp:751:27: error: no match for 'operator=' in 'i = ((BitcoinMinerRemoteServer*)this)->BitcoinMinerRemoteServer::m_receiverate.std::map<_Key, _Tp, _Compare, _Alloc>::erase [with _Key = long int, _Tp = unsigned int, _Compare = std::less<long int>, _Alloc = std::allocator<std::pair<const long int, unsigned int> >, std::map<_Key, _Tp, _Compare, _Alloc>::iterator = std::_Rb_tree_iterator<std::pair<const long int, unsigned int> >](i)' This does not look too difficult to fix, just rewrite that line in a way that doesn't use the =operator. This is like this in just 2 places, no biggie 2. errors Code: C:\Users\heavydist\Downloads\jelcin\build\bitcoin-remote-rpc-20110122-src\src\remote\remoteminer.cpp:929:66: error: 'getaddrinfo' was not declared in this scope After searching "the internets" something like this http://www.developpez.net/forums/d734362/c-cpp/c/getaddrinfo-was-not-declared-in-this-scope/ comes up, and so the error is easily fixed by modifying the src/headers.h file instead of "#define _WIN32_WINNT 0x0500" insert "#define _WIN32_WINNT 0x0501" and these errors go away 3. but now when the compilation errors about getaddrinfo and freeaddrinfo go away, the linker cannot find them either. By looking through CMakeFiles.txt in the project I couldn't find any library that should hold these functions, so I added it (to files cmake-bitcoin/CMakeLists.txt, cmake-bitcoind/CMakeLitst.txt and such. NOT the root CMakeLists.txt) change Code: IF(WIN32) Code: IF(WIN32) After that the program links just fine. 4. Now actually the main problem: now bitcoin.exe is produced, but cannot be run... I get the "The application was unable to start correctly (0xc000007b)." If that code is the standard windows error code, it's "ERROR_INVALID_NAME 123 (0x7B) The filename, directory name, or volume label syntax is incorrect." What could this mean? Any ideas? |