p2pool problem:
People see this 20% DOA/stale shit and are like "OMG, 20% less monies!1", instead of saying 'lol, someone has some shitty setup that's improving my relative efficiency, they are losing hundreds of thousands of ugandan dollars'. too bad that in the long run, you want people to not be dumb and be able to set up p2pool properly.
tip #1: TI-99's and Commodore 64's are not adequate to run p2pool servers on. either spend a couple hundred bucks getting a subpar computer that can run p2pool decently, pay $10 or $20 to OVH for server hosting, or (gasp) mine on a remote server. there are plenty out there that are at 0%. mine is at 1%, but that 80% efficiency you're getting to your Commodore is a lot worse than paying a 1% fee. try
http://p2pool-nodes.info/ and
http://p2pool.hostv.pl/tip #2:
run p2pool with
./run_p2pool.py (any other flags) --p2pool-node 5.9.24.81 --p2pool-node 198.12.127.2 --p2pool-node 64.120.253.194 --outgoing-conns 5
that means if all 3 of those servers are up (and not full on incoming connections, being DDoSed, DoSed, or being raided by the Interpol for stealing massive amounts of bitcoins), you'll have 8 outgoing connections. if none are up, you'll have 5. default is 6. that's not bad, right? if you have enough bandwidth, then allow some incoming connections. i think 40 is too much, but 20-25 is ok.
tip #3: after about 30 minutes, look at your share history. see which nodes you're actually receiving shares from. if they're incoming connections, test port 9333 by trying to telnet to it first. include those in your --p2pool-node list.
tip #4: high getblocktemplate latency isn't a huge deal... except it's symptomatic of also having horrible performance issues, probably either RAM or CPU related and also often caused by having an old version of bitcoind, filled with horse staple battery transactions. migrate off of the Atari 400 and/or fix your bitcoind, and/or reduce maxblocksize from 1000000 to 500000 or 250000.
tip #5: use xxx:9332/pings .. if someone is at 2000ms latency, then either their bandwidth is saturated or their Amiga is having issues. tcpkill them for a new connection.. somewhat related, use xxx:9332/peer_txpool_sizes to see all the people that are trying to help out horse staple battery get those transactions processed
tip #6: don't pay 2% fees to a pool with 70% efficiency
aha! forgot to mention bitcoind
tip #7: compile bitcoind with outgoing connections of 1, run bitcoind with listen=1, maxconnections=2, with one node on connect... well, that's what I do, since I can monitor it constantly.. you'd probably want to change maxconnections to 3 or 4, in case one of the nodes craps out, be it due to the Interpol, cult of the dead cow, or whatever else. an example conf file,
server=1
daemon=1
rpcuser=bleat
rpcpassword=bleatbleat
#datadir=/home/zevus/ramdisk
maxconnections=2
rpcallowip=127.0.0.1
rpcport=31337
port=31338
#timeout=150
#dbcache=xxx
par=8
listen=1 (<--- necessary cause of p2pool)
gen=0
upnp=0
keypool=0 (you don't store bitcoins on this wallet, right? right?)
dns=0
detachdb=1
logtimestamps=1
bantime=30
banscore=501
#blockminsize=0
#blockprioritysize=0
blockmaxsize=250000
#Myself
connect=5.9.24.81
#connect=198.12.127.2
#connect=64.120.253.194
..... now, I don't think w/o compiling it yourself you can modify the 8 outgoing connections? i think in that case, maxconnections of 9, listen=1, and just using 'connect' and firewalling the incoming bitcoind port would still work? it's not supposed to connect to other nodes, anyway... (besides the one you use connect= on, which is the difference between that and addnode)
ed: fixed --max-outgoing to real flag of --outgoing-conns
