Topic: [NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :) - page 30. (Read 101960 times)

Fixed my UTC conversion function's method to check for DST and adjust accordingly. Thanks for letting me know.

Did the US just switch to DST?  The times on bitcoinpool.com no longer shows UTC, but rather UTC+1.  Perhaps use gmdate() or similar?


Cheers,

I am currently running the updated minor, and after having a minor hiccup relating to the modification of the .cfg file with regards to connecting to my local bitcoin client, everything is now crunching away happily again.

Keep up the good work!

-NobleX13

WE'VE UPDATED OUR MINER!!! PLEASE READ!!!

We've updated our miner to check against a local bitcoind instance running on the miner's PC to see if the block has changed during work, and if it has, to get new work. This will prevent miners from continuing to work on stale work once the block has changed.

Download the newest version at:

(Command Line + Source) - http://www.bitcoinpool.com/file.php?id=1 [7.9MB]
(Win32 GUI + Source) - http://www.bitcoinpool.com/file.php?id=2 [8.9MB]

In order to enable block checking, you must have do the following:

• Run 'bitcoind' (on Linux) or 'bitcoin.exe -server' (on Windows), and have a properly configured bitcoin.conf.
• Edit poclbm-mod.cfg to include the local host, port, rpcuser and rpcpass to connect to your local bitcoind.
• Add the '-b' flag to the command line in poclbm-mod, or to the "Extra flags:" box in poclbm-mod-gui.

If you're running multiple PCs for mining, with your bitcoind on a single machine, you can set your 'rpcallowip' value in bitcoin.conf to '*.*.*.*' and point all of your machines to the central bitcoind.

_{Bitcoin.conf:
poclbm-mod.cfg:}
In poclbm-mod.cfg, change "host=" line to reflect the IP address or hostname of the PC running bitcoind (or bitcoin.exe -server), and enter the port, followed by the username and password set in bitcoin.conf.

Thanks for the support, and have fun mining!

Please could we accept only GPU miners?  Or please could we ban anyone like

bitcoining:
http://www.bitcoinpool.com/user.php?u=bitcoining

He has 12,000 get works and 20 completed.


Also I can confirm that I am getting paid out well from this pool after running it for 2 days so far.

I have been mining for this pool for a few days now, and now have a steady stream of BTC thanks to you guys.  Keep the hard work!  Mining under NobleTeam.

Likely because Geebus changed the pool to accept shares for both the current workset (useful) and the previous workset (wasted) but not anything older than that. I would expect (but don't know) that the pool would report to poclbm (and the modified version) that previous workset shares were "accepted" as opposed to "stale or invalid".

May I offer a very simple solution?

Simply modify the client to do the following:

1) Maximize time between get works so that shares processed : get work ratio is as close to 1 as possible

UNLESS time between getworks / time to solve a block is greater than 2.5%.

so if time to solve a block is 1000 seconds and time between getworks is more than 25, set time between getworks to 25.


Then less than 2.5% of the work is wasted and we're still better off than paying a 3%, 5% or 10% commission like the other pools.


Having said that, maybe I don't completely understand everything because I have two instances running on my two old gpus currently.  One is a 4850 and one is a 4870.

On the 4850 my time time between get works is 88 seconds with a 4% stale rate and on my 4870 it is 44 seconds with a 0% stale rate.  This after thousands of getworks.  

According to slush's calculations my 4870 with 44/600 should have a 7.33% stale rate.  Why is it consistently 0?


p.s. Donations to 13PNeVP5hNbmXVccfeC73BENtKdht2aEVe much appreciated

After reading through some of the recent discussions, I was wondering if when the miner (poclbm-mod) reports a result, does it get an indication that the getwork is stale? If it is stale, does the miner then request a new getwork?

Thanks for all the work setting up and running the pool.

Prove that anyone is receiving a reduced payment due to it and I'll politely accept it and ban all CPU users from my pool so that they can be told to fuck off by another pool operator... until then, I'll ask that you stop posting unfounded accusations about our pool.

Likewise, any discussion not directly related to connecting to our pool, joining our pool, issues or feedback on our website's functionality or display, or any potential concerns related to your active mining accounts on our pool, will be considered trolling and will be ignored.

Good day Sirs.

Slush, you may have missed the post where Geebus said (even though FairUser kept saying otherwise for quite some time) that they are accepting stale shares (CurrentWork-1) for inclusion in the payout calculations.

This means that slow users with many *would have been* stales are still just sitting there, processing away at useless work for 5 to 10 minutes and yet still get paid from the proceeds of the solved block. This is great for CPU Miners because they are getting paid even though they are doing useless work.

But where is the money coming from to pay for this huge amount of useless *would be* stale shares?

It's coming out of the pockets/payouts of the fastest GPU Miners! Faster Miners are letting Slower Miners have a part of their proceeds even though the Slower Miners are processing useless work and weren't contributing to the success of actually solving the block.


So, that 5% penalty for so many *would be* stales isn't coming out of the pockets of the people that are actually getting the *would be* stales, it's coming out of the pockets of the people that spent money to have fast hardware and very few stales!!


With the change to pay stale shares, this pool went from being one of the best (payout-wise due to 0% fees) for extremely fast miners (say a 5970) that get can process the entire GetWork solution space in 10 seconds or less, to one of the worst (only ahead of Pay-Per-Share 10% fee pools) due to subsidizing the payouts of those with slower hardware and thus more *would be* stales.

Likewise, this pool went from being an absolute nightmare impossibility for extremely slow miners (like CPU or nVidia GPUs) to being better than the PPS 10% fee pools (unless there are only slow miners in the pool......), but still wouldn't pay out as much as a normal pool.

With ask rate of 30 second and average time betweenn blocks 600 seconds, the ineffeciency of "long askrate" is 30/600 = 5%. This is FACT. *headdesk* With this settings, it makes this pool to one of the most expensive ever, by hidden costs which most people don't understand.


I wrotte he *think*, not that he tell.


Yes, I agree. But I don't have enough self-denial to stand away when I'm reading all this. It is not anyhow related to my position of pool operator, it is just because I see how those talks about "most effective pool" can confuse new people.

By the way, I'm not motivated by shooting to everyone else's pool; You can see that I'm leaving Tycho's pool and other alone, because they don't fooling people with pseudo-science. Currently the really most effective pool is Tycho's one, not mine; It's because I had long polling still disabled.


Yes, I proven that with calculation above.


I'm trying to explain this with "normal words". I'm not native speaker and it is very hard to me, but I believe more people will understand longer explanation better than "30/600 = 5% ineffectivity". But it is fact, it is how it works.

Btw geebus didn't response why he think that other (definitely very smart) people didn't implemented longer askkrate, too. This was one of my point.


Those talks annoys me, too. I'm trying to stand outside, trust me . As my homework, I will try to not response to anything after this post .

I have to say that I find your criticism of geebus to be rather over the top and unjustified. I didn't see him calling anyone an idiot and, unless he was, you should not be accusing him of doing so. Are you after a flame war? This is not the place to have one. As the admin of another pool, I think you should be more respectful.

If you think that your example, that 5% of the submitted shares are stale, is realistic, then I would have liked to see an argument to back that up, as the example is irrelevant otherwise. Unfortunately, with your tone and your lack of thorough argumentation, you have rendered any actual point, that may have been contained in your post, pointless.

I would personally request that you refrain from posting inflammatory messages in this thread.

Common, guys, why do you think that ALL people arround you are idiots? Why do you think that m0mchil, diablo, jgarzik, puddinpop and others implemented frequent ask rate in their miners? Do you really think that they had not an idea to set it to something longer? They had, but all of them understand that it is bad.  You're reinventing wheel. Wheel with four sides.

You are solving something, what is non-issue. Mining is not about shares/getwork, mining is about shares/time! Moving with ask rate, nobody will search more/less shares per unit of time. And nobody pay more bitcoins to user just because he is more effective from side of "shares/getwork".

You still calculate, that less pool load => more available capacity => more ghash. But nobody is even paid for total pool hashrate, everybody is paid for his shares/total shares. When increasing ask rate, you are lowering your pool load, but increasing probability of stale shares. This mean that every single person have LOWER effective hashrate. He has still 100 Mhash/s on his side with single GPU, but thanks to low ask rate, there are (for example) 5% stale, so user is really adding to the pool only 90 Mhash/s.

Yes, it is with minimal pool load, but he is cutting his income! You have nice tables and graphs, but they display something absolutely irrelevant ; pool users are not interested in your pool load, they are intesteted in their payouts. It's fine that you are running pool with minimal cost and for free, but people pay hidden cost in their lower efficiency (miner efficiency, not pool efficiency).

I'll try to explain that better on one absurd example:
Nonce is number with max value 2^32, it was choosen to be 32bit number by satosthi (probably). But there is no direct relation between nonce range and fact that share with difficulty 1 is one from 2^32 tries; those numbers are choosen artifically. Even better, when I did first version of pool, I could pick one share to be difficulty 2 (2^33 tries) or even more. I choosed difficulty 1 just because I liked that and others adopt my choice. So let's imagine that satoshi had good day and decided that nonce is 2^64. Does that mean that the pool will be the most effective when miners will crunch whole nonce space? Definitely not, because there will be few more blocks sooner than common miner crunch such large space and refresh his job, so majority of his done work was useless. But let's imagine, such ineffectivity! Miners are crunching only few % of 64bit nonce space!

So tell me, please, why are you so much amazed with getwork/share ratio 1:1 ? Do you finally see that there is no reason and it does not improve share rate of anybody?

To be fair, you're not interfering, just trying to publicly discount our comments, in our thread, about our pool, in reference to our users, and their participation in our pool.

Likewise, view the above datasets. Longer askrates yield a higher probability of shares in a lower amount of getworks when compared to incredibly low askrates and hoping an answer is discovered in less than a second of hashing, with a slow hashrate.

It's not a theory, it's not guessing, it's not some equation we're basing an assumption off of. It's data we've collected, and analyzed, and derived a  reasonable principal from. That principal just so happens to be that a higher askrate, up to and including the number of seconds required to process an entire 2^32 getwork, does yield the same amount of results, with less getworks... and that the likelihood of finding an answer in milliseconds, or single seconds, is incredibly low.

Therefore: More answers for the same number of requests.

You seem to be implying that I am attempting to interfere with "allow[ing] us to run our pool the way we choose to."  That implication is false, just like the assertion that changing the ask rate from 5 to 20 or more seconds "would find more shares" (direct FairUser quote).

You are and have always been free to run your server however you choose.  I don't have the power to interfere with that, nor do I want to.

On the other hand, I and others are free to hang out in this forum thread and point out things like the above quote.

In any case, long pooling in slush's and Tycho's pool looks interesting.  If it takes off, maybe that will eliminate the need for policies like this, in your pool.

I didn't say you did. I just asked you to allow us to run our pool the way we choose to.


http://bitcoinpool.com/thedata.html
3 different datasets and a comparison of the number of shares found for 3 different askrates to those that would have been found at lower askrates or with CPU miners.

It isn't proving the discovery of any pattern aside from the fact that the likelihood of finding an answer in 1 second on a CPU miner is < 5%, whereas it causes a significantly higher server load to try.

Even if a new block is solved every 600 seconds, setting an askrate of 20s or more would significantly decrease server load, and not likely increase the chance of an answer being for the previous block by any significant amount.

I'm not saying any pattern has been discovered. I never said SHA256 has been broken. I am however showing you actual proof that it is not a 50/50 chance on whether you will find an answer immediately upon switching to a new getwork.

I don't know of a video, but I'll try to explain it here as easily as I can... These are not in-depth answers by any means and are significantly simplified for the sake of explanation.

Block -
A large portion of encrypted data that, once solved, awards the individual or pool who solved it 50 BTC. Blocks are used to carry all transaction data for the bitcoin network.

Share -
Credited to a miner in a pool who finds a hash for a getwork. Your total number of shares submitted vs. the number of shares submitted by the entire pool determines your payout when the pool solves a block.

Getwork -
A 2^32 chunk of the block hash with the midstate already solved by the pool server. A much smaller piece of data that allows the miner to generate hashes (shares) for the pool at a faster rate. Any getwork could potentially result in the "answer" for the block itself.

How does a block become stale? -
A block doesn't, however a getwork can become stale when the current block the network is working on has advanced before the miner processing their current getwork has finished and asked for new work. Our pool (Bitcoinpool.com) still credits miners for anything from the current block, or previous block, so stale work in this case does not affect the individual miner.

What are we calculating the hashes of? -
As a miner in a pool, you're calculating hashes on getworks, which the pool server then uses to try and solve blocks. As an individual, outside of a pool, you're trying to accomplish the same thing, but by yourself. Think of it like a brute-force cracking an encrypted piece of data. More people working together means faster iteration through all the possibilities.

I hope that helps to at least some degree.

While not holding data to prove one way or the other, I must concur with jgarzik for the simple fact that unless there is something predictable about sha256, and thus we should all be working towards replacing it for bitcoin usage, the random nature of the calculation means that historical data bears no weight into future prediction.

This is just another way to say that just because you've gotten heads 10 times in a row, doesn't mean your changes of getting heads for the 11th time is bigger, assuming a well balanced coins and a good, strong throw. It is always 50%, really.

If you can in fact prove that you found a pattern on the hash calculation towards H==0, that is a potential attack vector and should be investigated. Please share the real world data you speak of!