Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 492. (Read 2591928 times)

Why not reanimate p2pmining? https://bitcointalksearch.org/topic/offlinep2pminingcom-hybrid-p2pool-no-fee-btcnmcixci0cdevltc-66202
Code available by PMing owner afik.

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?

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. 

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.


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 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

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

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.

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

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

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.

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

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

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?

p2pool LTC shares are now 85% for version 13.  When it reaches 95%, older versions of p2pool will be permanently left behind.  p2pool-13+ requires litecoin-0.8.3.7+.  Please upgrade both immediately in order to avoid problems.

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

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..?

so i convinced my brother to write a python script that will send an email (or an sms/mms if your provider has a gateway ex: [email protected] (verizon)) when you get a share and/or when a block is found. the message will tell you if its a share or a block, and also put in the current payout when either is found.

you can find it here:

http://gist.github.com/dreness/6247320

if you like it and feel like donating a buck or two, send to the address in my sig and i will give him the cash personally.

cheers!!

My p2pool node (which I don't use, personally, and so don't monitor closely) got hosed somehow and was in a non-stop error loop.  I killed it, git pull-ed, and restarted it and it looks like it is working again, although my node thinks the pool speed is about 4.6 TH/s.  If that is not what other people's nodes think, let me know.

PM me for faster service if you see any future problems

Update: P.S.  p2pool.info is showing the average hashrate over the past hour based on samples taken every 5 minutes.  So if hashrate spikes up briefly and then drops back to normal, you won't see the hashrate jump up as high on p2pool.info.

The "other fork" is only in the 10's of GH range (last I saw) not the TH range, so it's more likely it's just estimating the network rate a bit differently than fresh's local node.

For reference, my local node is currently showing a network rate of 5.93TH/s. It does vary a bit as hardware is added and removed, etc.