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

Only if you are sure that you have bandwidth to spare. Increasing the number of connections is more a safety net in case some of your peers start to misbehave in a way P2Pool doesn't correct for automatically.


If you use hardcoded IP addresses you'll have to check regularly that they are still up and the best one for you. Probably best to let the network find the best one for you automatically (if you let your node run a long time it will eventually find stable nodes to connect to).

I'm not sure how Erupter blades behave with P2Pool, please give us a quick report when your reach 25 total shares then 50 (the more you have the more we will know for sure how your setup behaves).

Thanks, I'll let it continue to run untouched for a week (assuming good luck and no system crashes), before worrying about it more.  Good news, I'm now up to 10 shares, and still only 2 orphans.

Would increasing the number of outgoing connections help?  Thinking of setting it to 20 instead of 6.

Is it better to use hardcoded IP addresses on the command line, as suggested, or let the network discover more nodes over time?

Hopefully the only thing I'll have to worry about is how to afford the BTC to buy more ASIC's

As a new user of p2pool, he asked if it was normal to get 2 orphans out of 7 shares.

The answer is that it isn't normal, regardless of sample size

Please zvs, study probabilities instead of reacting with your gut feelings. Statistically it's normal... If it were 20 out of 70 then it would probably not be normal.

@Krellan, with your hashrate you'll have to wait for a whole week to know if your P2Pool configuration is OK. With 2 out of 7 you are not on the good side but you only have to remove 1 orphan from your current result to already be on par with the rest of the network.

no, 2 orphans out of 7 isn't normal

1 incoming connection after two nights is a bit low.  i've been running a node off and on (on for the last 6 months or so) and only have 15 incoming connections after 30 hours, so it isn't *that* abnormal.  i probably appear in everyone's addr file, your ip wouldn't in most.  also, a lot of people keep their clients going for days at a time, so these nodes will rarely open new outgoing connections

there are few incoming connections is because the client defaults to only 6 outgoing.  bitcoind has a lot more users that increase their connection count, there are probably 20+ that have 500+ connections and some that may have more than 1000 if they've modified it to use epoll

use --p2pool-node feature to add more outgoing connections outside of the default 6.  it's better that way, anyway.  you can pick the fastest ones and if they're public, look at their graphs and see if they actually send out any data.  i have a relay in jacksonville, FL at 199.48.164.36 and primary is in nuremberg at 5.9.24.81, another person I know & help set his up is in the canadian OVH center @ 198.100.149.53.  none are capped on incoming connections

I also received that last night.  Same IP address.  Big dump of hex digits, filling several pages in my scrollback.  Haven't banned yet, but thinking about it.

Perhaps an unrelated question: I'm new to P2Pool, having just set it up successfully two nights ago, when my Erupter arrived.  I'm seeing a high percentage of orphaned shares: after just over 24 hours, I now have 7 shares, but 2 of them are orphaned.  Is this normal?  I also noticed that I have only 1 incoming connection, my other 6 connections are outgoing.  My network connection is fine, no slowdown, ports are open.  Shouldn't I be getting more connections, especially incoming?  The port is open, the router is happy, my bitcoind has been steady at the configured maximum of 40 for some time now.  Is P2Pool less aggressive at promoting connections than bitcoind, or are there simply fewer users of the network?  I'm thinking that if I could get better connectivity to more nodes, I'd have fewer orphaned shares.

Other than that, it seems to be working very well.  I love the idea of P2Pool, having each node self-sufficient when it comes to making mining decisions, while still building on shares earned by other nodes so it remains fair for all.

Josh

Well I've got about 8 different ip addresses constantly submitting invalid hash, but I made the changes suggested above and their impact seems to be a lot smaller. Why are peers constantly submitting invalid hashes? Are they intentionally trying to spam the pool.. Am I being paranoid?

edit: After making the changes recommended above I unbanned all ip's that I had restricted and at first I was bombarded with a bunch of ip's submitting invalid hashes, but now that all of the hex data wasn't being sent (?) and  their impact seems minimized. Now it's down to just 3 addresses doing it over and over. It may be premature but THX...

 

Found it:
https://github.com/forrestv/p2pool/issues/111

I started seeing this several times the last few days, same ip address each time.

2013-06-17 07:34:41.231070 invalid hash for 222.77.182.12 'remember_tx' 248861 872ef55d d295582b

2013-06-18 02:56:52.970716 > Peer referenced transaction twice, disconnecting
2013-06-18 02:56:52.976697 Lost peer 222.77.182.12:2288 -

2013-06-18 05:57:08.320456 > Peer referenced transaction twice, disconnecting
2013-06-18 05:57:08.321727 > Peer referenced transaction twice, disconnecting
2013-06-18 05:57:08.323347 > Peer referenced transaction twice, disconnecting
2013-06-18 05:57:08.324393 Lost peer 222.77.182.12:4187

Also this over and over and over.... I understand I will loose peers but this same one is doing this all day.

2013-06-18 17:25:41.304199 Incoming connection to peer 193.92.82.143:50029 established. p2pool version: 1100 '11.2'
2013-06-18 17:25:42.299477 Sending 1 shares to 193.92.82.143:50029
2013-06-18 17:25:42.301697 Lost peer 193.92.82.143:50029 - Connection to the other side was lost in a non-clean fashion.

I'm just going to ban both ip addresses for now. Is this something to concern myself with or is this normal?

edit: My latency smoothed out after banning them...

once a minute?

if you're using a remote server, latency would be like #3 on the list of things to check

#1 would be fees, why pay a fee?  #2 would be orphans, how many orphans is this pool getting?  then #3 is latency, and mostly whether that latency is solid or if it's got major jitter and/or packetloss

example:  p2pool.org has 80 shares, 9 are orphans.  that's essentially equivalent to the same amount of DOA's you'd get from 1125ms latency

myths........

Ping is an accurate measure of latency to a remote computer system..

Ping from a 2rd party machine is a good indication of local to 3rd party.

Actual...
Pings are 'cheap' to deal with, hell some are even turned round by the infrastructure BEFORE they reach the machine, or even by the network stacks in the load balancing systems.

1.The ONLY way to get a TRUE measure of your latency is to fire up Wireshark or some other network analyzer.
Analyzers TRACE packets to the destination port and back again, they are also give an indication of how fast/ quickly the internal infrastructure is processing YOUR request.

2. CHECK the DNS redirection, for example 'BTCguild' bullshitted that they had 'local servers' in various places in the world....
What they actually had was 'redirectors', that just used DNS to redirect to the US..... (maybe its changed now)
This is NOT the same, and is actually MORE expensive  packet wise.....

3. you 'may' be able to gain a little speed per network packet by using an absolute ip address for the pool  instead of a domain name, but it is risky (some countries have SHITE DNS infrastructure)

4. You may not like it..... but choose a pool with a low Latency....

also be aware that there seems to be a new sort of 'ddos' attack, rather than taking the pool off line (which a client can detect and switch)
this attack seems to be able to  allow connections to the pool, but then causes most work to be rejected as 'unknown....'?
Possibly a redirect of the services to a 3rd party, ultimately since the client cannot detect this, the miner (person) is more likely to say F*** it and just not use the pool.. rather than loose the work with unproductive connections.

I have no clue :/

How long would our share time need to be extended to in order to make p2pool work well with BFL hardware?

No luck, just getting paid for last week. It's an average.

But yippee! And good because I just left to slush because of stupid jalapeno.

I'm really trying to resist posting in case I jinx it, but has something changed or have we just had really good luck - 5 blocks in the last 27 hours?

zvs posted an interesting try with 1MB blockmaxsize on his setup.

forrestv, could you read it and my following comment? We may have found why we disagreed on blockmaxsize settings: it seems that P2Pool takes some time generating work with high number of transactions which is made worse on public nodes where the work must be generated for several payout addresses.

On private nodes like mine (only allowing miners sharing the same payout address) this isn't really noticeable (probably <100ms even with maxed out blocks) but on public nodes like his the delays between each work generation add up and the last one can be seriously lagging (by several hundreds of ms and probably in some extreme cases several seconds).

Here's the post:

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

Could you at least confirm that we understood what happens in zvs' log correctly?

Yes I have a public direct one, you can look at my latency

GetBlockTemplate all takes place on your machine... no network involved.  If I had to guess, I'd say old bitcoind (as bitpop suggested), slow disks, or not enough memory.

If you are all up to date and don't want to upgrade your hardware, feel free to give my p2pool pool a try.  It is a new type of mining pool backed by a p2pool instance that is currently running at 115% efficiency (with a sample of 595 shares).  Basically, it pools shares from multiple users and submits them to p2pool under the same address.  It tracks the original address tied to each share and then I pay out proportionally whenever p2pool finds a share.  This allows for lower variance for smaller miners and will hopefully bring more hashpower to p2pool.  I don't have publicly available stats yet, but I'm working on it.  See this thread for more details: https://bitcointalksearch.org/topic/poolyrralnet-p2pool-backed-mining-pool-alpha-234841

There are of course other public p2pool instances if you have enough hashpower and prefer the more direct route.  My software is very new, and while it has been stable so far I can't make any guarantees.  Anyone willing to help test would be very much appreciated.

Just to Bitcoin locally