Bitcoin Forum
December 06, 2016, 02:26:37 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 »
  Print  
Author Topic: [NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :)  (Read 96023 times)
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 12, 2011, 02:32:33 AM
 #161

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
1481034397
Hero Member
*
Offline Offline

Posts: 1481034397

View Profile Personal Message (Offline)

Ignore
1481034397
Reply with quote  #2

1481034397
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481034397
Hero Member
*
Offline Offline

Posts: 1481034397

View Profile Personal Message (Offline)

Ignore
1481034397
Reply with quote  #2

1481034397
Report to moderator
1481034397
Hero Member
*
Offline Offline

Posts: 1481034397

View Profile Personal Message (Offline)

Ignore
1481034397
Reply with quote  #2

1481034397
Report to moderator
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
March 12, 2011, 03:08:08 AM
 #162

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?

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


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
March 12, 2011, 03:16:28 AM
 #163

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?

Quote
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
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 12, 2011, 03:54:27 AM
 #164

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.


Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 12, 2011, 06:42:41 AM
 #165

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
March 12, 2011, 07:36:50 AM
 #166

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.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 12, 2011, 07:47:27 AM
 #167

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 12, 2011, 08:08:58 AM
 #168

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
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 12, 2011, 08:41:26 AM
 #169

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
dwarf
Newbie
*
Offline Offline

Activity: 2


View Profile
March 12, 2011, 10:17:36 AM
 #170

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
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
March 12, 2011, 01:02:34 PM
 #171

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.

Quote
I didn't see him calling anyone an idiot and

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

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

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

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

Quote
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 Smiley. As my homework, I will try to not response to anything after this post Smiley.

xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 12, 2011, 01:27:16 PM
 #172

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.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 12, 2011, 01:43:28 PM
 #173

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
nightskywalker
Newbie
*
Offline Offline

Activity: 4


View Profile
March 12, 2011, 05:12:00 PM
 #174

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
Jr. Member
*
Offline Offline

Activity: 30


View Profile
March 12, 2011, 06:34:52 PM
 #175

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 Smiley

All donations (even 0.01 BTC) are much appreciated! Thank you!
13PNeVP5hNbmXVccfeC73BENtKdht2aEVe
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 12, 2011, 09:08:25 PM
 #176

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

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
NobleX13
Newbie
*
Offline Offline

Activity: 2


View Profile
March 12, 2011, 10:21:31 PM
 #177

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
Jr. Member
*
Offline Offline

Activity: 30


View Profile
March 13, 2011, 03:13:14 AM
 #178

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.

All donations (even 0.01 BTC) are much appreciated! Thank you!
13PNeVP5hNbmXVccfeC73BENtKdht2aEVe
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 13, 2011, 07:21:47 AM
 #179

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!

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
NobleX13
Newbie
*
Offline Offline

Activity: 2


View Profile
March 13, 2011, 08:02:38 AM
 #180

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
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!