The last several pages are full of highly unprofessional banter. Can we please stick to the facts and lay of the ad-hom attacks?
I think the real problem here is that Luke-Jr has changed the rules of the game several times lately without warning. Some of these changes have resulted in the pool holding on to small, but not entirely insignificant, amounts of BTC owed to the miners. To make matters worse, these withheld earnings come with little explanation from Luke-Jr and little more than a vague promise to pay them out at some later date.
These events as of late are disappointing, to say the least, for a pool that prides itself on transparency. The MaxPPS change was expected for about a month before it happened. If people had a problem with it, they should have said so before then. As it turned out, the variation made the 40% MaxPPS impractical to run long, so I had to (retroactively) revert it to proportional rather soon. In short, all balances are presently correct, as determined by the original Proportional payout method, even if there is a (small) backlog on the US server. Occasional backlogs have been normal since almost the start of Eligius (ever since the 1 BTC minimum was implemented), and the only reason it's taking so long now is the general problems with getting the US pool running again. Since all the US blocks have long since reached the 120 confirmations, I have been making an exception to the usual policy by sending manual payouts on request to people who need their funds sooner. |
|
|
|
I'd like to know how long the pool hopper is not actively mining because the pool is above 43% of the difficulty (that is, how much time can the hopper spend on a different pool?). In percent.  It helps to figure out by how much the pool hopper gets overpaid for each payout method. About 2/3 of the pool hopper's shares were spent mining for other pools. |
|
|
|
I finally have real-world example graphs for most payout methods ( warning: heavy-load webpage), based on real-world data from Eligius for a random ~800 MHz miner over a ~4.5 day period. I also simulated the graphs as if he were pool hopping by reassigning his shares beyond 43% of a block to another user. This way, you can see visually how he would have been paid under the Slush Score, Proportional, Maximum PPS, PPS, and PPLNS systems. I would have added the Geometric method too, but I couldn't figure out how to make it work. The pool hopper spends about 2/3 of his time mining for other pools. Please use this thread to comment on the various methods (especially as they relate to Eligius's future), nominate new methods (which I might simulate a graph for, if it seems sensible), etc... Edit: Nominations for other methods should be made in this threadThese graphs took many hours to code and generate. If you find them useful, please donate: 12GJ27Fr9Wme2JT3ZkQMhzvHXNE8MXrAux
P.S. congrats 1AjsBb..., you're famous! Click here for latest version |
|
|
|
If I remember correctly, there's a special wallet where any generations that are created in a block but can't be paid out yet because there is no user with >1BTC balance are sent. It should be possible for luke-jr to send a standard transaction from that wallet to GimEEE to settle this once and for all. I can (and have been) make exceptions and manually send from the pool accounts, but GimEEE is demanding about 2 times what he is due, and if I offered to send his balance he would probably try to spin it as offering a settlement of a lower amount than he wants. Not to mention, why go out of my way for someone trolling? |
|
|
|
Coupled with the almost 7 BTC that the pool acknowledges it owes him but presumably has not yet made plans to pay him, I can see why this miner left and never returned to eligius.
If you have any disagreement on the math, PLMK where my mistake was.
There's a reason why all the top hashers have been with eligius less than 1 week:
After someone screws you out of BTC, would you keep mining with them?
Hopefully he won't do it to the new users, but you've all been warned. . .
Please stop trying to spread FUD. As you admit, the pool acknowledges the correct unpaid balance of 6.31658302 BTC (which isn't "almost 7"-- where did you learn math?). |
|
|
|
Please, post also instructions  yep too blind to find the download button I were assuming a set of patches, but apparently not. No reason to be an jackass for a valid point. no, i can't find the binaries either, just the source files. It's Python. There are no binaries. |
|
|
|
Why is the share rejection rate of Eligius for me consistently worse than other pools with LP? I've seen Continuum, Bitcoin Pool, Eclipse, and even bitcoin.cz (which doesn't have LP) all do better than Eligius in this respect. Yeah, this concerns me as well. Every time I look at my miner to check if it's doing ok, within minutes it shows a "timeout - can't connect" warning and about 8% of the found shares do never get to Eligius. That is also why my hashrate is under-reported. After the next payout I will give BTCGuild another try. Try the bleeding-edge DiabloMiner (I don't know what version; Diablo just fixed it a few days ago) or my branch of poclbm, both of which have been made more robust to handle network issues (which should hopefully be much less with the big upgrade). |
|
|
|
|
Probably not. You'd need to find a miner who will accept it and connect directly to him. You can get lower fees by merging the eligius_sendfee branch.
|
|
|
|
Are all of these invalid blocks normal for most pools? How does that happen? I'm getting a bit confused - for a while there my "unpaid reward" was negative. There was some issues earlier where stale shares were getting past pushpool and being reported as invalid blocks. Usually these would just show up as "stale" and "rejected" on the user's personal page. Other than that, I guess the network's had a lot of forking-lucky blocks lately. Luke-Jr, with the price a lot higher now than it was when you formed eligius, it seems wise to just lower the automatic payout threshold to 0.1. This would alleviate the complaint severity of you seemingly "holding" a relatively large amount of people's bitcoins whenever you have to do a server switch. Holding up to $15 for a week on an out-of-operation server is different than holding only $1.50 there. The plan is to lower it to ~0.34 BTC with the upgrade. |
|
|
|
Based on my mining activity with eligius approximately June 13th to June 16th, eligius underpaid me be around 5 BTC.
Approximately half is showing as needed to be paid, the other half is not credited at all.
How did he do it?
1) failing to pay out balance of >1 BTC on us server.
2) Pool split my mining work between eu and us servers, and not paying out the balance on eu server (<1BTC)
3) shorting my reward on rounds shorter than 90 minutes (while not increasing my reward for rounds longer than 90 minutes).
I will edit this post if luke-jr comes clean and pays up this debt.
Aside from shorting me, Eligius is really great, especially the statistics.
I'd recommend it for anyone who doesn't mind getting shorted and being forced to loan the pool money >1BTC.
The only truth to this is that you have an unpaid balance of 2.49442651 BTC on the US pool, which will be paid out as soon as possible when it is fixed, and an unpaid balance of 0.70262774 BTC on the Europe pool which does not meet the minimums required for payout. |
|
|
|
|
At least one developer of the Satoshi client has in the past expressed that they intentionally standardized the formatting on the "US" form, to ideally eliminate the ambiguity issues. If this is to be kept the case, "0,005" should probably be an error (ie, forbid leading zeros)
|
|
|
|
A lot of people don't know how to handle .xz though, so you'd still have to offer both choices in that case.
I'm not sure how much bandwidth of the download site is a problem at the moment. On every linux distribution not older than 5 years there should be no difference for the user at all. Nonsense. How many distributions include a xz decompressor by default? Even if you can figure out what to install easily, what command is used to extract? I'm not aware of GNU Tar including an option for xz yet... |
|
|
|
|
I noticed that listtransactions (and the GUIs) omit the address coins are generated to. For the random self-generated address, that makes sense, but normal addresses should really be shown... I suspect this is the reason behind MyBitcoin and other similar interfaces not working correctly with generated coins.
Since right now the interface shows a single "generate" entry for a block, no matter how many different addresses might be used to collect the reward, this is not simply a matter of adding a field.
|
|
|
|
Have you ever found a pool that has accepted a share that your modified client has attempted to resend?
Normally a rejected share won't be fixed by resending it. Rejected shares aren't resent. That's only for network issues. |
|
|
|
https://gitorious.org/~Luke-Jr/luke-jrs-poclbmChanges: - Real-time statistics show more than just hashrate-- also estimated hashrate (based on accepted shares), rejected share count and percentage, getwork count and efficiency (accepted/getwork)
- Optimizations around share submission
- If share submit fails, save it and retry a second later
|
|
|
|
Bump. I just realize a reason this is immensely useful (besides Eligius): no longer do transactions require unique destination addresses. A merchant can publish a single address/email pair for all purchases, and clients can send the purchase information via email, signed by the sending address.
If you want to use a single address for all purchases and still be able to tell who paid you and also pass secure messages then you need the method described in http://forum.bitcoin.org/index.php?topic=5965.msg87757#msg87757This can be implemented with the current network and client environment. So can this, and this is much more user-friendly... |
|
|
|
"HanSolo", your presence on IRC to discuss PPLNS has been requested by multiple people, if you have time. Thanks, I'll try to stop by IRC with a clear explanation in the next day or two.. when is 'prime time' for discussion? Pretty much 1500 to 0300 UTC |
|
|
|
|
ECDSA will break with quantum computing. SHA won't. I'd think ECDSA is the bigger risk.
|
|
|
|
AFAIK it is not yet possible to mine without fglrx (until someone work on this bounty). A while back, I recall seeing an example CAL program for free Linux...  |
|
|
|
|
Show Posts
