Maybe he was too subtle, but that's the joke he was making.

For anyone mining on public p2pool nodes, I updated the interface on my US-East node to have a miner-specific graph and some miner-specific stats if you click your address on the miner list on bottom. Want to expand that miner page quite a bit moving forward.

You only need to add / or + settings if there is a specific issue you are trying to solve. If you are running your own p2pool node you shouldn't need to do anything besides just connect and mine. If you are mining on a busy public node, default p2pool will raise the pseudo share and real share difficulty targets based on the node speed (not your personal speed). You can use a low + if you need more pseudo shares to make your graphs look better, or use / to set a lower speed if you aren't finding enough shares and don't mind potentially smaller ("dust") payouts.

Start with no special settings at all and see how that goes for a day or two, would be my advice. Or run your own local copy of p2pool.

Hi Cart! You can review it here

https://github.com/forrestv/p2pool/pull/187

However there's nothing wrong with my original little fix if you don't want the auto-worker-diff options that iongchun added.

This is lower level than I understand, but maybe you can learn something helpful from:

https://github.com/dogestreet/proxypool

I've sent in pull requests already and also for iongchun's auto-worker-diff branch which lets you have nice control over pseudo share difficulty. (This was better than my own little hack for pseudo shares so I dropped mine and use his myself.) iongchun also added an alt coin related fix for DIFF 0 work so I removed my pull request for that, since auto-worker-diff is all inclusive. My share difficulty change (branch vardiffbyaddress) was adopted by vertcoin p2pool repo when we did the hard fork long ago, so it's actually live network wide for them.

I still have more changes to the vardiff algorithm I want to test and such so my node will always run whatever experiment I'm doing at the time.

For the worker 'time to share' type stuff, I put in pull requests to p2pool for the minerstats branch and to p2pool-node-status as well.

There are merge minable scrypt coins but I don't believe any of them have real value. Namecoin seems the only one that is worth something.

Yes it's been discussed to death already in the Eligius support thread.

I've gotta say an average share time of 5h40m hours compared to 1d8h block times (at the time I post) is better than I expected. At 6 shares per block found, and a SPREAD of 3, I'd average 18 shares at any given time once I've been mining for a few days. That'll drop if the pool hash rate grows, but atm, ~18 average blocks seems like plenty to make sure I'm paid on every block and my payments don't vary wildly. I'll need to actually see it in action first hand a few weeks, but personally I don't feel that is unacceptable variance at all.

It'll be nice if/when I can get some sort of miner-specific graph page up to plot this stuff over time and let you see visually at a glance your projected and real share values.

I've gone ahead and set up a public node for BTC to go along with my other couple coins.

http://us-east.royalminingco.com:9332/static/

The fee is .5% to pool and .5% donation to forrestv. This node has my patches related to helping small miners get less variance, and uses the interface which shows average "time to share" per-miner so you can see what's going on. Pseudo share vardiff is also set reasonably per miner so no ADDR+ tweaks are needed just for graph purposes. Next I want to fold in iongchun's miner-specific stats page, and add some extra charts/history/info to that.

It isn't like the world needs more public p2pool nodes, but I wanted to have at least one that I knew was using the changes I worked on for the alt coin pools.

Last step should read

sudo apt-get install rtorrent

Is this the same torrent the official web site links at https://bitcoin.org/bin/blockchain/bootstrap.dat.torrent ?

Do you go to irc at all? Find me on #p2pool-vtc or #p2pool and I can try to help debug a bit if you want. I have two nodes in my signature. us-east is the better one.

Pseudo share size has nothing to do with share difficulty on the pool or payouts. Those are the little Accept X/Y your miner prints every few seconds or so. It just lets the pool know you are alive and plot graphs, etc. To actually get paid you need to submit a share where the difficulty is higher than the minimum share difficulty for the pool (or higher than your share difficulty target if it's higher than the minimum).

To get more or less pseudo shares you use +. For instance, if you run a local node you could spam it with tiny shares by adding +1 to your payment address. Has no effect on income.

To get more or less real shares you use /. Any /DIFF set below the network minimum is ignored, and your target diff to get on share chain is the minimum. Any /DIFF higher than the network minimum means you'll get on the share chain less often, but the shares are more valuable (your target share difficulty is the value stored to calculate your payout, all shares on share chain do not have equal value, maybe this is your confusion?). The maximum target diff you can set is 30x the network minimum. If you set it higher, it'll adjust every time the minimum target adjusts.


In a normal PPLNS pool, the payment window is all of the shares of work submitted (what p2pool calls pseudo shares), and there is only one type of share. All work submitted is logged and is in the payment window for a certain amount of work N. N is usually some multiple of the coin's difficulty.

In p2pool, the shares a normal pool would count are ignored and only shares of a certain difficulty target are counted. This is because there's no central database to record all of the info. We're decentralized and nodes can't trust each other. So the payment database, instead of being MySQL or similar, becomes a bitcoin style block chain, we call it the share chain. The share chain contents are the PPLNS payment database for p2pool. It has a specific target speed just like bitcoin. The share chain target is 30 seconds. The minimum difficulty to get a share onto the share chain is adjusted similar to bitcoin's difficulty algorithm, so the share chain grows by one share (block) every 30 seconds.

So the minimum difficulty for shares to get on the share chain is soley a factor of time. How long is it taking to add shares to the share chain? Just like bitcoin itself, the diff adjusts so the target rate is hit. The contents of the shares on the share chain don't matter.

(Side note: It's endlessly confusing that "share" might be a pseudo share, a real paying share that is recorded on share chain, or a "block" on the p2pool sharechain.)

So your question above, if you are talking about pseudo shares, it doesn't matter.

The issue is that the share chain has a finite number of "shares" (blocks) available. When it's full the older ones are expired. Even if the luck has been bad pool hash rate has dropped to where we aren't finding N work before the share chain length maximum is hit, opposed to the PPLNS window on a normal pool would still be counting those shares. This is a separate issue/concern of mine.

To even get on the share chain at all, you need to find a share (in your client) with a difficulty that is higher than your target share difficulty. I'll give an example below.


Yes, and this is exactly how bitcoin works as well. Difficulty is set based on actual shares found. Real hash rate doesn't matter, it's only the observed hash rate from actual found blocks that changes the difficulty target.

So why bother with /DIFF and using a higher one than you need to? Take a small coin with a p2pool share chain target of 1 minute, and two miners:

If Miner A has speed S and miner B has speed 99*S and are both mining on the p2pool node with the same difficulty targets (for simplicity ignore there being a vardiff, say both miners use /1, and the minimum share diff is a tiny number like on a scrypt coin) then A will find 1 out of every 100 shares and B will find 99 out of every 100 shares in some period of time. We want to find one share per minute for the share chain, so the minimum network difficulty will adjust so that shares come in once a minute. Thus, miner A finds 1 share every 100 minutes and miner B finds 99 shares every 100 minutes. As the p2pool network speed (or just miner B's speed) grows, miner A's rate of finding shares will get slower and slower. These shares all have a value of "1" for our example.

If a paying block is found when we have these 100 shares in the share chain:
Miner A is paid 1 * 1 / 100 of the block reward = 1%
Miner B is paid 99 * 1 / 100 of the block reward = 99%

(The math is # of shares * value of shares / total share chain value, assuming each of a miner's shares have same value, it's actually a sum of each individual share value in practice.)

Now let's say miner B feels bad for miner A and wants to help reduce his variance on when he gets paid. So whereas miner A might be mining diff 1 shares, miner B is going to change over to ADDR/99 to mine diff 99 shares. There is a 30x cap, so p2pool will actually make /30 the maximum it will use.

Now, in a specific period of time, miner A will find S shares  and miner B will find 3.3*S shares (since his diff target is 30 times higher vs his 99x faster speed). With the network difficulty from up above, A is still finding 1 share every 100 minutes but now B is only finding 3.3 shares every 100 minutes instead of slightly less than 1 per minute. This means the share chain is way too slow. Network minimum difficulty will drop until both miners combined average 1 share per minute. Once adjusted, in this 100 minutes of much lower minimum difficulty, miner A will find about 23.25 shares for every 76.75 shares miner B finds (please pretend we can have fractional shares to make the math clean).

The advantage is that miner A now finds shares on the share chain every 4.3 minutes (100/23.25) instead of one every 100 minutes. You can see that's a massive drop in his wait time. Miner B only goes up to about 1.3 minutes per paying share. What happens to the payouts?

The total value of shares on the share chain are 23.25 * 1 + 76.75 * 30 = 2325.75

Miner A is paid 23.25 * 1 / 2325.75 of the block reward = 1%
Miner B is paid 76.75 * 30 / 2325.75 of the block reward = 99%

So the end result is that Miner B can increase his time per share from 1.01 minutes to 1.3 minutes in order to let Miner A drop his time per share from about 100 minutes to 4.3 minutes. The miners still make the same average income over time.

You can imagine how big this effect becomes between a large mining farm and a single 180GH Antminer S1 miner.

TLDR: Sorry.

You don't initiate withdrawals, payments are made when blocks are found. If your balance is above the minimum then you get paid once your shares are in the front of the queue. If your coins are already above the minimum you don't need to do anything, payments are automatic.

So a followup to my earlier questions. From IRC forrestv mentioned the 30x cap is a hard coded limit that other nodes will enforce, so I can't raise it on my own node without the other nodes rejecting my shares. Also, the dust threshold works so that each share you find will be above the dust threshold, not based on the average actual payout you'll receive based on average # of shares in chain.

I'm talking about using / which adjusts actual share difficulty to find shares on the sharechain, not + which are the pseudo shares. It does have a rather huge impact on small networks. If I go the opposite way and mine with /1 so I'm always at the minimum, I can skyrocket the minimum share difficulty for the network. Noticing my impact on it when I first set the node up is what prompted me to always max out when I join in.

So I was working on one of my nodes this evening. I noticed the share targets were massively too high on my Uno node. Turns out dust threshold was set too high for a coin with a (currently) .25 block reward. I tweaked that around some so it was working better, and noticed some other things. This is my node:

http://us-east.royalminingco.com:9655/static/

I'm mining with about 1/4 of the pool power, I have my diff set to /64000 to help keep minimum diff low for smaller miners. The smaller guys on there at the moment as I post, from my debugging related to the dust issue, have their share targets set to hit a share every 30 minutes. I've seen from other alt coins that the networks.py settings basically end up where miners all get set (if they have the hash power to avoid dust issues) to the same time per share. I've never researched what formula feeds that yet though.

With the 30x diff cap, my target drops to a small fraction of the /64000. I'm finding, at the moment, 1 share per 1.5 minutes. The pool will find a block once per hour. So I'll have about 40 shares in the time we find a block. The other guys will have about 2 shares.

I'm wondering a couple things. Is there any problems if I just up or remove the 30x cap on my node? I honestly wouldn't mind averaging 2-3 shares per block like the other smaller miners, which would reduce the minimum share diff even further. In fact, if I remove the cap totally, I bet the vardiff would target me to 30 minutes per share just like the other 2 miners, meaning I'd be about 20x higher diff target than I am right now (which is 30x cap, so about 600x the minimum difficulty). I'm curious why that cap was put into place originally.

Also, when the expected value is generated for the dust calculations, is that based on the expected value of a single share or the expected value of the average # of shares a miners will have at any given time in the share chain? I assume the latter, just want to be sure without reverse engineering how the math is calculated in that function.

The 2nd post up above seems pretty clear?

https://bitcointalk.org/index.php?topic=332072.msg3576160#msg3576160

That does seem pretty high but when randomness is involved sometimes you'll have those super long waits and other times find 2 within a few seconds of each other. I show a few miners of similar speed to you on my nodes right now, and the front end reports about 3-4 hours average time to find a share. That will vary with network difficulty and size of the p2pool network of course.