[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[dc81]

I love P2Pool and having been running it for a while but I have a pretty marginal rig at around 700MH/s and with the latest hike in difficulty I'm just not getting any shares any more.

Sooner or later you should get one. It should all even out in the long run.

Of course, if you start getting shares once a week or something then it's time to switch pool, but it can't be that bad..?

700MH/s at currently 23400 difficulty is ...
23400 * 2^32 / (700 x 10^6) sec = 143574.6 sec = 39hrs 52min 55sec share average

how long does a share last in terms of payout? e.g. if you are getting 1 share every 2 days will you still be getting a payout for each block or will there be periods where your payout dips down to zero?

share chain is 3 days (8640 shares x 30 seconds)

[1714286889]

1714286889

[1714286889]

1714286889

[1714286889]

1714286889

[1714286889]

1714286889

[rav3n_pl]

But max 3 blocks, so if we have ~11hrs in between blocks it "cuts" in 1.5 day

[twmz]

But max 3 blocks, so if we have ~11hrs in between blocks it "cuts" in 1.5 day

It's a max of 3 "normal length" blocks, if I recall.  So it can be more than 3 blocks if there is a lucky streak and rounds are very short.  I may be remembering wrong, though.

[freshzive]

so if p2pool.info is underreporting the pool hashrate, doesn't that mean it's over estimating our luck?

[notme]

so if p2pool.info is underreporting the pool hashrate, doesn't that mean it's over estimating our luck?

It isn't underreporting.  It is using a smoother moving average that reacts less to temporary jumps and dips in hashrate.

[twmz]

so if p2pool.info is underreporting the pool hashrate, doesn't that mean it's over estimating our luck?

It isn't underreporting.  It is using a smoother moving average that reacts less to temporary jumps and dips in hashrate.

When calculating luck, the full complement of individual 5 minute data points are used.  The smoothing/averaging is only used on the UI/graph shown on the page to reduce the amount of data that has be loaded to the web browser and speed up the page load.

[wtogami]

p2pool-13.3 released containing bug fixes primarily for p2pool LTC.  This upgrade is recommended for p2pool LTC miners as it bans v11 nodes, reducing log spam and bandwidth use by a significant amount.

[zvs]

p2pool-13.3 released containing bug fixes primarily for p2pool LTC.  This upgrade is recommended for p2pool LTC miners as it bans v11 nodes, reducing log spam and bandwidth use by a significant amount.

At least unlike the bitcoin split, the cut-off LTC nodes should solve a few blocks (right now it's at one every 12hrs).  Given the 40% orphan/DOA rate, I've been considering reverting to a lower version and maybe even start my stuff back up to mine litecoins

[forrestv]

P2Pool release 13.3 - commit hash: 3ca723ee19cb8e2ee54e32a81e0d3caa2ff51441

Windows binary: http://u.forre.st/u/zdeurytx/p2pool_win32_13.3.zip
Windows binary signature: http://u.forre.st/u/gpuwkhue/p2pool_win32_13.3.zip.sig
Source zipball: https://github.com/forrestv/p2pool/zipball/13.3
Source tarball: https://github.com/forrestv/p2pool/tarball/13.3

Changes:
* Changes to make Litecoin switch go more smoothly (drop/ban old peers)
* Fixed startum miner failover not working - P2Pool would keep miners connected during failure conditions (lost connection to bitcoind or all peers)
* Fixed potential memory leak

[wtogami]

p2pool-13.3 released containing bug fixes primarily for p2pool LTC.  This upgrade is recommended for p2pool LTC miners as it bans v11 nodes, reducing log spam and bandwidth use by a significant amount.

At least unlike the bitcoin split, the cut-off LTC nodes should solve a few blocks (right now it's at one every 12hrs).  Given the 40% orphan/DOA rate, I've been considering reverting to a lower version and maybe even start my stuff back up to mine litecoins

40% orphan/DOA rate was a mis-measurement on the v11 side of the fork during a short period while those nodes failed to find each other as they were rejected by the v13 network.  v13 has 15 instead of 10 second average share intervals which has already enabled a measurable improvement to orphan and DOA rates on the v13 network.

Also note that p2pool version 11 was incapable of submitting blocks to litecoin-0.8.3.7, and 0.6.9.2 is considered unsafe to operate due to unpatched vulnerabilities.

Code:

        litecoin=math.Object(
        PARENT=networks.nets['litecoin'],
        SHARE_PERIOD=10, # seconds
        NEW_SHARE_PERIOD=15, # seconds
        CHAIN_LENGTH=24*60*60//10, # shares
        REAL_CHAIN_LENGTH=24*60*60//10, # shares
        TARGET_LOOKBEHIND=200, # shares
        SPREAD=12, # blocks
        NEW_SPREAD=3, # blocks

Also the share lifetime was reduced from the previous 12 shares to 3, and share difficulty for the first share is increased to such a level that you would have a target minimum dust size of 0.03 LTC.  The combination of these changes has the following effect:

• Greater Efficiency for the LTC Network: Small miners receive bigger dust payouts, but less often.  This means the reduction of thousands of tiny dust outputs per day, and far lower transaction fees for miners to combine the dust outputs.
• Lower DOA/orphan rate allows GPU miners to increase Intensity, allowing the entire p2pool LTC network to increase its hashrate with existing hardware.

p2pool-13.3 reduces bandwidth waste and log spam significantly.

[alatvian]

my LTC p2pool v13 reports in the log file that share difficulty is >6, while on the web UI it's around 1.  I'm tending to believe the log file, because cgminer hasn't scored a share in 2 days, but I have several shares over 64K difficulty (which equates to diff=1, if I understand cgminer's stats correctly).  Why does p2pool report 2 different difficulties?

The node is here: http://192.241.177.9:9327/static/.  I've disconnected my miners because I think the difficulty is just too great for my hashing power. 

[daemondazz]

P2Pool Sub-Pool for Low Hash-Rate Miners

I am planning up modifying the Bitcoin node at cryptominer.org:9332 to act as a sub-pool and be more friendly for low hash-rate miners. I'm looking for some feedback on my scheme to see if there are any glaring holes / vulnerabilities.

My basic plan is:

• Configure p2pool to have 100% fee so all hash rate goes to the pool
• A 'shift' is 12 hours in length, based on UTC midnight/noon
• P2Pool is modified to log all submitted shares with diff >= 25 (this is already completed - my patch provides a command line option to specify a logging function. I plan on submitting this to forrestv for inclusion upstream)
• The miner score is calculated as the logarithmic of the sum of the submitted difficulty of shares for that miner for that shift
• The miner is credited for all blocks found during the shift, minus an admin fee, based on the percentage of their score compared to the total

The admin fee will probably be on the order of 5% of the payout the node receives for each block found by the network.

I'm only logging submitted shares with diff >= 25 just so I don't have to log a heap of data but still allow the miners to submit a reasonable number of shares. My USB Erupters seem to find a >25 diff block every few minutes so a 12 hour shift should allow time for even very low rate miners to accrue a score. This value can be tweaked easily enough if needed.

I'm thinking the score will be the logarithmic of the sum of the total diff submitted rather than just the a count of shares that are higher than the threshold to provide a reward finding more difficult hashes, and especially shares and blocks. This is one area I can see there may be holes in the logic in.

If the miner connects to the pool using a valid bitcoin address, they are automatically paid out once a global threshold is reached (such as 0.25 BTC) or they can register on the website and choose more "friendly" usernames and payout threshold/address. This allows existing miners to continue as they are. I want to also modify p2pool so it rejects logins from users which are not a valid address or already registered on the website. If a miner that has mined using a bitcoin address subsequently registers on the website, they will have to sign a message using the address to claim the address and be able to modify settings.

An example: I have 3 miners, which submit scores of 100, 50 and 25 respectively. During a shift the networks finds 3 blocks which I get paid out 0.12412, 0.25121 and 0.16331 BTC.

Total received = 0.53864
Total score = 175
Admin fee (5%) = 0.026932 BTC
Payout for miners = 0.511708 BTC

Miner1 = 100/175*0.511708 = 0.29240457 BTC
Miner2 = 50/175*0.511708  = 0.14620228 BTC
Miner3 = 25/175*0.511708  = 0.07310114 BTC

Any feedback? Does this sound like a reasonable idea? Any big problems with it?

[rav3n_pl]

P2Pool Sub-Pool for Low Hash-Rate Miners
(...)
Any feedback? Does this sound like a reasonable idea? Any big problems with it?

Why not reanimate p2pmining? https://bitcointalk.org/index.php?topic=66202.0
Code available by PMing owner afik.

[daemondazz]

P2Pool Sub-Pool for Low Hash-Rate Miners
(...)
Any feedback? Does this sound like a reasonable idea? Any big problems with it?

Why not reanimate p2pmining? https://bitcointalk.org/index.php?topic=66202.0
Code available by PMing owner afik.

I did look at that, if you look at the last few posts in that thread you linked I actually worked out the database schema from the code. The biggest issue I had with it was that it written in PHP and hence doesn't integrate with the python web framework I'm using for cryptominer.org. Also the integration into p2pool was fairly specific and has drifted from HEAD over time.

The changes I've made to p2pool are very simple and also generic. They could easily be used by anybody to create their own modules for doing something similar. You pass in the full python path to a model as a CLI option and it imports it on the fly and then calls it with a predefined list of arguments. The simplest logging function could be:

Code:

def logger(submitted_hash, submitted_diff, found_block, found_share, miner_username):
    print 'Logged share diff %d (score %6.5f) from %s' % (submitted_diff, math.log(submitted_diff), miner_username)

Anyway, the coding side of this is fairly easy, in fact I've already done about 60% of it. I was more after feedback about the concept of running a sub-pool for low hashrate miners and if my methodology had any obvious issues that could be exploited.

[rav3n_pl]

You should log (count) only accepted shares, the way you posted can log both accepted and rejected ones Or log both but add "accepted" bool field for statistics.
Better way would be log into database not in text file - this way you can run many instances (ie European node and US node) and gather data in one place.

[TierNolan]

I did look at that, if you look at the last few posts in that thread you linked I actually worked out the database schema from the code. The biggest issue I had with it was that it written in PHP and hence doesn't integrate with the python web framework I'm using for cryptominer.org. Also the integration into p2pool was fairly specific and has drifted from HEAD over time.

Adding support for sub-pools directly into p2pool itself would add value to the p2pool software.

Variance for pools consists of pool variance and share variance.  If the pool is only winning one block every 3-4 days, then pool variance is high.  No matter how many shares are issued, the total variance can never be lower than that.

The more hashing power on the p2pool chain, the lower the variance for p2pool and that applies to all users.

Even, the major pools would benefit from it to, though granted to a lesser extent.  If 2 could be convinced to join, then both benefit from lower variance and reduce variance of all other users of p2pool.

Has anyone considered hierarchical p2pools? 

Using p2pool to mine the p2pool sharechain, in the same way people have modified the pool to mine alt-chains.

You could have 1 root chains and 10 sub-chains mining that chain.  Each sub-chain has 10X lower difficulty.

The risk of a sub-chain dying increases the more hops from the root chain though.

[wtogami]

Subpools are fine as long as they build up balances of miners over time in order to avoid dust micropayments that are unhealthy for the network and expensive for the miners to spend.

[nibor]

What are the current recommended bitcoind settings (blocksize etc...). Seen various answers in past but would like to know current thinking. Am mining with a 55ghash asic.

Currently have between 0.1 and 0.3 getwork latency. And have 1.8%DOA from web page. Actual share stats I can not say as only been mining a few hours so are unreliable.

Thanks

[daemondazz]

Thanks for the feedback guys, it sounds to me like there are no major issues with my concept and there may be some support for the service, so I'll continue with this.

P2Pool is modified to log all submitted shares with diff >= 25 (this is already completed - my patch provides a command line option to specify a logging function. I plan on submitting this to forrestv for inclusion upstream)

I have now done a push request to forrestv's GitHub repo for p2pool for the logging function: https://github.com/forrestv/p2pool/pull/127

The patch calls the logging function for all shares that are submitted by clients, it's up to the called function to perform any filtering needed, such as submitted_diff >= 25.

[TreasureSeeker]

my LTC p2pool v13 reports in the log file that share difficulty is >6, while on the web UI it's around 1.  I'm tending to believe the log file, because cgminer hasn't scored a share in 2 days, but I have several shares over 64K difficulty (which equates to diff=1, if I understand cgminer's stats correctly).  Why does p2pool report 2 different difficulties?

The node is here: http://192.241.177.9:9327/static/.  I've disconnected my miners because I think the difficulty is just too great for my hashing power. 

I'm getting the same situation at http://treasurequarry.com:9844/static/ . 

At the moment, for example, the logs show Share difficulty: 0.516141 whereas the share difficulty shown on the stats page is  0.0513.

Similarly the logs show  Expected time to share: 27.3 seconds (equivalent to 0.455 minutes) whereas the stats page shows 0.0459 minutes.