Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 # - page 123. (Read 458370 times)
May 06, 2013, 09:19:29 PM
WK - sent you a PM about manual payouts if possible. Thanks in advance!
May 06, 2013, 08:40:57 PM
Summary: Pool is online. Stats are online. No accepted shares we lost. Payout queue is clear.
Thank you all for you patience!
-wk
Thank you for the update and the work, wizkid057. Everything looks normal again from my chair.
-Sheep
May 06, 2013, 08:32:25 PM
Update with pool: everything was breaking everywhere, so I rushed to get the new server working.
New server Postgres is screwed up, so I set it up logging shares to a textfile for now.
Payouts and stats are down as a result, but hopefully it won't take long to recover from this mess.
New server Postgres is screwed up, so I set it up logging shares to a textfile for now.
Payouts and stats are down as a result, but hopefully it won't take long to recover from this mess.
Three day's no Payouts and Stats.........
OK! *clears throat*
... Greetings Eligius Miners!
Its been a rough past few days. Here's what's happened:
- Eligius's server was having some serious problems which appeared to be related to connectivity (bandwidth starved)
- Server was also having software issues related to memory and the virtualization software used to partition the pool and the web server.
- I was able to get a new, higher spec'd server online at a new data center several days before these issues became damaging, and I was unavailable when all hell broke lose with the original server to finish a clean setup.
- In my brief absence, Luke-Jr got in and quickly got the new server up and accepting connections and logged all shares to a well-formatted file.
- This broke stats (since the mining wasnt even on the same server!) and payouts (same issue) until I was able to migrate these key pieces of software and related data.
- I got accepted shares into the database as normal, and parsed the file that was made and added those to the database, then caught up the CPPSRB reward system.
- Coinbase payouts resumed shortly, and a manual payout was sent to catch up all payments missed while the reward system was offline. All payments are current up to the time of this post.
- Stats were offline mainly because of the huge size of the databases involved with the migration. They are now back online.
Just about everything should be back up and running. I will note that IPv6 connectivity is presently not available, but I will be working on that shortly.
I will be looking at all options in the coming days to make sure that Eligius remains stable and stats remain available.
On a side note, a generous miner has volunteered time and effort for a full redesign of the Eligius homepage, which should be online any day now!
Summary: Pool is online. Stats are online. No accepted shares we lost. Payout queue is clear.
Thank you all for you patience!
-wk
May 06, 2013, 08:18:03 AM
Three day's no Payouts and Stats.........
May 06, 2013, 12:24:51 AM
I was running 2.9.6. Just switched to 2.10.8 Seems to be working fine now. Thanks.
May 05, 2013, 10:49:03 PM
Pool is down for me. Anyone else?
Not stop "Abandoning stale search to restart"
This seems like a bug in BFGMiner - are you using the latest version? Not stop "Abandoning stale search to restart"
May 05, 2013, 10:40:24 PM
Pool is down for me. Anyone else?
Not stop "Abandoning stale search to restart"
Not stop "Abandoning stale search to restart"
May 05, 2013, 06:24:35 AM
Update with pool: everything was breaking everywhere, so I rushed to get the new server working.
New server Postgres is screwed up, so I set it up logging shares to a textfile for now.
Payouts and stats are down as a result, but hopefully it won't take long to recover from this mess.
Cool, cause I like your pool, but things were awful. Glad to see the server is helping. Got any idea when the stats might be back up? I'm testing some with your pool to see how it works for me now.New server Postgres is screwed up, so I set it up logging shares to a textfile for now.
Payouts and stats are down as a result, but hopefully it won't take long to recover from this mess.
When the statistics and payouts work again?
May 04, 2013, 03:21:49 PM
Update with pool: everything was breaking everywhere, so I rushed to get the new server working.
New server Postgres is screwed up, so I set it up logging shares to a textfile for now.
Payouts and stats are down as a result, but hopefully it won't take long to recover from this mess.
Cool, cause I like your pool, but things were awful. Glad to see the server is helping. Got any idea when the stats might be back up? I'm testing some with your pool to see how it works for me now.New server Postgres is screwed up, so I set it up logging shares to a textfile for now.
Payouts and stats are down as a result, but hopefully it won't take long to recover from this mess.
May 03, 2013, 05:27:19 PM
Update with pool: everything was breaking everywhere, so I rushed to get the new server working.
New server Postgres is screwed up, so I set it up logging shares to a textfile for now.
Payouts and stats are down as a result, but hopefully it won't take long to recover from this mess.
New server Postgres is screwed up, so I set it up logging shares to a textfile for now.
Payouts and stats are down as a result, but hopefully it won't take long to recover from this mess.
May 03, 2013, 01:02:04 PM
Yes, poclbm should gracefully handle it. But also eloipool could handle it by serving out 1 in this special case and use pdiff for any higher figures. When sending the value to the client, just ceil(pdiff,1.0) it? Call it a workaround for poclbm or whatever. Or check client name for poclbm and only serve it to them.
Sending 1 will cause miners to not submit, and thus not be credited for, some (tiny fraction of) shares.More problematic, poclbm does NOT send its useragent over stratum, so there is no way to identify it.
May 03, 2013, 09:36:36 AM
On the contrary, bdiff is a hack.
Anyhow, the point is that poclbm has this bug that affects any pool that wants to continue using the standard pdiff 1 target.
Anyhow, the point is that poclbm has this bug that affects any pool that wants to continue using the standard pdiff 1 target.
Yes it's a hack, but it's the hack used by bitcoind so it's sort of the standard (one could argue correct) way to represent the numbers.
Yes, poclbm should gracefully handle it. But also eloipool could handle it by serving out 1 in this special case and use pdiff for any higher figures. When sending the value to the client, just ceil(pdiff,1.0) it? Call it a workaround for poclbm or whatever. Or check client name for poclbm and only serve it to them.
The other option is that you and the poclbm author both refuse to provide a work around and then no one wins, but all poclbm users trying to mine at eloipool pools lose.
May 03, 2013, 12:47:26 AM
especially since it can be easily compressed down to a single byte (by counting the number of zero bits).
In other words, pdiff is a hack.Anyhow, the point is that poclbm has this bug that affects any pool that wants to continue using the standard pdiff 1 target.
May 03, 2013, 12:40:35 AM
https://en.bitcoin.it/wiki/Difficulty
Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?
There's two different standards, but bdiff only makes sense in the context of Bitcoin because of its floating-point block target.Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?
Pdiff makes more sense for pools, miners, and blockchain-independent difficulty measurements, especially since it can be easily compressed down to a single byte (by counting the number of zero bits).
Pdiff 1 = target 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, or 32 zero-bits
Pdiff 2 = target 0x000000007FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, or 33 zero-bits
Pdiff 4 = target 0x000000003FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, or 34 zero-bits
etc
But Bitcoin stores the target in a floating-point number type with 23 bits of precision, so it truncates them:
Bdiff 1 = target 0x00000000FFFF0000000000000000000000000000000000000000000000000000
Bdiff 2 = target 0x000000007FFF0000000000000000000000000000000000000000000000000000
Bdiff 4 = target 0x000000003FFF0000000000000000000000000000000000000000000000000000
etc
May 02, 2013, 10:56:09 PM
https://en.bitcoin.it/wiki/Difficulty
Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?
There's two different standards, but bdiff only makes sense in the context of Bitcoin because of its floating-point block target.Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?
Pdiff makes more sense for pools, miners, and blockchain-independent difficulty measurements, especially since it can be easily compressed down to a single byte (by counting the number of zero bits).
May 02, 2013, 10:19:44 PM
especially since it can be easily compressed down to a single byte (by counting the number of zero bits).
In other words, pdiff is a hack.
slush called it a mistake everyone copied from him.
May 02, 2013, 10:08:54 PM
especially since it can be easily compressed down to a single byte (by counting the number of zero bits).
In other words, pdiff is a hack.
May 02, 2013, 10:07:10 PM
https://en.bitcoin.it/wiki/Difficulty
Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?
Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?
This exactly.
May 02, 2013, 10:06:51 PM
standard pdifficulty
pdifficulty is not the standard.In any case, Eligius is completely stratum-spec-compliant here.
The spec doesn't specify a minimum difficulty, but you'll note that the default difficulty is 1, not 0.9999847412109375, making 1 an implied minimum.
May 02, 2013, 10:06:07 PM
https://en.bitcoin.it/wiki/Difficulty
Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?
There's two different standards, but bdiff only makes sense in the context of Bitcoin because of its floating-point block target.Pools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard?
Pdiff makes more sense for pools, miners, and blockchain-independent difficulty measurements, especially since it can be easily compressed down to a single byte (by counting the number of zero bits).
Jump to: