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

[twmz]

yes, we definately need fallback nodes. so in case 1 bitcoind goes down, p2pool goes to the next, same if its lagging.
could you do this forrestv?

My post has nothing to do with the actual p2pool software (that forrestv develops).  I'm talking about the p2pool.info website that monitors the blockchain looking for blocks found by the p2pool software. 

Currently, it doesn't have fallback support.  While it is theoretically possible to add it, I'd rather just find a bitcoin instance to talk to that is in theory available 24/7 (baring unplanned downtime) vs something that comes and goes regularly.  If I can't find a 24/7 bitcoin to talk to, I'll suck it up and either keep running my own out of my house, or I'll do the work to point p2pool.info at blockchain.info.

[btharper]

Can't you just use Blockchain.info for this?

It already does pull some information from blockchain.info as a backup method, but it can't get everything from there, mostly because blockchain.info automatically blocks IP addresses that make a lot of requests (which has happened to p2pool.info multiple times).

Actually, it appears that they significantly raised their request limiting thresholds, so maybe this would work.  It would mean significantly rewriting some of the p2pool.info code since blockchain.info has a different set of APIs than bitcoind does and p2pool.info's code is built assuming bitcoind.  So if someone does happen to have a bitcoind server, that would still be the easiest for me to migrate to.  If not, I will add to my todo list to rewrite the code to use blockchain.info and we'll just hope blockchain.info doesn't ever go away

You can also contact them for an api key allowing you to bypass rate limiting altogether. Is it possible you could get the same information from blockexplorer or an ABE client? or possibly even an electrum server?

[zvs]

yes, we definately need fallback nodes. so in case 1 bitcoind goes down, p2pool goes to the next, same if its lagging.
could you do this forrestv?

My post has nothing to do with the actual p2pool software (that forrestv develops).  I'm talking about the p2pool.info website that monitors the blockchain looking for blocks found by the p2pool software. 

Currently, it doesn't have fallback support.  While it is theoretically possible to add it, I'd rather just find a bitcoin instance to talk to that is in theory available 24/7 (baring unplanned downtime) vs something that comes and goes regularly.  If I can't find a 24/7 bitcoin to talk to, I'll suck it up and either keep running my own out of my house, or I'll do the work to point p2pool.info at blockchain.info.

Ah, well, it's around 95% for the last 6 months probably.  I tend to shut it down sometimes when doing torrenting or something o' that nature.

bitcoin.sipa.be/seeds.txt has about a page full of 99%'ers

(i'm at 91%, but i think i just got polled at bad times...   like ^^ , around 95%)

What about just using blockchain as a backup for a bitcoind that's > 60s unresponsive?  'though I suppose that'd require you to do the same amt of work on the code

[zvs]

I seem to be having that memory issue ongoing as well,

Fri Feb 15 2013 22:47:24 GMT-0600 (Central Standard Time)   516M
Fri Feb 15 2013 22:44:36 GMT-0600 (Central Standard Time)   516M
Fri Feb 15 2013 22:41:48 GMT-0600 (Central Standard Time)   516M
Fri Feb 15 2013 22:39:00 GMT-0600 (Central Standard Time)   516M
Fri Feb 15 2013 22:36:12 GMT-0600 (Central Standard Time)   516M
Fri Feb 15 2013 22:33:24 GMT-0600 (Central Standard Time)   516M
Fri Feb 15 2013 22:30:36 GMT-0600 (Central Standard Time)   515M
Fri Feb 15 2013 22:27:48 GMT-0600 (Central Standard Time)   515M
Fri Feb 15 2013 22:25:00 GMT-0600 (Central Standard Time)   515M
Fri Feb 15 2013 22:22:12 GMT-0600 (Central Standard Time)   515M
Fri Feb 15 2013 22:19:24 GMT-0600 (Central Standard Time)   515M
Fri Feb 15 2013 22:16:36 GMT-0600 (Central Standard Time)   514M
Fri Feb 15 2013 22:13:48 GMT-0600 (Central Standard Time)   514M
Fri Feb 15 2013 22:11:00 GMT-0600 (Central Standard Time)   514M
Fri Feb 15 2013 22:08:12 GMT-0600 (Central Standard Time)   513M
Fri Feb 15 2013 22:05:24 GMT-0600 (Central Standard Time)   512M
Fri Feb 15 2013 22:02:36 GMT-0600 (Central Standard Time)   510M
Fri Feb 15 2013 21:59:48 GMT-0600 (Central Standard Time)   508M
Fri Feb 15 2013 21:57:00 GMT-0600 (Central Standard Time)   508M
Fri Feb 15 2013 21:54:12 GMT-0600 (Central Standard Time)   507M
Fri Feb 15 2013 21:51:24 GMT-0600 (Central Standard Time)   507M

it's @ 5.9.24.81:9332, though I don't see anything particularly out of the ordinary.  Looks like it started a bit ago

Fri Feb 15 2013 22:36:00 GMT-0600 (Central Standard Time)   516M
Fri Feb 15 2013 22:02:24 GMT-0600 (Central Standard Time)   510M
Fri Feb 15 2013 21:28:48 GMT-0600 (Central Standard Time)   494M
Fri Feb 15 2013 20:55:12 GMT-0600 (Central Standard Time)   475M
Fri Feb 15 2013 20:21:36 GMT-0600 (Central Standard Time)   460M
Fri Feb 15 2013 19:48:00 GMT-0600 (Central Standard Time)   443M
Fri Feb 15 2013 19:14:24 GMT-0600 (Central Standard Time)   427M
Fri Feb 15 2013 18:40:48 GMT-0600 (Central Standard Time)   411M
Fri Feb 15 2013 18:07:12 GMT-0600 (Central Standard Time)   394M
Fri Feb 15 2013 17:33:36 GMT-0600 (Central Standard Time)   377M
Fri Feb 15 2013 17:00:00 GMT-0600 (Central Standard Time)   369M

slowed down a lot now.

right before it started occurring i was doing some work on a few of my computers, and the mhash rate was fluctuating quite a bit.

re: http://5.9.24.81:9332/static/graphs.html?Day

ed to insert hyperlink and stop myself from repeating myself.  jaja

[zvs]

oh, i noticed

-rw-rw-r-- 1  10003163 Feb 15 18:30 shares.12

so it started a new share file  at 6:30, but looks like that started around 5:00-5:30

err, well, on second look, i do see a little notch around 5'ish where i lost an incoming peer and gained another

[K1773R]

yes, we definately need fallback nodes. so in case 1 bitcoind goes down, p2pool goes to the next, same if its lagging.
could you do this forrestv?

My post has nothing to do with the actual p2pool software (that forrestv develops).  I'm talking about the p2pool.info website that monitors the blockchain looking for blocks found by the p2pool software. 

Currently, it doesn't have fallback support.  While it is theoretically possible to add it, I'd rather just find a bitcoin instance to talk to that is in theory available 24/7 (baring unplanned downtime) vs something that comes and goes regularly.  If I can't find a 24/7 bitcoin to talk to, I'll suck it up and either keep running my own out of my house, or I'll do the work to point p2pool.info at blockchain.info.

yea, saw that later too, sry!

[Rogue Star]

i'm finding my orphan rate is still really high in the master branch. it appears the share chain keeps getting "stuck" since there are many unverified shares when I restart p2pool. i also find there are many reports of block stales in the logs. i thought upgrading bitcoind to 0.8rc1, deleting the share and peer files would help, but it has not. for me p2pool has effectively been totally broken for any serious mining since upgrading to sharechain v10. my twisted module is v12 and I'm still seeing the memory leak as well.

[Rogue Star]

KC has asked me to post this on his behalf as he has yet to be white-listed. I haven't had a chance to investigate or even speculate if the same issue is affecting me, but perhaps this info will be useful to others in the meantime.

Hi Rouge Star,
I'm new to the forum and still in the newbies sandbox, so I can't post this, but wanted to share with you in hopes it helps. If it does, please repost to the forum as it may be a while before I can get the information up there myself. I'd spent some time looking to see if this had already been covered but found nothing related.

In a nutshell, I'd spent 4 days trying to figure out why my stale /orphan and rejected rates were abnormally high and had been troubleshooting as a network issue. My ISP forces me to do some extra work to set up NAT, so I'd double checked my NAT and FW rules verify that port 9333 was forwarding correctly and was sure it was.
From the machine I run P2Pool on, I fired up wireshark and filtered on tcp 9333 to make sure it was working asynchronously when I noticed a problem with numerous packets returning invalid IP and TCP checksums.
You may already know, most new NIC's by default will perform TCP, IP and UDP checksum calculations on board and I've run into issues with this especially with NAT where a firewall will drop the packet due to the invalid checksum. I disabled all of the "offload checksum" features on the NIC, and have had a huge improvement overnight with only 1 Stale, 2 orphans and <1% rejected in the last 12 hours.

Best of luck,
-KC

[mdude77]

I turned off port forwarding to solve my reject problem.

But I'm not using p2pool atm.  I switched when stratum support came out and things went south.  So far I haven't regretted that decision...

M

KC has asked me to post this on his behalf as he has yet to be white-listed. I haven't had a chance to investigate or even speculate if the same issue is affecting me, but perhaps this info will be useful to others in the meantime.

Hi Rouge Star,
I'm new to the forum and still in the newbies sandbox, so I can't post this, but wanted to share with you in hopes it helps. If it does, please repost to the forum as it may be a while before I can get the information up there myself. I'd spent some time looking to see if this had already been covered but found nothing related.

In a nutshell, I'd spent 4 days trying to figure out why my stale /orphan and rejected rates were abnormally high and had been troubleshooting as a network issue. My ISP forces me to do some extra work to set up NAT, so I'd double checked my NAT and FW rules verify that port 9333 was forwarding correctly and was sure it was.
From the machine I run P2Pool on, I fired up wireshark and filtered on tcp 9333 to make sure it was working asynchronously when I noticed a problem with numerous packets returning invalid IP and TCP checksums.
You may already know, most new NIC's by default will perform TCP, IP and UDP checksum calculations on board and I've run into issues with this especially with NAT where a firewall will drop the packet due to the invalid checksum. I disabled all of the "offload checksum" features on the NIC, and have had a huge improvement overnight with only 1 Stale, 2 orphans and <1% rejected in the last 12 hours.

Best of luck,
-KC

[Subo1977]

Does p2pool needs this Funktion from bitcoind 0.8?
"
This release no longer maintains a full index of historical transaction ids
by default, so looking up an arbitrary transaction using the getrawtransaction
RPC call will not work. If you need that functionality, you must run once
with -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more
details)." ?

[PatMan]

I turned off port forwarding to solve my reject problem.

But I'm not using p2pool atm.  I switched when stratum support came out and things went south.  So far I haven't regretted that decision...

M

KC has asked me to post this on his behalf as he has yet to be white-listed. I haven't had a chance to investigate or even speculate if the same issue is affecting me, but perhaps this info will be useful to others in the meantime.

Hi Rouge Star,
I'm new to the forum and still in the newbies sandbox, so I can't post this, but wanted to share with you in hopes it helps. If it does, please repost to the forum as it may be a while before I can get the information up there myself. I'd spent some time looking to see if this had already been covered but found nothing related.

In a nutshell, I'd spent 4 days trying to figure out why my stale /orphan and rejected rates were abnormally high and had been troubleshooting as a network issue. My ISP forces me to do some extra work to set up NAT, so I'd double checked my NAT and FW rules verify that port 9333 was forwarding correctly and was sure it was.
From the machine I run P2Pool on, I fired up wireshark and filtered on tcp 9333 to make sure it was working asynchronously when I noticed a problem with numerous packets returning invalid IP and TCP checksums.
You may already know, most new NIC's by default will perform TCP, IP and UDP checksum calculations on board and I've run into issues with this especially with NAT where a firewall will drop the packet due to the invalid checksum. I disabled all of the "offload checksum" features on the NIC, and have had a huge improvement overnight with only 1 Stale, 2 orphans and <1% rejected in the last 12 hours.

Best of luck,
-KC

Ditto.

[taltamir]

How do I make p2pool work for both bitcoin and litecoin simultanously?

[btharper]

How do I make p2pool work for both bitcoin and litecoin simultanously?

You would need to run two instances. One to handle BTC, one to handle LTC. Each one needs it's own config file as well, and that's where you tell it which currency it should pay attention to.

[rav3n_pl]

How do I make p2pool work for both bitcoin and litecoin simultanously?

RTFM? It is described in readme....

[taltamir]

Thank you

[zvs]

KC has asked me to post this on his behalf as he has yet to be white-listed. I haven't had a chance to investigate or even speculate if the same issue is affecting me, but perhaps this info will be useful to others in the meantime.

Hi Rouge Star,
I'm new to the forum and still in the newbies sandbox, so I can't post this, but wanted to share with you in hopes it helps. If it does, please repost to the forum as it may be a while before I can get the information up there myself. I'd spent some time looking to see if this had already been covered but found nothing related.

In a nutshell, I'd spent 4 days trying to figure out why my stale /orphan and rejected rates were abnormally high and had been troubleshooting as a network issue. My ISP forces me to do some extra work to set up NAT, so I'd double checked my NAT and FW rules verify that port 9333 was forwarding correctly and was sure it was.
From the machine I run P2Pool on, I fired up wireshark and filtered on tcp 9333 to make sure it was working asynchronously when I noticed a problem with numerous packets returning invalid IP and TCP checksums.
You may already know, most new NIC's by default will perform TCP, IP and UDP checksum calculations on board and I've run into issues with this especially with NAT where a firewall will drop the packet due to the invalid checksum. I disabled all of the "offload checksum" features on the NIC, and have had a huge improvement overnight with only 1 Stale, 2 orphans and <1% rejected in the last 12 hours.

Best of luck,
-KC

not because of any firewall, but I do this on all my systems as well (w/ netsh in windows and ethtool in linux)...   unless I'm missing something here, the offloading is only beneficial if your CPU is overworked... otherwise it's faster to just not do any offloading (don't need to offload if your CPU is at 99% idle?).  I disable RSS, chimney, and netdma in Windows as well...  Leave DCA on unless I'm having CPU issues (then it goes off and some of the others come on, like NetDMA and offloading)

[Aseras]

There's definitely something going on in the background. After 5-7 days my latency goes way up and it slows everything down and I start getting much more dead/orphans. By 9 days p2pool goes almost all dead work. A reboot/restart fixes it all. Instantly. I'd suggest just putting in a switch or script that makes p2pool restart ever 24-36 hours as a temporary "fix/workaround"

[Aseras]

How do I make p2pool work for both bitcoin and litecoin simultanously?

change a port in the conf. both try to use 9332.

[taltamir]

How do I make p2pool work for both bitcoin and litecoin simultanously?

change a port in the conf. both try to use 9332.

thanks

[Subo1977]

There's definitely something going on in the background. After 5-7 days my latency goes way up and it slows everything down and I start getting much more dead/orphans. By 9 days p2pool goes almost all dead work. A reboot/restart fixes it all. Instantly. I'd suggest just putting in a switch or script that makes p2pool restart ever 24-36 hours as a temporary "fix/workaround"

+1

My Memory gets blown up... and my income goes down....