[NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :)

[slush]

it looks like you are trying to make it more efficient to allow more people in.

I'd like to notice that they are doing it more effective for them (for the pool), but using this "hacked" miner is less effective for users. We had long discussion with FairUser and Geebus about this and it looks they still don't understand what they are doing. Pretty bad for pool operators . Their "mining efficiency" is absolutely irrelevant number.

I'm not using "ineffective miners" on my pool because I'm masochist but because it is good for users. By the way, everybody on my pool (or every other current pool) can "optimize" his miner by setting custom ask rate on command line. But I really don't recommend that.

Because I don't like to start long discussion about nothing again, this is both my first and last post in this thread. Thank you for reading.

[1714055652]

1714055652

[1714055652]

1714055652

[1714055652]

1714055652

[elFarto]

-a 5 -t 8 -o host@host.com:#### -u XXXXXXXX -p XXXXXXXXX is how you are supposed to set it up

I'm using it with deepbit's pool (deepbit.net) it also works with btcmine.com's miner

I dug through the source code of Ufasoft's miner.

Basically, most miners (poclbm, diablominer, rpc-miner, jgarzik's cpu miner) work like this:

Client (Request for Getwork w/ Authorization Headers included) --> Server
Server (Respond with Getwork) --> Client
Client (Send Hash from Getwork) --> Server
Server (Respond with Accepted, or Invalid/Stale) --> Client

Ufasoft's Miner works like this:
Client (Request Getwork) --> Server
Server (Prompt for Authorization) --> Client
Client (Respond with Credentials) --> Server
Server (Respond with Getwork) --> Client
Client (Send Hash from Getwork) --> Server
Server (Prompt for Authorization) --> Client
Client (Respond with Credentials) --> Server
Server (Respond with Accepted, or Invalid/Stale) --> Client

Twice as much network traffic, and incompatible with our pool simply because they don't include the credentials in the headers on every request.

Maybe you can email ufasoft about it and see if they can modify the way their miner works.

I'd like to point out my RPC Proxy fixes this issue with Ufasoft's client, as it doesn't use any authorization locally, and always sends authorization to the server.

Regards
elFarto

[xenon481]

Absolutely, this "efficiency" number is how much processing you are saving their server (potentially lowering server costs for the pool operator), not how much better you as a miner are doing.

To be fair, a more efficient pool server means that costs per miner are lower and those savings "can" (and currently are) be passed on from the pool operator to the miners.

The problem is that the way that this pool has implemented their efficiency gains comes at the cost of increased percentages of Stale (unpaid) wasted processing power. And to make it worse, it specifically causes slower miners to incur the worst of this increase of Stales.


I fully applaud and support these operators for having taken the initiative of creating their own pool (competition is awesome), but I will not stand for "spin" to be applied to try and hide the truth from an open community.

That being said, this certainly might be the most effective pool (due to no required fees) for miners with fast hardware.

[nster]

Absolutely, this "efficiency" number is how much processing you are saving their server (potentially lowering server costs for the pool operator), not how much better you as a miner are doing.

To be fair, a more efficient pool server means that costs per miner are lower and those savings "can" (and currently are) be passed on from the pool operator to the miners.

The problem is that the way that this pool has implemented their efficiency gains comes at the cost of increased percentages of Stale (unpaid) wasted processing power. And to make it worse, it specifically causes slower miners to incur the worst of this increase of Stales.


I fully applaud and support these operators for having taken the initiative of creating their own pool (competition is awesome), but I will not stand for "spin" to be applied to try and hide the truth from an open community.

That being said, this certainly might be the most effective pool (due to no required fees) for miners with fast hardware.

How fast is "fast" is 250~300Mh/s enough to get more from this pool?

[nster]

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

[jgarzik]

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

The modified poclbm does not give you better performance -- more hashes per second -- nor does it find more shares than the unmodified.

[Raptorblaze]

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

The average person isn't that creative My efficiency on the stats page is low because i was having trouble getting their miner to work at first. Totally forgot the .exe name was poclbm-mod, not just poclbm in the batch file....*facepalm*  Hope they send me my payments soon, i've been running for almost 13 hours now and haven't seen anything. More information on the payment system would be appreciated.
Edit: Just to clarify, I recall reading something about slush's pool requiring more confirmations for each block than actually necessary. The number for default confirmations (i believe...) was 120? which would put it at ~20 hours per confirmation. So I'm not getting impatient at this point.

[nster]

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

The average person isn't that creative My efficiency on the stats page is low because i was having trouble getting their miner to work at first. Totally forgot the .exe name was poclbm-mod, not just poclbm in the batch file....*facepalm*  Hope they send me my payments soon, i've been running for almost 13 hours now and haven't seen anything. More information on the payment system would be appreciated.

We haven't found a block yet so we don't get paid yet... and the difficulty increased so we have even less chance to get a block now >.>

[Raptorblaze]

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

The average person isn't that creative My efficiency on the stats page is low because i was having trouble getting their miner to work at first. Totally forgot the .exe name was poclbm-mod, not just poclbm in the batch file....*facepalm*  Hope they send me my payments soon, i've been running for almost 13 hours now and haven't seen anything. More information on the payment system would be appreciated.

We haven't found a block yet so we don't get paid yet... and the difficulty increased so we have even less chance to get a block now >.>

Yeah I was just perusing the Block solved history, I'm hoping to upgrade my miner with birthday money (No criticism, I'm turning 19 and still get birthday money) next week on Thursday.

[Raptorblaze]

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

The modified poclbm does not give you better performance -- more hashes per second -- nor does it find more shares than the unmodified.

Let me check to make sure I'm understanding this right:
Both clients do approximately the same in terms of mining
The modified client significantly reduces the load on the server
A reduced load on the server allows more users to join the pool
More users in the pool allows the pool as a whole to find blocks more quickly

I'm not seeing the disadvantage here....
Edit:Sorry for the double post!

[jgarzik]

oh and guys, you can use the normal poclbm with this pool so if that is suppose to give you better performance, why can't we just use that?

The modified poclbm does not give you better performance -- more hashes per second -- nor does it find more shares than the unmodified.

Let me check to make sure I'm understanding this right:
Both clients do approximately the same in terms of mining
The modified client significantly reduces the load on the server
A reduced load on the server allows more users to join the pool

Is the pool remotely near capacity?  If not, then it makes zero difference.

[slush]

Let me check to make sure I'm understanding this right:
Both clients do approximately the same in terms of mining
The modified client significantly reduces the load on the server
A reduced load on the server allows more users to join the pool
More users in the pool allows the pool as a whole to find blocks more quickly

I'm not seeing the disadvantage here....

(I simply cannot stay outside)

Yes, less load on server for +/- same total pool hashrate. But you (as a miner) are not motivated to have huge hashrate on server, you're motivated to have high OWN hashrate. Higher pool hash rate does not make your payouts higher (only more steady). So with long ask rate to server, you're cutting your effective hashrate and losing some valid shares because you work on stale jobs.

[bombo999]

hey slush ... perhaps if you spent more time working on your own pool it might re-open for registration sooner

[Raptorblaze]

hey slush ... perhaps if you spent more time working on your own pool it might re-open for registration sooner

This

Also, I'm in favor of an idea that doesn't limit the number of participants as much as yours with little disadvantages to the user themself, which this seems to do.

[neptop]

View your profile at:
http://www.bitcoinpool.com/users.php?u=xxx

...is wrong, it is user.php

[martok]

I'm not sure the modified poclbm does this. By looking at the code it doesn't seem to but maybe a compromise would be to use the "efficient" miner but if a block comes back as invalid, we submit a new getwork and start working on a new block. If a block is invalid, no sense continuing on the existing getwork right?

[geebus]

So you admit that your pool too favors faster miners when you specifically (incorrectly in every way except your one shortsighted emotions over statistics way) chided Slush's pool for doing so in your OP.

"Testing with" and "favoring" are two different things. We pay CPUs and GPUs the same amount for each share. We don't "favor" either one over the other.

[geebus]

(I simply cannot stay outside)

Yes, less load on server for +/- same total pool hashrate. But you (as a miner) are not motivated to have huge hashrate on server, you're motivated to have high OWN hashrate. Higher pool hash rate does not make your payouts higher (only more steady). So with long ask rate to server, you're cutting your effective hashrate and losing some valid shares because you work on stale jobs.

Maybe your pool wouldn't be in the situation it is in now if it had less network traffic against it.

Our version of poclbm does NOT lower the hashrate of anyone using it. Theoretically, or otherwise. It gains shares at the same speed, and as long as we're accepting the shares, it doesn't negatively impact the user in any way, but benefits us greatly.

Even if a small percentage (and it's small, < .55%) of shares are stale, we can still allow 10 new users for every 1 user that runs our miner due to the reduction in server load.

To be fair, a more efficient pool server means that costs per miner are lower and those savings "can" (and currently are) be passed on from the pool operator to the miners.

The problem is that the way that this pool has implemented their efficiency gains comes at the cost of increased percentages of Stale (unpaid) wasted processing power. And to make it worse, it specifically causes slower miners to incur the worst of this increase of Stales.

We've been completely open about why we said it was more efficient. We've been completely open about what our definition of efficient was... Our definition just happened to be the same as the dictionary's definition of efficient.

Yes, it is for the benefit of the server. We charge NOTHING to participate however, so there is no benefit to the "operators" aside from being able to participate in a pool that functions the way we want it to...

And no, the slower miners don't see any negative impact, because we accept shares, and pay them for shares for (CurrentBlock) and (CurrentBlock - 1). If a block is solved every 600 seconds, it would take them 1200 seconds to have their new shares for a getwork become stale.

If 1200 seconds is too slow for you to submit I share, I apologize, but I might suggest upgrading from your PIII to save you some trouble.

[xenon481]

So you admit that your pool too favors faster miners when you specifically (incorrectly in every way except your one shortsighted emotions over statistics way) chided Slush's pool for doing so in your OP.

"Testing with" and "favoring" are two different things. We pay CPUs and GPUs the same amount for each share. We don't "favor" either one over the other.

Your pool asks the miners to keep a high Share/GetWork ratio. In order to accomplish this, your pool requests that miners process the entire solution space of every single GetWork before requesting another GetWork. This means that the slower a miner, the more likely that that miner's solutions will be Stale.

If it takes a slow miner 300 seconds (5 minutes) to process through an entire GetWork's solution space (say a Core2 Quad CPU Miner), and if a block was solved by anyone in the entire BitCoin network even a full minute after the miner requested the GetWork, then that miner has been sitting there processing for 4 full minutes completely wasting the miner's time and electricity.

This increase in Stale Processing can lead to a very significant amount of wasted processing power, wasted electricity, and lack of pay for miners.

Even the miner in the OP (~160MHash/Sec) is requesting a GetWork once every 26 seconds instead once every 5 seconds as is the default on many miners. That's 5 times longer during which the work can become Stale. Now imagine taking that 5 seconds and multiplying it by 60 to get 300 seconds for a fairly fast CPU Miner. That is 60x the time during which the work can become Stale.

So, yes, your pool favors faster miners over slower miners by requesting that miners process the entire GetWork solution space and thus giving slower miners a significantly higher percentage of Stales than faster miners.

[xenon481]

And no, the slower miners don't see any negative impact, because we accept shares, and pay them for shares for (CurrentBlock) and (CurrentBlock - 1). If a block is solved every 600 seconds, it would take them 1200 seconds to have their new shares for a getwork become stale.

That is not what is stated in the OP.

- Anti-fraud protection.  We only accept shares from the current block, in the current round.