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. 
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 589. (Read 2591920 times)
February 20, 2013, 08:37:59 PM
February 20, 2013, 07:59:58 PM
How do I make p2pool work for both bitcoin and litecoin simultanously?
February 20, 2013, 03:16:50 PM
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
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.
Quote from: KC_Atlanta
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
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.
February 20, 2013, 12:34:49 AM
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)." ?
"
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)." ?
February 19, 2013, 08:37:12 PM
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
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.
Quote from: KC_Atlanta
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
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
February 19, 2013, 08:34:58 PM
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.
Quote from: KC_Atlanta
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
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
February 18, 2013, 02:50:53 PM
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.
February 16, 2013, 10:21:16 AM
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?
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.
February 16, 2013, 12:01:06 AM
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
-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
February 15, 2013, 11:52:15 PM
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
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
February 15, 2013, 11:46:35 PM
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?
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.
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
February 15, 2013, 11:32:57 PM
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
February 15, 2013, 06:27:47 PM
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?
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.
February 15, 2013, 01:56:58 PM
I am expecting to get out of the bitcoin mining business sooner that later. At the same time, I am still a fan of p2pool and would be happy to continue to maintain p2pool.info long after I am no longer personally mining. However, as I shut down my home mining operation and all the servers running in my house that support that operation, I'd like to remove the dependency p2pool.info has on server(s) running inside my house, and I'm hoping someone in the p2pool community can help.
What p2pool.info needs is access to a bitcoind server's RPC interface. For security reasons, ideally this would be a bitcoind instance that had an empty wallet that had never been used.
These are the RPCs that p2pool.info uses:
* getblockcount
* getdifficulty
* getblockhash
* getblock
* getrawtransaction
As for bitcoin version, it needs to be at least 0.7 as some of the RPCs above were new in 0.7. If it happens to be running a version of 0.8 or the GIT tree with the new optimized storage structure, it needs to be running with the txindex=1 configuration setting because p2pool.info needs to be able to look at all generation transactions for all blocks.
I'm hoping that someone here is already running bitcoind in a datacenter somewhere and would be willing to let p2pool.info's web server connect to it to watch for p2pool blocks. If you have a bitcoind server whose RPC interface is accessible over the internet and that you'd be willing to give me access to, please let me know.
would it have fallbacks? my bitcoind is on most of the time, but not always..What p2pool.info needs is access to a bitcoind server's RPC interface. For security reasons, ideally this would be a bitcoind instance that had an empty wallet that had never been used.
These are the RPCs that p2pool.info uses:
* getblockcount
* getdifficulty
* getblockhash
* getblock
* getrawtransaction
As for bitcoin version, it needs to be at least 0.7 as some of the RPCs above were new in 0.7. If it happens to be running a version of 0.8 or the GIT tree with the new optimized storage structure, it needs to be running with the txindex=1 configuration setting because p2pool.info needs to be able to look at all generation transactions for all blocks.
I'm hoping that someone here is already running bitcoind in a datacenter somewhere and would be willing to let p2pool.info's web server connect to it to watch for p2pool blocks. If you have a bitcoind server whose RPC interface is accessible over the internet and that you'd be willing to give me access to, please let me know.
could you do this forrestv?
February 15, 2013, 01:20:51 PM
I am expecting to get out of the bitcoin mining business sooner that later. At the same time, I am still a fan of p2pool and would be happy to continue to maintain p2pool.info long after I am no longer personally mining. However, as I shut down my home mining operation and all the servers running in my house that support that operation, I'd like to remove the dependency p2pool.info has on server(s) running inside my house, and I'm hoping someone in the p2pool community can help.
What p2pool.info needs is access to a bitcoind server's RPC interface. For security reasons, ideally this would be a bitcoind instance that had an empty wallet that had never been used.
These are the RPCs that p2pool.info uses:
* getblockcount
* getdifficulty
* getblockhash
* getblock
* getrawtransaction
As for bitcoin version, it needs to be at least 0.7 as some of the RPCs above were new in 0.7. If it happens to be running a version of 0.8 or the GIT tree with the new optimized storage structure, it needs to be running with the txindex=1 configuration setting because p2pool.info needs to be able to look at all generation transactions for all blocks.
I'm hoping that someone here is already running bitcoind in a datacenter somewhere and would be willing to let p2pool.info's web server connect to it to watch for p2pool blocks. If you have a bitcoind server whose RPC interface is accessible over the internet and that you'd be willing to give me access to, please let me know.
would it have fallbacks? my bitcoind is on most of the time, but not always.. What p2pool.info needs is access to a bitcoind server's RPC interface. For security reasons, ideally this would be a bitcoind instance that had an empty wallet that had never been used.
These are the RPCs that p2pool.info uses:
* getblockcount
* getdifficulty
* getblockhash
* getblock
* getrawtransaction
As for bitcoin version, it needs to be at least 0.7 as some of the RPCs above were new in 0.7. If it happens to be running a version of 0.8 or the GIT tree with the new optimized storage structure, it needs to be running with the txindex=1 configuration setting because p2pool.info needs to be able to look at all generation transactions for all blocks.
I'm hoping that someone here is already running bitcoind in a datacenter somewhere and would be willing to let p2pool.info's web server connect to it to watch for p2pool blocks. If you have a bitcoind server whose RPC interface is accessible over the internet and that you'd be willing to give me access to, please let me know.
February 15, 2013, 12:07:49 PM
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
February 15, 2013, 12:05:57 PM
Something went wrong and memory jumped from 200MB to 1GB overnight.
Please report your python twisted version. Memory was only fixed for twisted 11.2 and onwards.Code:
$ uname -a
Linux fedora 3.6.7-4.fc16.i686.PAE #1 SMP Tue Nov 20 20:51:24 UTC 2012 i686 i686 i386 GNU/Linux
Code:
python
import twisted
print twisted.version
Code:
$ python
Python 2.7.3 (default, Jul 24 2012, 11:41:34)
[GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import twisted
>>> print twisted.version
[twisted, version 11.0.0]
>>>
Older... sob, I'm gonna update it asap.
Thanks.
spiccioli
February 15, 2013, 11:55:03 AM
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).
February 15, 2013, 11:54:36 AM
Something went wrong and memory jumped from 200MB to 1GB overnight.
Please report your python twisted version. Memory was only fixed for twisted Code:
$ uname -a
Linux fedora 3.6.7-4.fc16.i686.PAE #1 SMP Tue Nov 20 20:51:24 UTC 2012 i686 i686 i386 GNU/Linux
Code:
python
import twisted
print twisted.version
February 15, 2013, 11:52:44 AM
I am expecting to get out of the bitcoin mining business sooner that later. At the same time, I am still a fan of p2pool and would be happy to continue to maintain p2pool.info long after I am no longer personally mining. However, as I shut down my home mining operation and all the servers running in my house that support that operation, I'd like to remove the dependency p2pool.info has on server(s) running inside my house, and I'm hoping someone in the p2pool community can help.
What p2pool.info needs is access to a bitcoind server's RPC interface. For security reasons, ideally this would be a bitcoind instance that had an empty wallet that had never been used.
These are the RPCs that p2pool.info uses:
* getblockcount
* getdifficulty
* getblockhash
* getblock
* getrawtransaction
As for bitcoin version, it needs to be at least 0.7 as some of the RPCs above were new in 0.7. If it happens to be running a version of 0.8 or the GIT tree with the new optimized storage structure, it needs to be running with the txindex=1 configuration setting because p2pool.info needs to be able to look at all generation transactions for all blocks.
I'm hoping that someone here is already running bitcoind in a datacenter somewhere and would be willing to let p2pool.info's web server connect to it to watch for p2pool blocks. If you have a bitcoind server whose RPC interface is accessible over the internet and that you'd be willing to give me access to, please let me know.
Can't you just use Blockchain.info for this? What p2pool.info needs is access to a bitcoind server's RPC interface. For security reasons, ideally this would be a bitcoind instance that had an empty wallet that had never been used.
These are the RPCs that p2pool.info uses:
* getblockcount
* getdifficulty
* getblockhash
* getblock
* getrawtransaction
As for bitcoin version, it needs to be at least 0.7 as some of the RPCs above were new in 0.7. If it happens to be running a version of 0.8 or the GIT tree with the new optimized storage structure, it needs to be running with the txindex=1 configuration setting because p2pool.info needs to be able to look at all generation transactions for all blocks.
I'm hoping that someone here is already running bitcoind in a datacenter somewhere and would be willing to let p2pool.info's web server connect to it to watch for p2pool blocks. If you have a bitcoind server whose RPC interface is accessible over the internet and that you'd be willing to give me access to, please let me know.
Jump to: