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

[geebus]

Im currently using this pool, and it's great! but is there a way for me to change my account details? such as payment address, or password?

Those features will be added in the next day or two.

[jgarzik]

However, we have scanned over tens of thousands of shares worth of logs and found the real-world proof that this simply isn't the case.

Instead of bolding an unsupported claim, how about presenting this real-world proof that sha256 has been broken, and certain hashes are acquired more rapidly than others?

There is no reason that a SINGLE USER should be generating the same amount of traffic as the rest of the pool, and no offence to you, because you've done many great things for the bitcoin community and I respect both your knowledge and opinions, but in this instance, I'm going to have to politely request that you let us run our pool the way we choose to run it.

Did I ask you to change anything?  No.  Simply stating the facts.

[nelisky]

However, we have scanned over tens of thousands of shares worth of logs and found the real-world proof that this simply isn't the case.

Instead of bolding an unsupported claim, how about presenting this real-world proof that sha256 has been broken, and certain hashes are acquired more rapidly than others?

There is no reason that a SINGLE USER should be generating the same amount of traffic as the rest of the pool, and no offence to you, because you've done many great things for the bitcoin community and I respect both your knowledge and opinions, but in this instance, I'm going to have to politely request that you let us run our pool the way we choose to run it.

Did I ask you to change anything?  No.  Simply stating the facts.

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!

[geebus]

Is there a nice easy to understand video that explains what a share is and what a block is and how the get work function and ask rate tie into that?

Why are the chances of getting a stale block higher with a get work every 60 seconds?  How does a block become stale?  What are we calculating the hashes of? 

I read the wiki and bitcoin site faq and it still doesn't answer a lot of questions.  I'd like to understand the generation of bit coins in much more depth.  Thank you.

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.

[geebus]

Did I ask you to change anything?  No.  Simply stating the facts.

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

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!

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.

[jgarzik]

Did I ask you to change anything?  No.  Simply stating the facts.

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

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.

[geebus]

Did I ask you to change anything?  No.  Simply stating the facts.

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

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.

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.

[slush]

Therefore: More answers in less requests.

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?

[geebus]

Therefore: More answers in less requests.

Sorry, my bad. I fixed it. "More answers for the same number of requests."

i.e. Instead of 5000 getworks requested and 200 shares submitted, I can submit FAR MORE shares for the same 5000 getworks if I process the entire getwork.

I never said anything about time regarding more answers. However, in the same timeframe, I can submit the same number of answers with considerably less getworks.

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 600 Mhash/s on his side with single 5970, but thanks to low ask rate, there are (for example) 5% stale, so user is really adding to the pool only 570 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?

I'm starting to get very annoyed at the fact that you people don't seem to even be reading my posts.

The ENTIRE point of this is that a miner can get the same number of shares submitted with LESS getworks, thereby reducing the load on our server while working and being JUST AS EFFECTIVE.

I'm done explaining this to you. You're not reading what I write. You're not taking the time to understand what the point of this is, and I'm getting sick and tired of re-explaining myself repeatedly.

1:1 ratio doesn't increase the share rate of anyone. It does however give them the exact same amount of shares, in the same timeframe while reducing our server load significantly.

If it doesn't effect you, then you don't need to post about it. If you don't like it, don't participate in our pool.

[dwarf]

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.

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.

[slush]

I have to say that I find your criticism of geebus to be rather over the top and unjustified.

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 didn't see him calling anyone an idiot and

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

As the admin of another pool, I think you should be more respectful.

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.

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.

Yes, I proven that with calculation above.

Unfortunately, with your tone and your lack of thorough argumentation

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.

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

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 .

[xenon481]

I have to say that I find your criticism of geebus to be rather over the top and unjustified.

With ask rate of 30 second and average time betweenn blocks 600 seconds, the ineffeciency of "dynamic 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.

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.

[geebus]

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.

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.

[nightskywalker]

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.

[datathe1st]

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

[xenon481]

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?

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

[NobleX13]

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.

[datathe1st]

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.

[geebus]

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:}

Code:

rpcuser=user
rpcpassword=password
rpcallowip=0.0.0.0

_{poclbm-mod.cfg:}

Code:

host=localhost
port=8332
rpcuser=user
rpcpass=password

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!

[NobleX13]

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