I use Slush's pool, so this question may belong in that thread. However, if it is common to all mining programs, or if it is on the client side (my end) then I suppose it deserves its own thread.
It is related to the pool, I'll add next server today, which fix the problem. |
|
|
|
Your mastery of mathematics does you credit. However, the tax man, wherever he may be, seems to tax this kind of thing about once a year and my post questions projected returns over that period. 1/20 * 1000000 * 12 > "a half million". I do not believe Slush would be responsible for the tax, were he in the US, and Slush would likely only be responsible for tax on 2%. But tax laws are wildly different everywhere.
a) Pool isn't crunching money, but Bitcoins. I don't see any law talking about Bitcoin taxes yet. b) I didn't withdraw the bitcoins from pool fees, so I don't have any tax duties yet. c) When I withdraw the bitcoins, I'll pay 15% tax of "other income". |
|
|
|
Approx. cluster performance: 209.218 Ghash/s is that true?  No, it's the (known) bug. |
|
|
|
does the server think I am disconnecting/reconnecting?
No, that means the request from the miner to server timed out. I was busy during weekend, but I'll set up the third server tomorrow, so this should be definitely fixed, as there is no rising load on the pool (thanks God!). |
|
|
|
it seems that my payout has also dropped below what the difficulty increase should say
That's because yesterday was one of first day with higher difficulty and we also hit very bad day (see the round with almost half of million shares). Today we should be back near the expected reward. That's the life. |
|
|
|
how can i have a fraction of a share  ? Oh, I think I finally understand. Yes, you can have a "fraction of a share". Because pool reward calculating isn't share-based. As you have only tiny amount of hashpower in the pool, you have much higher variance every round. And finally, 2% of 50 BTC isnt 2 BTC. |
|
|
|
Somebody is getting a free ride
Who's Idea of fair is this
Send me some of what they were smokin
Hey bobR, I see you're upset, but I don't have an idea what are you talking about?? Are you high? |
|
|
|
|
Hey guys, this is thread about pool, not about power consumption, cards, tuning of miners and so on ;-)
|
|
|
|
Don't use the word "anonymous". The person who hears that word will assume it means something quite different from how Bitcoin works.
+1 Bitcoin is not _only_ for the selling drugs :-). |
|
|
|
after 60 - 90 seconds of uping your score you return the valid block to finish the round.
There is new bitcoin block every 600 seconds, but with very random occurence. When you keep the found block for yourself for 60 seconds and pull every your power to this pool, you risk loss, because somebody else can submit other valid block in the meantime; maybe the pool which you disconnect few seconds before. Maybe you can teoretically achieve few % of additional reward by attack like this, but you risk much higher variance as you will be successfull only in every few attempts of this. |
|
|
|
Does anybody know what just happend to the Ghash/s rate, it more than doubled just like that to 134,531Ghash/s for several minutes, i believe its back to 60 Ghash/s again now.
This is known bug in hash meter, but I don't plan to fix it now. I'm focused on pushwork now as it is the only way how to handle rising load and open registrations back again. |
|
|
|
Does anyone think it's because there are so many invalid or stale hashes that's making us so unlucky? Although if I'm correct that shouldn't make a difference it should only lower amount of shares.
Hi, I just wake up. The such long round looks very strange, but after deep system analysis I didn't find any major problem. As few users disconnected (probably because such long round), pool is currently in very good condition. Yes, time to time, there were some peaks which leads to some network timeouts (I'm still trying to resolve this), but as number of found shares in round is rising, it should not affect the pool performance in way of such unlucky rounds. So demonofelru is right. |
|
|
|
The problem is that we do not have enough speculators.
+1. More speculators = better liquidity, smaller spread. |
|
|
|
The official bitcoin program considers 6 confirmations to be enough to change a transaction from unconfirmed status, but slush's pool requires quite a few more confirmations than 6. Bitcoin client needs 6 confirmations for common transactions and 120 confirmations for generated block. As pool is using standard bitcoin client itside, it also needs 120 confirmations to pay out the block rewards to participants... |
|
|
|
With the recent difficulty increase of ~30%, we should expect our payout to go down by ~30% if our hash/s stays the same, correct? Correct. Everytime the difficulty changes, your average reward change too. Usually will be a bit lower :-). |
|
|
|
slush can correct me if I'm wrong, once the push infrastructure for work distribution is complete, the server will be able to notify the clients to stop working on the block.
Hey, nice feature request :-). By default, with push protocol, server will notice clients that there is new block to solve, but it doesn't say anything if the previous block was found by pool or by another miner. But it might be handy to set some flag, when the block was found by pool, and miners can handle that in some way (show message, play sound, make you a coffee, ...). |
|
|
|
my threshold is set at 1.0 bitcoins, but 5.82 bitcoins have accumulated um my confirmed rewards. is anyone else having this problem.
Check your wallet address. |
|
|
|
I thought about that too, but I tried correlating them to block durations and block solve times and found that I was getting several even while in the middle of very long blocks.
Yes, there are really performance peaks time to time. Before few minutes, there were >2000rq/s for no reason. I don't know if those floods are from regular users or if somebody is trying to overload server. For sure, I'll add next server tomorrow. |
|
|
|
|
Because of huge rise of traffic every day, I decided to close pool registrations right now. For example, over this night the number of requests rise from 300 getwork/s to more than 500 getwork/s. I simply cannot add new server every day. I also need more time to finish my work on push based protocol and currently the maintenance of rising load consume too much time.
Once the pushwork stack will be ready, I open registration back again.
|
|
|
|
I've too got 0E-8 reward (instead of "none") for once, maybe it should be bugreported hereby.
That's not a real "bug", it is just another notation of "zero" . But you are right, it should display normal number. |
|
|
|
|
Show Posts
