Quote from: manifold on April 02, 2012, 08:22:28 AM

Ahh.. ok no i have no static ip address and I don't even run 24/7... ;-)

static IP isn't necessary as long as your IP address is relatively stable. Looking at the incoming peers chart it looks like >8 hours is where # of incoming peers rapidly increases. For most users DHCP leases tend to be 14 days or longer (I have the same dynamic IP address as I did last year) so there is no need for a static IP address.

Keeping p2pool running is important. nodes rank other nodes based on how long they have seen them. If you are always seen as a very short lived and unstable node it is unlikely any node will ever voluntarily connect to you (as there are other better options available). Nodes are oppertunistic (as they should be). They seek out the best possible nodes.

Currently looking at the code it looks like longevity is the only factor is how "good" a node is. That probably could be expanded to include things like latency, share notification (what % of shares did that node report), bad shares (nodes should verify shares before forwarding), version reported, etc.

One thing to keep in mind if that even if you don't mine 24/7 you can keep p2pool & bitcoind running 24/7 (both use minimal resources & bandwidth).

Quote from: Ente on April 02, 2012, 07:35:54 AM

Some people suggested that a node has to be "reliable" for people to connect to it. The node is running 24/7, but the internet connection reconnects every 24 hours. Maybe this is the reason.

If the IP address changes then other nodes will see you as a new 0 minute node. Nodes identify other nodes based on IP address. Theoretically that could be changed but I don't think it is a pressing concern. One way I could see that changing is by nodes identifying themselves by a public key. This would allow nodes to retain information on other nodes even when IP address changes.

A simpler patch would be to have the node list include dns entries. Then using dyndns one could always be the same url despite IP address changing. Personally I like the public key method better (prevents the need for frequent dns lookups) but using dns is much simpler.