rKvZQtNbLozU7wYf15sjSdeqonbci5Kgv1

Jine,

Do you have the statistics available (and the time of course) to generate some comparisons of payout methods using real historical data from the pool?  Per user would be great (I'd like to see if I would have made more or less with my miners since joining the pool) but a lot of work I'm sure.  Even some "this is a typical full-time miner of X mh/s, this is a typical part-time non-hopper user, and this is a typical hopper" over the last 365 days would be very helpful.  If you could also show what payouts would have been without the hoppers in the pool for everyone else that would be even better.  My suspicion is without factoring out the hoppers being in the pool, merely adjusting their payouts to the tested method along with everyone else, the amount of payout I'd have received would be roughly the same.  If you can in fact "remove" them from the pool for the statistics, I'd be curious to see if they really do hit regular users for up to 20% as is being claimed, or if the reduction in found blocks due to loss of hash power will offset some or all of that loss.

At the end of the day, I don't care if I make (obviously exaggerated) 20% of 50 BTC found or 10% of 100 BTC found in the same period of time, the payout to me is the same, 10 BTC, for the same amount of work I contributed.  I don't care about hoppers unless they're reducing that number either by taking an unfair portion, or if they're causing undue delay or downtime on the pool.  It sounds like that is happening, but as they say, "the proof is in the pudding."

Thanks Jim!

Jeremy

Well I'd voted for keeping it as-is before learning that hopping-pools are actually causing undue stress on the system and/or operators.  Unfortunately you can't go back and change a vote, so please disregard one of the proportional votes.  I think the best way to choose is to compare and contrast what the various methods actually mean to the pool and its members.

DGM - I haven't gone and looked up how the calculation is actually done, but on the surface it sounds a bit complicated.  The pool absorbing some of the fee from shorter rounds and paying it out on the longer rounds seems to add a bit of accounting overhead.  I would think there'd be risk of pool members accusing the pool of trickery if they don't understand precisely how it works.  Unfounded negative publicity would be a very bad thing considering how paranoid some bitcoin users are to begin with.  Wouldn't this also expose the pool to risk that a large number of subsequent long rounds causing the pool to constantly pay out without any income to compensate for it?  Long term this should average out, but the pool would need enough capital to survive shorter-term ruts.
PPLNS - This is a very transparent methodology, and is simple to calculate.  The negative here is the shares become completely worthless over time.  I think many users that only mine part-time (not hoppers, but those that mine when not gaming, etc...) would tend to not like this method for the same reason hoppers don't.  This is a non-issue for those of us who mine 24/7 since we're constantly replacing the shares that roll off with new shares.
PPS - I wouldn't even consider this for the pool.  Right now BitLC is built on being a fair pool, not charging fees to the miners, and being open and transparent.  Switching to PPS would cause undue risk to you as the pool operator, and/or would require the pool to charge fees.  The first is not fair to you, and the second goes against the philosophy of the pool (at least how I perceive it as a pool member.)
Score - This may be the best choice, since it eliminates the "worthless" share issue with PPLNS.  A part-time miner still gets "something" if they stop mining during a round.  It would ease their minds getting a miniscule "token" amount for the work put in.  Hoppers would still get paid some too, but they're in it for the quick reward and the token payment they receive should not be enough to have them view this pool as a valid target.

For full-time 24/7 miners the payout method really means nothing in the long haul; it all averages out.  The change in payout method needs to be used as a method to attract part-time individual miners that come and go based on individual PC habits, but not give enough advantage to make it a viable pool for hopping purposes.  Score-based payout is probably a good balance and would be my first choice, but if you wanted to follow the KISS principal, PPLNS is the way to go, and I'd consider that my second choice.

No matter what you decide, thank you Jim for all of the hard work you put into running the pool.  I know it isn't easy, and to do what you do without charging fees is saying a lot.

Jeremy

Many of us have discussed this at length, including you and I, in the past on IRC.  The biggest reason to switch was in order to discourage pool hoppers from leaving the pool.  After much discussion it was (I thought) decided that pool hopping doesn't actually hurt the pool or the workers in it.  Yes they reduce the payout for all of the shares since there are more of them, but they contribute to more frequent blocks so it all comes out in a wash.  It has been quite a while since I've participated in any discussions, so if the overall consensus has changed, then I digress.

To me determining why is it time to change the payout method affects the preferred method.  If it is "just because" then my vote is to leave it as-is.  "If it ain't broke, don't fix it."  If there is a reason other than an (arguably) irrational fear of pool hopping, choosing a method that best answers to that reason is the way to go.  Is it because the risk is unbalanced between the pool and the workers, then choose the method that shares that risk in the most fair manner.  Is it because there is too much confusion on how proportional payouts work?  Then choose the method that is easier to understand (is there one?)  Is it because proportional is too much load on the servers to calculate payout?  Choose the method with the least load to complete the payout calculations.

In the long run, assuming any fees/charged by the pool are reasonable, it all works out the same for people who have workers that sit and stay in the pool, and payout calculation method really doesn't matter.

Just my 2 bitcents worth.

Jeremy

Same here.  Read here for a long time without even registering, finally registered a month or so back, but never had need to post.  Now when I want to post in a thread (or PM someone) I find out I can't until I make some postings.  This is number 5, so once I've been logged in for another 2 hours I should be golden.

Hence the reason I said to put a TrueCrypt container there, even if someone gets it it won't be useful as long as secure passwords are used.  Nothing is 100% secure of course, but that should be sufficient for most all cases.  If you're really paranoid, use GPG to encrypt the truecrypt volume before uploading it, of course you still have to keep safe backup copies of said GPG key.

Also you don't need to open your savings wallet when you transfer BTC into it.  Just send the coins to one of the addresses you've generated for it.  Since the transaction is pushed into the block chain it is done, regardless of whether the client is active or not.  You could send hundreds of coins to your savings wallet and not check it for months.  Once you do open it, it will download the block chain, and all of the transactions will show up.

As others have said, make sure you have multiple copies of your saving wallet on several forms of media, and in several physically separated locations.  Maybe even put a TrueCrypt container file containing your savings.wallet.dat on Dropbox or some similar service.

Not much here, about 60 Mh/s on a GTX460, but it is something.

Name is Jeremy, I've been playing with BTC since July of '10.  Ran mining using the BTC client for a while at first, but it never came up with anything.  Kind of lost interest due to not much going on with it, and got back into it a couple of months back, and I just started GPU mining this week.