|
Maybe you should change Luck last 24H to something like Luck last 72H.
|
|
|
|
it's accepting shares but stats page is messed up and "Total bounty for 24h" is 0.00000000?
Idd, roundtime 1d 01:41:51. That's not right Nope, this is normal numbers with current difficulty and pool hashrate power. thanks for that dbitcoin - also getting 0.00000 for 24 hours. bit grim at the moment then  Looks like the perfect time to let in new miners I like my income per blok right now but he swings are a little but too much I enjoy it as is. |
|
|
|
|
My rejects have spiked recently? Anyone else having this issue?
|
|
|
|
With the current threat of an SC meltdown, I will be taking the SC pool offline at block 35250.
I will bring it back up once the new client is released.
This means everyone back to BTCs for a few weeks. I think SC has caused this pool more harm than benefit with all of the issues that client crashing has had on the BTC pool. |
|
|
|
|
BLOOOOOOOOOOOOOOOOOOOOOCK!
|
|
|
|
Ok. My internet is back.
The solidcoin 1.04 client just doesn't want to play nice with pushpool...... It's back up.
UPDATE: seems memcached is acting up, not so much pushpool.
yes, memcached is zombied. Forcing server reboot, should only be a minute.
UPDATE2: Back up and running full steam.
I am still getting periodic disconnects and stuff. Are you still having solidcoin issues? |
|
|
|
getting connection errors with SC. Hard lock again?
He said he took that pool down because it was what was crashing Bitcoin. why yes he did. i guess i should read the updates  Wait, he said he brought it back online after that. So you were right  |
|
|
|
getting connection errors with SC. Hard lock again?
He said he took that pool down because it was what was crashing Bitcoin. |
|
|
|
BTCguild with their 1 hour delay on stats makes the simplest PP system practically hopper proof.
I doubt that, hoppers are just too lazy to hop it properly. It's true. You can still hop it in exactly the same manner as before, it just is less effective. To make proportional hopper proof you need a delay that is longer than a round could ever conceivably be. |
|
|
|
|
My primary pool was having issues last night, and at one point it looks like CGMiner just idled my gfx cards instead of switching to the backup. Also I was getting a lot of caching. When exactly does the miner make the switch to the backup when the primary is messed up? I had to manually change the backup to my primary when I saw that.
|
|
|
|
My miners aren't connecting!
Lot of stales!
Site is saying it's broken too!
Pool is definitely acting up again!
Me too, I am getting a ton of downtime and communication errors in CGMiner. Switching overnight to my backup. |
|
|
|
Looks like the solidcoin client db was corrupted. rebuilding it (sorry for the gazillion longpoll messages).
Basically this, on both! Welcome back! We've been missin' ya around here! This MFing block....Robble...robble! No kidding, this block is BRUTAL. make it end! Find two more blocks yourself Actually, excitingly, I am going to be bringing another 700mh/s on tonight (I hope). So I should be back to like 1.2 gh/s I hope. |
|
|
|
Looks like the solidcoin client db was corrupted. rebuilding it (sorry for the gazillion longpoll messages).
Basically this, on both! Welcome back! We've been missin' ya around here! This MFing block....Robble...robble! No kidding, this block is BRUTAL. make it end! Find two more blocks yourself |
|
|
|
I guess I need to get some of the 'second edition' from you, huh? |
|
|
|
is the pool down?
It's either up, but just a little bit, or cgminer is doing an awful job of rerouting all my work to my backup pool by looking at my hashrate there. Oops! Now my fully 400 MH/s is at my backup, so I suppose we are. |
|
|
|
is the pool down?
It's either up, but just a little bit, or cgminer is doing an awful job of rerouting all my work to my backup pool by looking at my hashrate there. |
|
|
|
Got my PCI-E 16x extender and silver coins. Thanks a lot!
Glad to hear it made it through customs! Note: I no longer have any PCIe extenders! |
|
|
|
If there are 10 pools like this, can't I set them all up to be .1N a day in advance or whatever, mine for a bit at one, and then bump up the N and jump to the next .1N pool? Especially if you allow people to change their N at will, they can just make it float along so that their last batch of mined blocks is always in focus, until they drop it back to the minimum and begin mining again.
I'm not sure I understand what you mean, but I think you missed the point that you can configure what X will be for the future shares you submit to the pool, not for past shares. Although there's no problem with changing X for past shares, as long as they're rescaled to maintain the same expected payout. You are right, I misunderstood. Thanks! |
|
|
|
Something that I'd be interested in and where I'd really love to know if it's possible:
Can you let your users choose N (in multiples of D) individually?
Let's say I have a miner that wants to have payouts as fast as possible and be able to cash out and leave the pool quickly at any time - so he chooses N = 0.5*D
Another one really loved the idea of prop that every share gets paid at least something and wants to be paid something at every (or nearly every) share, so he chooses N=10*D
Is it possible to pay these users their fair share without enabling them to hop the pool by creating a few workers witrh different Ns and choosing the optimal(?) one?
If there is a scoring system for this (and I suspect there is), users then could "tune" the pool payouts + variance to their individual needs. If you first had N=1 and then set it to N=10, of course you'd only apply this to shares submitted afterwards, not to past shares...
Yes, this is possible. It creates some variance for the operator, but if the pool's composition doesn't change much it's fairly small. Basically, when you go backwards in the list of shares, you pay each share (sB/X) if the total score so far is less than X, where X is the value specific for this share. For participants it doesn't matter at all that others use a different X, because their own payments are exactly like in uniform PPLNS. For the operator it can matter, because there's no guarantee that the total paid is equal to the block reward, but long-term it will average out and I don't think the variance will be much of a problem. This is consistent with some ideas I have for moving away from traditional reward systems and using a more general "futures market" for pool shares. Instead of distributing block rewards, the operator keeps block rewards but allows miners to trade shares for "bets" on blocks found in the future. This way there's no fundamental need for different miners to take the same bets. If the bets conform to one of the known reward systems, the system will reduce to them, and if the bets are offered in a way that the total obligation per block is equal to the block reward, you have 0 operator variance. And these contracts could be traded on an exchange, so investors who are not risk-averse and not mining themselves, can trade instant money for a contract that will have a higher eventual expected return. This will also allow miners to get cheap PPS. But I'm getting ahead of myself... In the more immediate future, you can have a system where a miner can configure in the pool's website what reward system and parameters he wants to use, and get a quote for the fee the operator demands to compensate for the induced variance. If there are 10 pools like this, can't I set them all up to be .1N a day in advance or whatever, mine for a bit at one, and then bump up the N and jump to the next .1N pool? Especially if you allow people to change their N at will, they can just make it float along so that their last batch of mined blocks is always in focus, until they drop it back to the minimum and begin mining again. |
|
|
|
|
Show Posts
