Must just be variance. How many shares have you found? Remember, the pool doesn't receive 50% of the payout, it receives randomly over time 50% of the shares. So the number of the shares the fee has in the sharechain can vary quite a bit. There is a literal random() call with the fee % to see who owns each share your node finds.

Hard coding in a fee amount to the sharechain like how donations work would be a really nice feature and easy to add. But not backwards compatible, so it'd have to be one of those things that only kick in once 95% of the network has upgraded. Then the variance is gone for both operator and miner in regards to node fee.

It isn't intuitive, but each share a miner submits to you has a 1% chance of becoming your share instead. So you'll see a lot of variance in your pool fee income, but long-term it should even out (at the expense of higher variance for the miner as well).

Maybe one day p2pool will allow the fee amount to be recorded in the share, like the donation amount is, so it can be paid exactly when each share is paid and all shares remain with the miner.

It'd be sweet if someone does that eventually. Could bring Prime closer to using normal pools.

It's possible the pool hash rate was moving around a lot that day though. The share difficulty needs to adjust quickly as the network hash rate changes. Since starting my graph 3 hours ago, the non-stale hash rate has been reported from 89T-139T.

I wonder how much of that is actual changes in the makeup of the pool, and how much is variation in the reporting even with no real change in who is mining.

Hiya lenny. Yeah been running this pool for about 8 months. Has been fun. I thought about making a more fancy interface, but I remember some people in the bitparking thread saying they go there because of the simple web site and they don't want the complexity some of the other pools provided on their front ends. Since bitparking has a very simple page as well and is successful in the BTC world, I figured I'd keep things minimalistic on my TRC pool.

Basically I wanted to try making a pool but it seemed impossible to succeed with a new BTC pool. Coinotron had suspended TRC for a while, so I figured I'd set up a TRC pool. My main goals were to use in-coinbase payments like Eligius, keep it all very simple like bitparking, and use the most robust payment method (DGM). Took a few weeks of coding to bring it all together.

The front end stuff is all custom, but the backend runs fireduck's sockthing which is in github. Was the same software he used for HHTT. All of the customization for DGM coinbase payment/etc have been submited as a github branch.

The luck page I worked with organofcorti on, it's quite cool I think:

http://www.royalminingco.com/luck.php

(After blocks are found it gets remade when loaded, so it might time out. If so, try it again a few minutes later. I really should automate that and only serve a non-dynamic version to visitors.)

If you click on a miner's address, you get a historical hate rate graph and some other gabs of info. Some of those tabs are slow to load.

I could do to spend time TLC time to optimize some of that and clean it up some. Recently all of my coin-related time has been spent learning how p2pool works and pondering ways to set up a useful public BTC node for people who can't/won't run a node of their own. I'm temporarily running two VRT (Vertcoin) p2pool public nodes so I have a testbed.

Since I can't find what I was looking for... I made it myself!

http://vtc-us-east.royalminingco.com/p2pool_share_history/diff_history.png

That image will be updated automatically once per minute, plotting share difficulty vs pool non-stale hash rate. Looking over the share chain by hand I couldn't see the difficulty jumping around all that much, so this will at least give us a clear 24 hour picture once it has been running for a full day.

I assume you aren't confusing the share difficulty to find valid shares with the vardiff difficulty sent to your miner on what work to report back for stat purposes.

Edit: Of course, the target difficulty does increase above the share difficulty for miners who are large enough to be generating over 1.67% of the whole share chain (or if people elect to). But as a smaller miner, that doesn't apply in your case. You just need to find the normal minimum difficulty to get a share into the chain.

FYI if you are mining BTC, the PPLNS window is 3 days now since the block retarget time was moved to 30 seconds from 10 seconds but the share chain length left alone. Should smooth things out a bit more for people, hopefully.

Is there a site someplace with a historical graph of the p2pool share chain difficulty? Google has failed me on this one. I'm curious how much the difficulty on the share chain actually moves around.

(A number of alt coins seem to have having success with the Kimoto Gravity Well difficulty algorithm. I don't know the specifics myself, but it changes difficulty each block like XPM/PPC do.)

Edit: Manually clicking through the share chain I see the minimum difficulty changes each share already. I'm curious what the graph looks like though, since kano mentioned it various highly. So far, the biggest single share difficulty adjustment I can find is about 1% of the prior value.

I use coinbase, which is super convenient and direct bank transfer, there's no costs expect whatever coinbase's exchange rate is vs other exchanges. But because I don't have a Visa credit card (all of mine are Mastercard), I can't get approved for instant purchasing. :/

I've decided to wade into the pool. Will be ordering as soon as my BTC purchase clears next week.

I'm not disagreeing with you. But one thing to remember is the PPLNS window in p2pool is currently 3 days since the move to a 30 second retarget time. So the daily variance in your # of shares is softened, since your payments are tied to the variance in your total # of shares over 3 days instead.


When I read the last 5 months of posts the other day I saw some discussions you had on the difficulty and large miners having increased difficulty to reduce the total # of shares they have in the sharechain. Edit: Was back around December. I thought there were 2-3 excellent replies that clarified it all for you, but I guess you didn't accept their explanations?


Yes, if p2pool is dropping 150GH miners like flies that's a serious problem. A single GPU miner somewhere can just not be worried about. When I hear "small miner"  I think someone who has an expected share rate below 1 a day, so at times they will not even be in the share chain and receive no payments. I wouldn't think, myself, that a miner with an average 18 shares on the chain is 'small'.

Please don't join the single largest pool already on the network. There are many, good, smaller pools. And if they are paying fairly for the work you do, then the pool you are on shouldn't have any effect on your expected net returns, only your variance. Or you could set up a p2pool node and not use an external pool at all.

Any idea why that is?

Had a nice conversation on irc about multiple payment address support in the share chain, and I can see why that might not be a good thing to support in a generalized way.

However I do want to suggest that the node fee be handled like donation with a special line in the share chain. It would only add 1 address to the share chain per share mined at a node with a fee, but the advantage is a node can't lie about the fee they are charging, and it reduces node and miner variance.

I've seen a few. None that are like official public "download here" interfaces that I know of. For example here are a couple variations:

http://p2pool.etyd.org:9171/static/ (comes from http://sleipnir.syari.net/pool/)
http://q30.qhor.net:9171/static/


Edit: Found another one, with source.

https://github.com/johndoe75/p2pool-node-status

as used on:

http://bitcoin.p2pool.fr:9332/static/

Edit: Apparently the default extended inteface has some bugs, fixed by this version: https://github.com/blixnood/P2PoolExtendedFrontEnd

Check out bitparking.

To add support for multiple address shares, it'd basically be converting share_data.payout_addrress to a list (of addresses and amounts) and reflecting it correctly in block.gentx.coinbase as well. At least from my quick glance at the code so far. Does this sound right? Then of course handling the payout_address list properly in all spots.

There wouldn't seem to be a way to make this compatible with older nodes, so it'd have to be one of those features that doesn't activate until 95% of the nodes are on the minimum version that supports it.

The diff adjustment should have no effect on your hash rate. If it impacted the global hash rate, that'd be from miners who didn't upgrade their wallets being forked off into an invalid blockchain.

I looked it up, it is random. I play a card game where packs have a 1% chance of giving you a better card so I'm quite familiar with how much variance that can result in. So it's possible you might find 200-300 shares with no operator fee, or sometimes the node will find 100 shares and pay the node much more than 1%.

I wonder how difficulty it'd be for p2pool to support shares with multiple payment addresses. As I mentioned in an earlier way too long post, that could be used to both help address the variance of smaller miners and pay the operator exactly 1% of the shares found with less variance to the miners or the node operator.

It's possible it's random, I don't know having not looked at the source code. So it might be every share has a 1% chance to go to the pool, or it might be every 100th share.