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

[doobeedoo]

I obeserved today a phenomenon

Suddenly my stales rate went drasticaly up allso the whole machine was lagging badly, im not sure about what did cause that, i could not find any activities in my logs so that wasnt caused by any apache related activity, just p2pool and the chains was running. I suspect that this has something to do with peers; this could be intentionaly or cause of a bug. i realized that stales and orphaned shares on the p2pool operating chain are probably caused trough this.

got the same problem.
my DOA increased to 40-50 %.
using bitcoind 6.3.

investigated that my ztex-boards caused the problem. for some reason java took 100% of all 4 cores.
did a reboot and every thing is fine now.

[Icoin]

I would llike to point your attention towards the BMP Project listed on cryptostocks echange. This project has as the one of the primary goal to add a nice amout of hashpower (acutaly approxmatly 30 gh/s on avarage) to p2pool. At the moment the shares are free to buy in total 50k for a price of 0.1 BTC each. I would realy feel honored if members of the p2pool comunity would deside to become a shareholder. For more Informations please visit https://bitcointalk.org/index.php?topic=90880 or directly at croyptostocks https://cryptostocks.com/securities/9 . For Security concerns: My personalities was audited and verfied trough cryptostocks https://bitcointalk.org/index.php?topic=88036.20

[sharky112065]

I obeserved today a phenomenon

Suddenly my stales rate went drasticaly up allso the whole machine was lagging badly, im not sure about what did cause that, i could not find any activities in my logs so that wasnt caused by any apache related activity, just p2pool and the chains was running. I suspect that this has something to do with peers; this could be intentionaly or cause of a bug. i realized that stales and orphaned shares on the p2pool operating chain are probably caused trough this.

got the same problem.
my DOA increased to 40-50 %.
using bitcoind 6.3.

investigated that my ztex-boards caused the problem. for some reason java took 100% of all 4 cores.
did a reboot and every thing is fine now.

Did this per chance happen at midnight 12 AM on the 1st of July? There was a leap second adjustment that has caused all kinds of problems. The solution is to reboot the computer that is having issues. This max CPU usage is something I have heard developers in other non Bitcoin related IRC channels mention.

[Red Emerald]

So I realize it hasn't been very long, but have the new share changes helped the orphan rate?

[doobeedoo]

I obeserved today a phenomenon

Suddenly my stales rate went drasticaly up allso the whole machine was lagging badly, im not sure about what did cause that, i could not find any activities in my logs so that wasnt caused by any apache related activity, just p2pool and the chains was running. I suspect that this has something to do with peers; this could be intentionaly or cause of a bug. i realized that stales and orphaned shares on the p2pool operating chain are probably caused trough this.

got the same problem.
my DOA increased to 40-50 %.
using bitcoind 6.3.

investigated that my ztex-boards caused the problem. for some reason java took 100% of all 4 cores.
did a reboot and every thing is fine now.

Did this per chance happen at midnight 12 AM on the 1st of July? There was a leap second adjustment that has caused all kinds of problems. The solution is to reboot the computer that is having issues. This max CPU usage is something I have heard developers in other non Bitcoin related IRC channels mention.

thanks!
yes, it happened at 12AM and it was caused by the leap-second. I read that bitlc.net had some trouble with their java-apps too.

[Prattler]

So I realize it hasn't been very long, but have the new share changes helped the orphan rate?

Yes! So far v3 changes have helped to save 1 block from being orphaned.

http://blockchain.info/block-index/241146

Still quite a lot of orphans past few days, hopefully it's just bad luck - they were all close calls.

[Icoin]

chapeau for the new version 3.1-15 my node works flawless since the update to bitcoind 0.6.3 thanks for the awesome work !!

[rav3n_pl]

Outdated clients/nodes/miners:

1PoNvnRhbvFE4xebEXjcVWfA3f2CGQkrCw
1DpJ9tfVotdAXc2FKfUDRJhHLP72hzBtQ4
17n2PjMRMZWsz6fiF9KpQZpLwRDzum7TzV
1HM8ysRnYZzmXD5i4W7FEiDP3brCZGsYC5
1Hxhyew5cJthaxX1iGi6gKjguaGYHpPoLj
16i6LtbydUput1BPDABmHtiFpuKAk9mtVT

Check your P2pool software and update it!

[twmz]

Outdated clients/nodes/miners:

...

Check your P2pool software and update it!

Sadly, people running outdated clients are almost certainly not reading this thread.  Pretty much the only way to get their attention is to force an upgrade (i.e. fork them so that they stop getting paid regularly).

[sharky112065]

Outdated clients/nodes/miners:

1PoNvnRhbvFE4xebEXjcVWfA3f2CGQkrCw
1DpJ9tfVotdAXc2FKfUDRJhHLP72hzBtQ4
17n2PjMRMZWsz6fiF9KpQZpLwRDzum7TzV
1HM8ysRnYZzmXD5i4W7FEiDP3brCZGsYC5
1Hxhyew5cJthaxX1iGi6gKjguaGYHpPoLj
16i6LtbydUput1BPDABmHtiFpuKAk9mtVT

Check your P2pool software and update it!

Sadly, you are wrong. My address is in that list and I upgraded my node three days ago and have double checked via the stats page.

[rav3n_pl]

https://en.bitcoin.it/wiki/P2Pool#Miners
Added simple tips that help few ppl reduce local DOA when using cgminer (best miner imo).

We have 2 kind of stales/doa there.

1. Miner getting work from p2pool
2. Miner finds a share diff>1 solution and send it to pool
3. Pool register share to calculate hash speed of miner
4. Pool checking that SD of share is higher that current SD of p2pool
5. If 4 is true Pool sending share to to other nodes.

Tuning miner options can reduce DOA that appears between 2 and 3. We can see it as red line in local graph.
It will NOT reduce doa/stales in between 4 and 5. Forrestv is struggling to improve logic of pool in that point. BUT like in "real" bitcoin share chain there is no way to reduce number of orphans to 0... ;]

[organofcorti]

Couple of questions, rav3n_pl:

How dynamic is the difficulty? How often does it change?

If it changes often and this causes orphaned shares, what would the downside of changing it less frequently be?

Thanks for the work you do explaining p2Pool - it's really very helpful for those of us that want to understand it better but don't actually mine there.

[twmz]

How dynamic is the difficulty? How often does it change?
If it changes often and this causes orphaned shares, what would the downside of changing it less frequently be?

I don't know if it changes every share or every few shares, but I'm not sure how the frequency of difficulty changes, alone is causing extra DOA/orphaned shares.  If, when you started looking for a share the difficulty was 800 and you find a share that is valid for difficulty <= 800, the only way that that wouldn't be valid is if someone else found a share in between when you started looking and when you found a share (which is the only time the difficulty changes).  But if that happens, then your share is DOA anyway because your share doesn't build off the most recent share (which arrived at your node and changed the difficulty). 

Maybe I am missing something, though?

[organofcorti]

How dynamic is the difficulty? How often does it change?
If it changes often and this causes orphaned shares, what would the downside of changing it less frequently be?

If, when you started looking for a share the difficulty was 800 and you find a share that is valid for difficulty <= 800, the only way that that wouldn't be valid is if someone else found a share in between when you started looking and when you found a share (which is the only time the difficulty changes). 

If you start looking for a solution at difficulty, but by the time you submit it the difficulty is 900 and your solution is too large for the retarget, it will get rejected - is that DOA or orphaned? Not sure.

Either way, if difficulty changes too often then when it increase you'd expect to have an increase in submitted shares that do not solve the current difficulty. Or is the LP mechanism fast enough to prevent this?

[twmz]

How dynamic is the difficulty? How often does it change?
If it changes often and this causes orphaned shares, what would the downside of changing it less frequently be?

If, when you started looking for a share the difficulty was 800 and you find a share that is valid for difficulty <= 800, the only way that that wouldn't be valid is if someone else found a share in between when you started looking and when you found a share (which is the only time the difficulty changes). 

If you start looking for a solution at difficulty, but by the time you submit it the difficulty is 900 and your solution is too large for the retarget, it will get rejected - is that DOA or orphaned? Not sure.

Either way, if difficulty changes too often then when it increase you'd expect to have an increase in submitted shares that do not solve the current difficulty. Or is the LP mechanism fast enough to prevent this?

If you submit a pseudo share (i.e. a diff 1 share) and it doesn't meet the requirements of the current share difficulty, it is just not a share.  It's not orphaned or DOA just because it doesn't meet the difficulty.  This is common as most shares that the miner submits meet the diff 1 requirements but not the diff 800 requirements.

Now, if a pseudo share comes in that builds off of share X, but share X+1 has arrived at the node in the mean time, then that is a DOA pseudo share, regardless of if it meets the difficulty requirements.  If it happens to meet the difficulty requirements it will be counted in the "dead shares" statistics.

Since share difficulty only changes in response to new shares being added to the share chain, the only way difficulty could change while your pseudo share was "in flight" would be if a new share had been added to the sharechain.  In that case, your pseudo share is DOA no matter what because it isn't building off the head of the sharechain.  Again, difficulty change or not, it's DOA, so I don't think the difficulty change rate matters.

[organofcorti]

If you submit a pseudo share (i.e. a diff 1 share) and it doesn't meet the requirements of the current share difficulty, it is just not a share.  It's not orphaned or DOA just because it doesn't meet the difficulty.  This is common as most shares that the miner submits meet the diff 1 requirements but not the diff 800 requirements.

I follow - I was assuming the miner would be mining at the appropriate difficulty and only sending shares that met it. But if you're sending D1 shares which then may be rejected if they don't meet diff 800, then this isn't an issue. Thanks for the explanation, twmz.

[twmz]

If you submit a pseudo share (i.e. a diff 1 share) and it doesn't meet the requirements of the current share difficulty, it is just not a share.  It's not orphaned or DOA just because it doesn't meet the difficulty.  This is common as most shares that the miner submits meet the diff 1 requirements but not the diff 800 requirements.

I follow - I was assuming the miner would be mining at the appropriate difficulty and only sending shares that met it. But if you're sending D1 shares which then may be rejected if they don't meet diff 800, then this isn't an issue. Thanks for the explanation, twmz.

Yes, p2pool "lies" to the miner and tells it to look for diff 1 shares.  This was done for multiple reasons.  It helps verify the miner is working more quickly because shares are found 800 times faster.  It allows p2pool to estimate hashrate of local miners more accurately.  Also, some miners choke on shares that are higher than diff 1 and so this is also done to be as compatible with existing miners as possible.

[Diapolo]

https://en.bitcoin.it/wiki/P2Pool#Miners
Added simple tips that help few ppl reduce local DOA when using cgminer (best miner imo).

We have 2 kind of stales/doa there.

1. Miner getting work from p2pool
2. Miner finds a share diff>1 solution and send it to pool
3. Pool register share to calculate hash speed of miner
4. Pool checking that SD of share is higher that current SD of p2pool
5. If 4 is true Pool sending share to to other nodes.

Tuning miner options can reduce DOA that appears between 2 and 3. We can see it as red line in local graph.
It will NOT reduce doa/stales in between 4 and 5. Forrestv is struggling to improve logic of pool in that point. BUT like in "real" bitcoin share chain there is no way to reduce number of orphans to 0... ;]

You did not even mention the diakgcn kernel in CGMINER (use -v 2 -w 256 with it for optimal performance) :-P, at least it should be mentioned as an option and perhaps it can be valuable for some users out there .

Dia

[rav3n_pl]

Couple of questions, rav3n_pl:

How dynamic is the difficulty? How often does it change?

If it changes often and this causes orphaned shares, what would the downside of changing it less frequently be?

Thanks for the work you do explaining p2Pool - it's really very helpful for those of us that want to understand it better but don't actually mine there.

Share diff is changing about every 10 sec. Every LP in P2pool means that some node found a valid p2pool chain share and diff is adjusted to meet another share in about 10sec.
DOA share appears when it is delivered to pool after LP message (it is from "previous" LP) and it can not be joined into chain.
Orphaned share is like in bitcoin chain - 2 shares almost at once and win that one what follows quicker by another valid share.

[Proofer]

Ubuntu 11.04, p2pool Version: 3.1-17-gb3a4925: If I try to run p2pool without my bitcoind username and password at the end of the command line, I get:

Code:

Traceback (most recent call last):
  File "/home/user/src/p2pool/run_p2pool.py", line 5, in <module>
    main.run()
  File "/home/user/src/p2pool/p2pool/main.py", line 676, in run
    cp.readfp(StringIO.StringIO('[x]\r\n' + f.read()))
  File "/usr/lib/python2.7/ConfigParser.py", line 316, in readfp
    self._read(fp, filename)
  File "/usr/lib/python2.7/ConfigParser.py", line 538, in _read
    raise e
ConfigParser.ParsingError: File contains parsing errors: <???>
        [line  5]: ' # Network-related settings:\n'
        [line  7]: ' # Run on the test network instead of the real bitcoin network.\n'
        [line  8]: ' #testnet=1\n'

 # Connect via a socks4 proxy
 #proxy=127.0.0.1:9050
 
 ##############################################################
 ##            Quick Primer on addnode vs connect            ##
 ##  Let's say for instance you use addnode=4.2.2.4          ##
 ##  addnode will connect you to and tell you about the      ##

[the rest of my bitcoin.conf file is listed here]