I, for one, am glad you made this point and found it quite interesting. As it turns out, my Masters thesis in Computer Science was also somewhat related to machine learning (summary, I used a naive Bayes classifier and some other tools to increase the click-through rate of ads on a web site). I suspect yours was far heavier on the math, though. (My Bachelors's was also in C.S. with a minor in mathematics, but that feels so long ago.) I left the computer industry in 2001-2002 after the dot com implosion, but my hobbyist interest remains, likely for life.

I'm thankful for your contributions to the community and to mining pool compensation analysis.

TLDR: If you jump down to Edit #2, I figured it out.


This is giving me values about half of the actual amount paid in the blocks. To use some real numbers on one specific block, here is my amount paid out formula. I am re-scaling $s to 1 every share. So it is $s=$s*$r in the figures below.


If I also calculate the estimated payout for the next block at the same time, I get (leaving out /s since I re-scale to 1 constantly.)


For S=12.932020560171, r=1.0000315757467, c=.03, f=0.0, o=.97, p=3.2552316167526E-5, s=1.0000315757467. The estimated equation reduces to 12.932020560171 * 0.4923857868 which is why it's about half. (With re-scaling every share, the payouts are extremely similar to the actual score value itself.)

I think I have the math coded properly. So either I misunderstand what "expected payout for next block" means or I have a blatant bug in how I'm coding the formula. Assuming formula is correct.

(To try and get a handle on how DGM operates, I'm using my share database to recreate "what would have happened" with DGM from start to finish. Since I'm only doing private testing, my test data is limited with about a week of mining and 3 blocks found, on an alt coin. Maybe the sample size is too small. 99K shares recorded with average block difficulty 36K, the block difficulty changes every block.)

Edit: Just occurred to me. Is the expected payout for next block given above if the miner stopped mining? So on average, D shares from now the payout to the miner would of course be much lower than the numbers I'm seeing (since the miner in my data sample kept mining away).

Edit #2: Yes that's it. I should have worked on it more before posting. Sorry for all the noise. It's spot on.

I injected an extra 41000 shares of work on a 41000 difficulty block into my database, and then injected a new "found share".

Before these changes, up to the final point in time for a worker (not the one listed above):
"Expected remaining total payout 6.1845766103505, next block pays 3.0451976203249"

After my artificial data injection,

Block Found: (score 3.1393789900256) pays out: 3.0451255771104

Nailed it within .00008. And I bet that's because there actually were a few thousand shares in the database after the last real block I left alone (so it was a slightly long round I created). So if someone stops mining, I can tell them their expected remaining total payout and their expected payout in the next block too. Awesome.

Just need one legitimate forex provider to start trading BTC and all of the other exchanges can go away.

I think maybe I was paranoid about changing values in the database somehow making it unstable. Given your answer below, I'm thinking if a miner hasn't mined for a bit of time (to not trim brand new low hash rate miners) then do a single manual payout if S/s gets too low, and delete them from database completely.


*bonks self on head*. Thanks.

Also try raising the difficulty at the pool you are mining at, but really you shouldn't need to send a lot of traffic back and forth. I assume you are using a modern miner like cgminer/bfgminer with stratum which will generate local work instead of asking the server for new work constantly.

You can't change the fee after the fact so far as I know, so I think you just have to wait for some pool somewhere to get your feeless transaction into a block. Eventually.

I was going to use logs so I didn't need to rescale, but it occurred to me that if I rescale every share I don't need to store s. Since s=s*r and s is always 1 going into the share, s is now always r. Thus, the payout becomes (S(r-1)(1-f))/(pr).

I guess the question is, do I really want to divide every score by r every share (updating hundreds of rows if there are hundreds of workers) vs storing s and using logs. It'd seem logs would be less impact to the database.

Edit: Final question for now. Is there a formula to calculate the total expected future payouts for a miner if they stop mining? That is, given the current state of things like s, r, p, B, and their score, can you approximate "if you stop mining right now the sum of all of your future payments is expected to be X". Basically, the value of their capacitor discharging from the current state down to zero. I think miners might find that useful (in addition to expected payout on next block from S/s), so they have a sort of idea of the long-term trailing reward that offsets the slow startup as the capacitor charged.

Thanks.

I love this graph. However, it doesn't work right in Chrome btw, MSIE is needed. Also, if you added CGM and CPPSRB one day that'd be epic.

Looks like TRC web interface is back up, just a few hundred blocks behind. Yay!

I think I'll just take your word for it and run with it. As they said in Star Trek II, "Yours is the superior intellect."

There's always Amazon EC if you are a do it yourself person.

Don't know who it was, but someone says in their signature all of their BTC farming is solar powered.

What I'm struggling with getting my mind around is that work done before the orphan are at S*o and work done after the orphan is at S. When the orphan goes away and the payment is cancelled, aren't shares after the orphan worth more than the shares before it improperly? (If the orphan never happened and scores were never updated, then all work since last block (before or after the orphan that never happened) are all at S.)

I'm hoping you are indeed correct, since being able to ignore the score changes from the orphan event would be so easy. And you are normally correct.


Dust is an issue for everyone eventually I think (if I'm understanding correctly) since there's no 0-1 cutoff. We are going down by S=S*o every payout the scores for a miner who stops mining will approach zero but never actually get there, they will just have ever decreasing scores. (Eventually so low it's just dust, forever?)

Same problem here, but I get it with 32 or 64 bit versions.

Googling the error it's a standard SSL error response. Some solutions for other applications:

http://curl.haxx.se/docs/sslcerts.html

http://stackoverflow.com/questions/14566864/peer-certificate-cannot-be-authenticated-with-known-ca-certificates-how-to-reso

Verbose output:


Tried the ENV variables from this:

http://stackoverflow.com/questions/14286265/how-to-use-ssl-cert-file-for-openssl-windows-openssl-1-0-1c

with no luck. Also set PATH to the directory the .pem file is in. I'm betting Windows 8 is part of the problem since the earlier guy uses it also.

Two implementation questions, if you have ever thought about this.

For miners that have a very small payout due, it's best to not pay them at this time and rather let their payout grow higher first. Otherwise they collect too much "dust" and when they try to go spend those coins, the transfer fees eat it all up (or cost more than the inputs, making the dust useless). Is handling this as easy as skipping their payment and leaving their score alone?

I realize even with f=0 future blocks may have more rewards to pay than the block contains. The other alternative is I could "pay" it to a separate dust database (keep the coins for a pool "dust reserve") then once the dust has gotten big enough do a payout from pool funds. Then the DGM scoring system/database isn't effected and knows nothing about it.

If you are paying miners in the coinbase of the block found, you can't wait for confirmation of the block to adjust their scores (or you might pay them multiple times if you find multiple blocks in a row). In a *PPS system you mark the found block as a "payout" for the relevant shares, and if that block later becomes an orphan you mark those share back to unpaid. Piece of cake, conceptually. In DGM, is the way to handle this to go through everyone paid in that block and set S=S/o? The payout in effect never happened, and the only change in database before was S=S*o. Seems simple, but wanted to know if you agreed.

Thanks!

So instead of a PPLNS pool with a fixed 3% (f=.03) fee, one could run DGM with f=0, c=.03, o=.97 to have a similar pool with average fee to operator of 3%, but less variance for the miners because the operator is taking on that variance.

I didn't see it explicit in the OP, but does o need to equal 1-c?

I skimmed back over the thread, I thought I saw this discussed before but missed it just now if so, but if you are adjusting the parameters per-miner are there any specific constraints that must be observed? I'm specifically thinking of pools where the fee is based on the difficulty you are mining at. So as the user selectable difficulty rises, the pool's fee for that miner goes down. I wasn't sure if multiple miners all with f=0 but a variable c (and o=1-c?) would pose a problem.

Did you ever write this up someplace?

In any case where f>=0, the operator will not be paying out of his own funds, is that accurate? I think I was misunderstanding "operator variance" as meaning the operator may be paying money out of his own funds like PPS in long rounds. Which I'm not willing to do. However, if it is simply variance in how much the operator earns without ever going negative, that's a totally different situation. I wouldn't mind my earnings (as an operator) going all over the place as long as the pool cannot ever go bankrupt in terms of payouts to miners like PPS.

When a reward drop is coming up, like when Bitcoin went from 50 to 25, the shares submitted before the drop would be earning twice the reward as the shares after the drop if you store credit by current potential reward at the time of submission instead of the actual reward at the time a block is found. Is that that intentional? In a pure PPS model, that's how it'd have worked of course. But in a pay-once PPNLS model you can only pay back as many shares as you actually received from the found block. So if the D shares up to the reward drop didn't find a block, then D+1 finds a block with half the reward, you're only going to be able to pay the most recent D/2 shares. It seems a bit counter intuitive to me, I'd think the last D shares would all get paid on the actual block (half reward than if we found the block sooner, but it is what it is, you can only pay out what the pool receives).

I guess the same applies long-term with transaction fee based blocks, although then the reward would be going up and down from block to block.

For pay-once, does it just boil down to this then:

1- Knowing exactly what you are earning (share of potential reward+fees for current block, the reward you earned never changes between now and when you get paid) but not knowing how long until you get paid (if reward drops, your time until getting paid increases if your shares weren't recent enough)

OR

2- Knowing a better idea when you get paid (based on average time to solve blocks regardless of varying reward) but not knowing how much you'll earn (reward+transaction fees of the block actually found in the future).

As far as I understand things currently, most PPS models (should, if coded to use reward at time of share) fall under #1. Pay-Once-PPLNS using block rewards at time shares are submitted would also fall under #1. Proportional would fall under #2.

Ah okay, excellent. The initial pool I'm setting up is for TRC where the difficulty changes with each block. I store in my shares database d (user selected difficulty) and D (difficulty of the block you just submitted a share for) but do all of the payment logic based on sum(d/D for each share submitted individually, ie: D will vary over time) in LIFO (most recent) order. I mark shares if paid and then ignore them moving forward (stored for graphing and historical record).

The only thing I'm not doing is storing the reward based on B at the time you submit a share. I was only storing "You have earned sum(d/D) blocks" and then pay it out when a block is found based on the reward of the block found, not the reward at the time of submission. Which is exactly what you said not to do. I'll need to look at that.