kano replied to you in the other thread.

address/2500 will set your diff target to the minimum sharechain difficulty when submitting real shares, however it's so much higher than that, using / that low has no effect.

address+2500 will set your pseudo share target to that, for graphing purposes. No effect on actual shares that go on the sharechain for payouts.

So if blocks are only found every 2 days, say, all shares found in the first day of searching are lost before the block is found? Giving us basically an N=.5 window? That doesn't seem right.

I recall (unless I'm confused) that p2pool uses a PPLNS window of N=3 blocks, so if blocks are found frequently, shares will last 3 blocks of time. However when blocks are taking longer to be found like at the moment, is it 3 days before shares will expire off the end of the max sharechain size? I couldn't quite remember if it was 3 days or some other period of time.

Are you using the default interface? The one I like is

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

which you can see in live use here:

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

If you want the "time to share" info down on the miner line, you need to go into p2pool-node-status after you clone it and try "git branch devel". That will update it to support the extended API stats needed.

If you cloned it from github I think all you need to do is "git pull" in the p2pool directory.

You might find this useful:

A guide for mining efficiently on P2Pool, includes FUD repellent and FAQ

If it is any help to you, the script I use on my linux machine reads:


Obviously, replace the address with your own if you have a fee. Since I have --fee 0 at the moment I might not even need --address. The "bitcoinuser" and "bitcoinpassword" are the rpcuser and rpcpassword set in your bitcoin.conf file.

As jonnybravo mentioned, the exchanges are the ones who don't process deposits properly when they are in the coinbase of the block (the newly minted reward coins). Nothing p2pool can do about that.

You could mine to an online wallet at a variety of places if you don't want to run a wallet locally. On my PC I use Electrum. Doesn't require downloading the blockchain, syncs very quickly, and gives you a seed you can print out and store in case you ever need to recreate your wallet from scratch.

An important thing to remember is that the way it works is a % of shares founds, not a % of the bitcoin paid by those shares. So each share has a 1% chance of going towards the fee+donation. 99% of the shares are paid totally to you. If you run a public node with 1% in fee+donation, you might not see anything happening at first.

My hope is that one day if there's ever another major p2pool version released with mandatory upgrade, that forrest adds support for the donation (and fee?) to appear right with the share data in the blockchain. Thus if you are 1% donation, and a block is found, 1% of that share's pay goes to forrest and 99% to the share's owner. This smooths it out so you don't randomly lose a share (which you might only be finding once a day as small miner), and provides less variance to miners, pool operators, and forrest himself.

2 TH takes about 3 hours per share on average. So if you are at 1/5 that, I'm guessing you'll get about 1 share every 15 hours or so. Keep in mind shares last a while, so the startup time where you have no shares is offset by the time after you get shares but eventually stop mining, you'll still be getting paid on any blocks found before those shares expire.

In celebration of forrestv merging in the extended API stats pull request, I spun up an old server, refreshed everything, and got a public node online to try it out. And since I don't mine any more, I rented some hash power to make the stats fill in.

With baseline p2pool and the devel branch of p2pool-node-status we end up with this:

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

The extended API stats is what allows the per-miner "time to share" info to appear on the interface under the active miners section. It also shows the difficulty target of work last served out to the miner (to earn a share, not to be confused with pseudo difficulty for hash rate calculations).

All miners on the node would be served the same difficulty target in base p2pool, you'd need to apply my vardiffbyaddress patch to make it so small miners work on the lowest difficulty allowed whereas bigger miners have the variable difficulty based on their hashrate. Back in the day on alt coins, it was very cool to watch small miners have lower targets than big miners. (That was the whole motivation for doing it.)

And while supply lasts... bonus fun things!

Graph of share chain difficulty: http://us-east.royalminingco.com/p2pool_share_history/
Geographic map of my p2pool peers: http://us-east.royalminingco.com/map.php

Yeah maybe I'm being naïve. Don't know. It just doesn't seem like the largest miners need to have potentially 150 shares in the share chain at a given time, when they could have 15 shares worth 10x as much instead. There isn't a real 'detriment' here as you'll still earn the same amount of income on average.

Also a big miner shouldn't view p2pool share difficulty as "very high".

I don't have the math to come up with a confidence interval on the # of shares someone will have in the share chain for a given hash power off the top of my head. However, for sake of example, lets say the huge miner with 150 share on average has high confidence to be in the 130-170 range. Likewise, if his diff target was ten times higher, he'd be 13-17 with 15 on average. If each share of normal difficulty paid out .01 BTC for simplicity (.1 BTC for the 10x higher target shares), then his income averages 150 * .01 or 15 * .1, 1.5 BTC either way. The question is if the steps within this range are steps of .01 BTC each or .1 BTC each.

When I used to run sha256 alt coin p2pool nodes and would mine on them with my S1, I'd set /DIFF as high as I could to not shut out GPU miners. I know, few people likely do that in the p2pool BTC world, which is why it makes more sense for p2pool to automatically scale the vardiff beyond just minimizing network traffic and be smart regarding the fact the sharechain is a fixed size.

I guess my point is the # of shares in the sharechain is a resource that needs to be managed as intelligently as possible for the health of the network. For each big miner with 100+ shares in the chain at any one time, there will be far more miners struggling to keep just 1 share active at all times.

Edit: On a sidenote I sent an email to windpath with various old links and github patches in case he wants to apply some nice front end improvements from last year. It seems p2pool-node-status went quiet before they moved from -devel to the normal branch, and the alt coins that also used the interface all faded away. So the cool improvements to show things like estimated time per share and miner-specific difficulty targets have been forgotten to the sands of time.

Been looking around the past month of posts and saw this. I think I recall a conversation once that it'd be nice to scale the difficulty target for miners to target some preferred # of shares in the sharechain. It does this already in some regard as I think there's a cap the target for a hash rate can't be so low that you'll find more than 5% of the full share chain's % of shares on average. (Going by memory and haven't touched p2pool since last April.) However that's realistically way too high. For low variance payouts for a large miner, you only need to keep a few shares in the chain at all times. This is a reason "friendly" large miners could use /DIFF to kick their difficulty targets way higher... they'd have less shares in the share chain (leaving more room for smaller people and reducing their variance), but the shares they do have are worth that much more during payout.

Actually I used google and spent some time trying to find what I'm thinking of. I did. It's here, the bottom portion of this post:

https://bitcointalk.org/index.php?topic=18313.msg4830990#msg4830990

with small followup:

https://bitcointalk.org/index.php?topic=18313.msg4831519#msg4831519

What I provided was a different way to calculate target difficulties for large miners such that they'd always have shares in the sharechain (amount of payment would vary, but they'd almost never miss a payment totally). For large miners it might drop the # of shares in the sharechain they were gobbling up by a factor of 10-15. Which means the sharechain difficulty is lower, making it easier for smaller miners to find shares.


It wouldn't be in a large miner's financial interest to push out/hurt smaller miners. Just makes p2pool network speed lower for everyone. Granted, the community is full of vandals though.

Edit: Correction, the hard code in p2pool was to make a miner's minimum difficulty target even if they said /1 to be such that they can only find 1.67% of the total share chain's shares. This is far too many shares for 1 miner to have, of course...

I've been away a year so maybe you are referring to something else, but if you are talking about small miners having their difficulty targets skyrocket when a large miner joins the same public p2pool node, that is avoided with this pull request:

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

Basically, it assigns difficulty targets to miners based on their payment address instead of the total hash rate of the local node. This way the difficulty target your miner is working on is identical to running your own private node, even if some other far larger miner is on the same public node with you. This is for the true difficulty target to get shares, a different pull request was submitted related to pseduo-shares.

Just been checking out ckpool and ckproxy, I think those came out after I left, quite cool. I'd have been all over ckproxy if I knew about it back then. I attempted to learn enough Haskell to run proxypool with p2pool for BTC mining, but it wasn't worth the pain.

The 25BTC is shared throughout all of the p2pool network. It's like a distributed pool, where you mine off your own node (or a public node) with the advantages that can give you (zero latency if you run it local to your miners) but you also benefit from sharing hash power with the rest of the p2pool network to reduce variance.

NiceHash seems like a cool idea. It must have launched right around the time I stopped messing around with Bitcoin. It may have kept me around longer if I knew about it at the time.

I can see how the price to rent would rise when there are alt coins people want to throw lots of hash power at for short periods of time, but when it comes to mining Bitcoin itself, is the idea people with hardware can get a PPS payment with no variance (albeit lower than mining normally) and people who rent can pay the PPS and then mine bitcoin directly to arbitrage the difference in expected return by absorbing all of the variance themselves?

Or do people not generally rent hash power to mine Bitcoin, and instead it's mostly about the alt coins?

Edit: I guess that's not the thing at all. Looking at the price history graphs, esp. on scrypt, people consistently pay more than the miners would make mining bitcoin/litecoin themselves. Are buyers of hash power predominately mining alt coins?

I don't think anyone ever properly answered your question so I'll give it a shot.

In this context, "hop" is a technical term related to ways you can exploit pools running certain older payment methods by changing between pools in a way that will increase your income at the expense of other miners on those pools who remain loyal to the pool and stay there all of the time. Eventually some alternate payment methods were developed which were hop-proof in the sense a miner can't enter/leave the pool in a systematic way in order to boost their earnings. The most popular is PPLNS, although to me the most interesting is DGM (by Meni Rosenfeld). (I ran a Terracoin pool for over a year that used DGM.)

So when p2pool says it is Hop-proof, it means you can't abuse the payment method. It doesn't mean people can't or won't still use multiple pools or move around to chase "luck".

If you are interested in more information, read Analysis of Bitcoin Pooled Mining Reward Systems.

Ahhhhhhh. That finally solves the mystery of "missing" blocks on alt coins with rapid blockchains.

Ahh okay cool, glad someone ran with the idea. clown's ProxyPool he originally only ran for Doge. The code was open sourced, I thought about trying to get it going for regular bitcoin, but he wrote it in Haskell (I think it was), which made my eyes bleed trying to learn. Finally gave up as being too hard to learn a really weird new language just to run a p2pool proxy that noone might use.

For small miners there was that proxypool project,

https://bitcointalk.org/index.php?topic=461632.0

but it appears he's been out of the forum for a year as well and his pool is gone.

Looked over Windpath's site, looks cool. I remember the Node Stats was the front end I liked and used on my pools. I see my blocklines pull request did get merged in. mmouse and iongchun had made some nice tweaks as well. iongchun added a link on the default page addresses to an address-specific page, where all stats were based just for yourself. Quite nice and personal for a no-login stat system.

I eventually turned my own little miners off (just an S1 and a couple tiny things) so I don't have the hash power to even bother with alt coins any more. The hassle of IRS reporting when they released their guidelines is what was the nail in the coffin for me.