Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 297. (Read 2591971 times)

Change to the Relay Network region closest to your p2pool node:

ExecStart=/bin/java -Xmx100m -jar /PATH/TO/RelayNodeClient.jar public.YOURRELAYREGION.relay.mattcorallo.com:8335

Someone asked me this in email so I figured I'd copy the response here:

....

Someone asked me this in email so I figured I'd copy the response here:

> Someone on the forum wanted me to ask if there's any advantage to
> running java RelayNodeClient versus simply connecting bitcoind to the
> Relay Network via "addnode"?

Yes, there is quite a huge advantage to it - namely if you connect to
your nearest Relay Network addnode you get the blocks relayed as normal
(ie the whole block is sent again), if you use the relay client (which,
despite it being java uses almost no memory/CPU, and can be easily kept
from growing its heap with -Xmx100m) the only thing relayed over the
wire is transactions you havent seen before, so it can (more often than
not) fit the entire block in one TCP packet. Also, addnode does not
reconnect very aggressively and, as such, if the relay node gets
restarted due to upgrade or whatever, you will likely lose the
connection and not end up reconnecting for a day or so, however the
relay network client will reconnect almost immediately.

If there is enough demand, I've been considering rewriting the relay network client in Rust/C++/whatever for those with concerns.

Matt

If you're running RelayNodeClient.jar it looks like it's time to upgrade. I got the following email from the author, Matt Corallo:

Sorry for the inconvenience, please upgrade your relay client node as an
incompatible server change was made . Still, fitting most blocks in
one TCP packet is probably worth it.

I'm waiting to hear back from him to see if he will be producing a .jar file, right now there's only RelayNodeClient.java.

So much fail.... *sigh*  And people wonder why p2pool doesn't get higher adoption rates with answers like this.

You CAN use a public P2Pool node, take a look at this page for a listing of some of them - http://p2pool-nodes.info/ - you can sort by country, latency, etc.  Just find a couple geographically close to you and ping them... the lower the ping (latency), the better off you will be.

It is absolutely NOT stupid to mine on a remote p2pool node, especially if you have one close enough to you.  If you aren't close enough to a public node it could affect your performance, so it might be more wise to look at building your own local node if you have the capability, but some folks don't have the resources to do that.  It's all about your comfort level and resources.

The main issue with p2pool is latency - how quickly your miners can communicate to the node you're mining on.  The lower the latency, the less DOA rate you will have.  The less DOA you have the better chance you have of getting good shares, and thus payouts.  This is why it's RECOMMENDED to bring up your own p2pool node locally, because obviously the miners are right next to the node.

There's a bunch more to go into with DOA, shares, stales/orphans and how in general it works if you want to.  The bottom line is that all things equal, over time, you should see at least equal if not better payouts on p2pool versus others, as long as you have a decent hashrate, which I personally consider over 600GH/s.  Judging from your payouts I'd say you have about 1.2-1.5 TH/s, which should be plenty fine.

To configure it's simple.  Once you find a pool node it would look like this-

Pool: stratum+tcp://ip.add.ress.here:9332
Pool worker:  {your bitcoin payment address here}
Pool password:  anything123

I would suggest finding at least 2 P2Pool nodes for pool1 and pool2, and then put your original proprietary node in for pool3.  This way you're covered with failovers and backup in case any of the p2pool nodes go down.

And, no matter what pool node you mine on, if you keep your payment address the same (the pool worker), your shares and payouts will "follow" you to whatever node you're on, so you won't lose any mining time if you failover to another node.

Hope this helps to get you started.  Read up on the last 20-30 pages of this thread if you can at least, and post more questions, most folks here are pretty helpful.

In the short term (i.e. "per day") variance will be much higher. At 1.5 TH/s and the current pool rate you should expect a payout from each block the pool finds (after you have a share in the chain), here is the closest example to 1.5 TH/s I could find on my node, the payouts per block should give you an idea of what to expect:

http://minefast.coincadence.com/miner.php?id=1JPVPkdnpYYwyYic51id6anMBn9weHwVV9


I disagree.

While setting up your own local node is ideal, and how p2pool is intended to be used, it is not a requirement, and mining on a public node is a great way to get started with p2pool.

There are many 0% fee public nodes available to give the pool a try, I would recommend committing for a minimum of 4 days. P2pool uses a PPLNS payout system and the share chain is ~3 days long, any amount of time under that will not give you accurate results.

In picking a public node latency (the time it takes your data to reach the server) is very important. Find your 2-3 closest nodes by using ping and use those in your miner configuration.

My node is in the US east, for other nodes you can explore here:

http://p2pool-nodes.info/

Patience is very important with p2pool. Once you are connected to your closest node for a couple hours check the stats, as long as your DOA rate is lower then the pool average your are doing just fine. Then sit back and let your miners do their thing. Again I would say 4 days is a minimum.

Use:   "bitcoind getaddednodeinfo true"

I too have noticed an increase in efficiency since using Matts "backbone" - by simply adding it to the .conf file. Is there a reason why you decided to use the jar file? I hate using anything java - it's such a resource hog.

So I did this yesterday, downloaded the jar and ran it on the commandline using nohup.  Eventually will probably add it into the p2pool startup script so it's all handled automatically.  Logfile shows decent transaction activity.

Since server restart just over 24 hours ago, my efficiency hasn't dipped below 110% (that I've seen), and is currently hitting 114.5% ... .  31 shares, 1 orphan, no dead. 

Previously I was bouncing between 95-105%, lately a little under 100% a bit with about a 14% share loss.

So, we'll see how this runs over time... if it keeps up the way it is, then it's a big thumbs up in my book.

EDIT - although it seems to be a bit of a resource hog - 11G of virt RAM according to top.  Then again that could be just usual Java bloat and not necessarily this program since it really isn't much.

I pointed out her/his inaccuracies about p2pool.info previously here:

https://bitcointalksearch.org/topic/m.8467067

Some trolls just refuse to listen.........