|
I think this could work if it had some sort of real-time interface with sniping extension, like in penny auctions where the bids/bets come in slowly during the normal time and the real game starts with the late bids that each extend the auction for a few minutes.
|
|
|
|
So you mean something similar to RSMPPS but also favor unpaid shares from miners who are still active. So if miner A worked on block 1 (a long block) and didn't get fully paid. And miner B worked on block 2 (another long block) and didn't get fully paid. Miner B stopped mining with the pool, but miner A continued mining. When the pool finally starts to get lucky and has enough BTC to pay the unpaid shares from block 2, we might favor paying miner A for his work on block 1 because he's still active instead of paying miner B for his work on block 2.
I think seems ok. It will give people incentive to keep mining and stick with the pool. But I can't think of a good formula that makes this simple to understand and implement. It might turn away miners due to it being too complicated even though the idea behind it is valid.
It seems similar to MaxPPS, which pays you more than proportional on long unlucky rounds only if you have your own surplus credit from participating in short lucky rounds. This method was also proposed for Eligius, but it gained some negative publicity, because some people mistook its effects as withholding payments by operator. No, it's still the same shared risk principle as the current system since only the maximum reward credit would be affected. The proportional reward for each long round would stay the same, only the accumulated MaxPPS credits would be pushed forward to benefit those who continue to mine until the pool gets lucky again. |
|
|
|
Something along those lines, yes. I guess the only drawback is that if the pool would grow quickly during a bad luck period persistent miners would have to share some of their unpaid credits with new miners, but that's still better than the risk of having the pool stall and maybe never recover. It would probably need some weighting based on contribution throughout the whole stint of bad luck. I agree that it's a bit complicated, and I also feel that while I think the concept has something I would like to see someone with more number skills than me analyze it.  |
|
|
|
Just throwing out an idea here as well... it's quite unpolished, as I came up with it a couple of minutes ago...  Would a "tax" on old Max rewards be some sort of compromise? I'm thinking of some sort of system that moves accumulated unpaid PPS during longer streaks of bad luck and pays it forward to the the current round... let's say that with two rounds it proceeds as normal, but when the pool goes into the third bad block it starts taking a percentage of the unpaid shares from the first round and adds those to the current round, and if there's a fourth bad round it takes a cut from both round one and two and so on. That way, the unpaid PPS from those who jump to another pool would gradually be shifted over to those who continue mining. Not exactly sure what you mean by this. What does moving unpaid PPS from previous unlucky rounds to current round mean? I'm thinking about a way of shifting the deficit forward – in practice it would mean that part of the deficit from old rounds would be added proportionally to the maximum rewards in the current round. It wouldn't increase the direct reward, but new and persistent miners would have a chance to get a larger part back when the pool starts to catch up with the deficit again. |
|
|
|
Just throwing out an idea here as well... it's quite unpolished, as I came up with it a couple of minutes ago... Would a "tax" on old Max rewards be some sort of compromise? I'm thinking of some sort of system that moves accumulated unpaid PPS during longer streaks of bad luck and pays it forward to the the current round... let's say that with two rounds it proceeds as normal, but when the pool goes into the third bad block it starts taking a percentage of the unpaid shares from the first round and adds those to the current round, and if there's a fourth bad round it takes a cut from both round one and two and so on. That way, the unpaid PPS from those who jump to another pool would gradually be shifted over to those who continue mining. |
|
|
|
|
You're not getting any games. It's all a Jedi mind trick! Anyone with a Yoda avatar can do it...
Seriously, though... the fact that no one has considered the possibility that the seller here might work in retail and can get keys the same way g2play and other sites get theirs makes one wonder about how ignorant people are about how things work. It's not like you have to be some sort of demigod in direct descent to the Ancient Lord Wholesale to be part of that...
|
|
|
|
|
I had one miner failing to connect intermittently and realized that one was connected to mining.eligius.st, while the other machine has been pointed to s3.mining.etc... since the change from EU server. So, I pointed the first one to that address as well, and I haven't noticed any connection problems since then.
If it has anything to do with the local connections or the redirection on the server end is beyond me, though.
|
|
|
|
|
How are balances on S3 planned to be paid out, by the way? Fitting previous overhead back into generation payments would work in a theoretical world of perfect averages, but I don't think reality will be that kind to theory.
Personally I have enough bitcoin that I don't have to worry if I get my mining rewards back in the next block or next month, so it doesn't bother me much that several blocks have passed since my reward passed the threshold and that I now have several times that amount outstanding, but I think many will be more comfortable with having a somewhat more defined (or at least less obscure) payment schedule.
|
|
|
|
|
Instead of changing the ticket price I think you would get more players if you had more than just the jackpot to a single winner. Something like a grand prize of 50% to one winner, five winners who get to split 25% and the last quarter of the pot to 25 more players. I'm sure that with a distribution like that you'd get enough players to keep the grand prize at least as large as in the current round.
|
|
|
|
So maybe "maximum reward" is the amount of BTC we will be awarded in the future, if the pool has a few lucky rounds?
Yes Isn't it the opposite... the pool had lucky rounds before, and the maximum reward is the amount you get back from the overhead if the current round ends right now? Edit: I got that backwards. I blame it on just having gotten out of bed with a fever...  Anyway, even though the pool stats won't admit it yet, it seems that a block was produced, and that outstanding EU payments are included: http://blockexplorer.com/b/134863 (4 confirmations atm) |
|
|
|
|
Came to think of something, when it comes to new pools and old ones changing things around...
Why not give each pool its own config file, and collect them all in a folder? That would make it a bit like a plug-in system, so that pools can supply their own configuration files when they change addresses and add servers, as well as letting new pools get their details into the GUI without waiting for the next update.
|
|
|
|
|
It sounds like the EU payments are set up to be sent as transactions, like happened with the outstanding US balance.
|
|
|
|
Selling vanity addresses would be useless. I wouldn't trust the seller not to keep a copy of the corresponding key.
It could be done. Offering them as a premium option with an eWallet service would be one example, and that wouldn't require more trust than such things already do. |
|
|
|
You get pretty nifty stats (when they are working). Here's a screenshot I had for the hashrate graph for two miners on the somewhat cranky EU pool:  You can't see individual stats for each worker unless you give each its own address (which might cause you to get spammed with small transactions once they come over the threshold), but otherwise I think Artefact2 has built one of the most detailed stats pages of any pool. |
|
|
|
|
I was mostly implying that a combination of a dictionary file and a fair amount of processing time must have been involved in generating those results. I guess it's a business idea of some sort.
|
|
|
|
|
I was trying to set up a backup for an Eligius miner, which I have to define manually with port 8337, and when it tries to connect to the backup it tries to reach backup-pool.com:8332:8337.
Scratch that. It works now. Probably left something I shouldn't when I shortened the address after using cut and paste from the console to look it up after starting a miner configured for the backup pool...
|
|
|
|
what's the advantage of having a default affinity for cpu 0?
Mining multiple GPUs mostly causes a lot of CPU use, so forcing all miners to the use same core keeps the total CPU load down. |
|
|
|
|
I seem to fail at using a pool with different port as backup for an "other" pool. It appends the port specified in the field, and leaving that blank makes poclbm refuse to start so it doesn't help adding the port for the main pool in the address field.
|
|
|
|
|
Show Posts
