Author

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

hero member
Activity: 798
Merit: 1000

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,


While a low number of connections may save bandwidth, wouldn't it possibly have the side-effect of making the Bitcoin network less resilient?

I guess I will see how much bandwidth is used when I finally get my node up.

yeah, but if you are trying to run a node locally and are bandwidth starved, that's something you should do.  

otherwise you'll either randomly connect to an outgoing peer that is missing part of the block chain or have one connect to you.  then your upstream is saturated

i think it's not so bad in other parts of the world, but in the US, you really get gimped on upstream

Not all of us... I've got 75down/35up rated (typically 86down/39up actual).  FiOS kicks a$$.

Running a local node at galactica.geekgalaxy.com:9332  
Any tips? Wink
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com

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,


While a low number of connections may save bandwidth, wouldn't it possibly have the side-effect of making the Bitcoin network less resilient?

I guess I will see how much bandwidth is used when I finally get my node up.

yeah, but if you are trying to run a node locally and are bandwidth starved, that's something you should do.  

otherwise you'll either randomly connect to an outgoing peer that is missing part of the block chain or have one connect to you.  then your upstream is saturated

i think it's not so bad in other parts of the world, but in the US, you really get gimped on upstream
legendary
Activity: 1008
Merit: 1001
Let the chips fall where they may.

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,


While a low number of connections may save bandwidth, wouldn't it possibly have the side-effect of making the Bitcoin network less resilient?

I guess I will see how much bandwidth is used when I finally get my node up.
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
14iVxhdTHgog4nU6DmRzEmuXvJ2PxgqQ3w

7.8% orphans, 9.1% DOA over 375 shares on what looks like a local node, despite the doa % (not sure why else it'd be on a roadrunner cable line)

pm me if you want to fix it

1QKkhvTNVWbg3w1CFCVDUrgWJ8w5iRWaNF

8.5% orphans over 610 shares on a node in Germany (!)       (ed: there's also a secondary issue here)

pm me if you want to fix it
member
Activity: 90
Merit: 10
Cheers for taking the time for to write that up zvs. It helps  to learn from others with experience.

--max-outgoing doesn't seem to exist on mine, is --outgoing-conns the same thing?  Running on Windows in case it matters.
Whoops.  No, I was just flat out wrong.  I just looked:

    p2pool_group.add_argument('--max-conns', metavar='CONNS',
        help='maximum incoming connections (default: 40)',
        type=int, action='store', default=20, dest='p2pool_conns')
    p2pool_group.add_argument('--outgoing-conns', metavar='CONNS',
        help='outgoing connections (default: 6)',
        type=int, action='store', default=10, dest='p2pool_outgoing_conns')


--outgoing-conns is the correct thing to use.  i've always just modified the source to change the settings.. not sure where I got --max-outgoing from...  and the --p2pool-node additions don't count towards that total

i'll edit the original message

Awesome thanks for the clarification!
donator
Activity: 798
Merit: 500
it a  fool idea

when i set btcaddress+256 i got a 99% reject!!!!!!!!!!!!!!!!!!11

256 is too high for 82GH/s.  I don't know where the double your hash rate idea came from.  Read here:

https://bitcointalksearch.org/topic/suggestion-for-how-to-choose-a-pool-difficulty-for-miners-274023

Or just let p2pool do it for you  Wink
hero member
Activity: 896
Merit: 1000
Code:
btcaddress+256
Should be ok.
thanks a lot,but i dont understand,why is
Code:
btcaddress+256
and
if i have another  82g avalon i also use btcaddress+256 ?
Quote
it a  fool idea

when i set btcaddress+256 i got a 99% reject!!!!!!!!!!!!!!!!!!11

that'd be based off your hardware then,  i thought the avalons could handle variable difficulty.  maybe it's considering sub 256 stuff as rejects

Avalons use cgminer which handles variable difficulty fine. At least I can confirm mine does (I don't set difficulty manually but p2pool adjusts difficulty automatically anyway and I don't get any suspicious reject %).
zkfq123 probably has a problem specific to his/her setup, but his/her bug report isn't really helpful (google "how to report a bug").
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
Cheers for taking the time for to write that up zvs. It helps  to learn from others with experience.

--max-outgoing doesn't seem to exist on mine, is --outgoing-conns the same thing?  Running on Windows in case it matters.
Whoops.  No, I was just flat out wrong.  I just looked:

    p2pool_group.add_argument('--max-conns', metavar='CONNS',
        help='maximum incoming connections (default: 40)',
        type=int, action='store', default=20, dest='p2pool_conns')
    p2pool_group.add_argument('--outgoing-conns', metavar='CONNS',
        help='outgoing connections (default: 6)',
        type=int, action='store', default=10, dest='p2pool_outgoing_conns')


--outgoing-conns is the correct thing to use.  i've always just modified the source to change the settings.. not sure where I got --max-outgoing from...  and the --p2pool-node additions don't count towards that total

i'll edit the original message
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
Code:
btcaddress+256
Should be ok.
thanks a lot,but i dont understand,why is
Code:
btcaddress+256
and
if i have another  82g avalon i also use btcaddress+256 ?
Quote
it a  fool idea

when i set btcaddress+256 i got a 99% reject!!!!!!!!!!!!!!!!!!11

that'd be based off your hardware then,  i thought the avalons could handle variable difficulty.  maybe it's considering sub 256 stuff as rejects
newbie
Activity: 49
Merit: 0
Code:
btcaddress+256
Should be ok.
thanks a lot,but i dont understand,why is
Code:
btcaddress+256
and
if i have another  82g avalon i also use btcaddress+256 ?
[/quote]

it a  fool idea

when i set btcaddress+256 i got a 99% reject!!!!!!!!!!!!!!!!!!11
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Cheers for taking the time for to write that up zvs. It helps  to learn from others with experience.
Now if people will do it... =p

Also, you might have high latency to those three p2pools I suggested to --addnode, just look at the list on http://p2pool-nodes.info/ and find some other well connected ones if so.  I wouldn't add any w/ an average getblocktemplate time of over .3s, since those are probably overloaded as is... well, either that, or they may be experiencing this issue (as referenced above):



immediate action is recommended in such cases

... and I thought I'd add that most orphans directly after a block is solved are unavoidable, as p2pool will (usually) orphan the share that was directly before the block solve (or it may have been a few seconds after, which is the reason for it doing that... but 95% of the time it's a legit share that just gets jacked). 
Amiga FTW Smiley
member
Activity: 90
Merit: 10
Cheers for taking the time for to write that up zvs. It helps  to learn from others with experience.

--max-outgoing doesn't seem to exist on mine, is --outgoing-conns the same thing?  Running on Windows in case it matters.
legendary
Activity: 986
Merit: 1027
Miner-Control.de Pooler
Add a Pool Node to the P2Pool Network....

e.g. On a Pool Node all miners works on one p2pool share.

And make a new option wallet-address/+P0.02 for payouts with 0.02 BTC or auto payout after one week.

BTC payout from pool wallet to miner-wallet based on the shares to the node.

So can small miners connet to the p2pools.

Without that, a miner needs over 50 GHs to make a p2pool share... thats to high for small miners....
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
I've seen various suggestions for setting up workers with p2pool, but want to better understand the 3 main paths I've seen so far.

What are the relative Advantages and Disadvantages to the following for the Miner? The local Pool? the P2Pool Network as a whole?
Using 15Ghs as an example...

Method 1: add +N to worker address where N = double your miner's hashrate
Example: worker_address+30
Adv/Disadv - Miner?
Adv/Disadv - Local Pool?
Adv/Disadv - P2Pool Network?

Method 2: add /N+1 to worker address where N = 210xHashrate
Example: worker_address/3150+1
Adv/Disadv - Miner?
Adv/Disadv - Local Pool?
Adv/Disadv - P2Pool Network?

Method 3: just use worker_address
Example: worker_address
Adv/Disadv - Miner?
Adv/Disadv - Local Pool?
Adv/Disadv - P2Pool Network?


I've been using Method #2 for awhile to supposedly help lower speed miners while keeping P2Pool shares flowing with P2Pool diff 1 work, but my understanding on this may not be right.

bitcoinaddress/x+y

Yeah, the x variable wouldn't do anything unless it was over the base share difficulty which is at 216k right now.  At 15ghash, you shouldnt increase that unless, eh, you're feeling really lucky.  Would have to be over 216,000 to have any impact ..

The Y amount is just used to calculate your hashrate on the webpage.  With pushpool it mattered a lot more, with stratum it doesn't really matter much.  I guess it consumes a little more bandwidth if you're using 1 share difficulty instead of 10-20.  You might as well use the higher #...

hero member
Activity: 798
Merit: 1000
I've seen various suggestions for setting up workers with p2pool, but want to better understand the 3 main paths I've seen so far.

What are the relative Advantages and Disadvantages to the following for the Miner? The local Pool? the P2Pool Network as a whole?
Using 15Ghs as an example...

Method 1: add +N to worker address where N = double your miner's hashrate
Example: worker_address+30
Adv/Disadv - Miner?
Adv/Disadv - Local Pool?
Adv/Disadv - P2Pool Network?

Method 2: add /N+1 to worker address where N = 210xHashrate
Example: worker_address/3150+1
Adv/Disadv - Miner?
Adv/Disadv - Local Pool?
Adv/Disadv - P2Pool Network?

Method 3: just use worker_address
Example: worker_address
Adv/Disadv - Miner?
Adv/Disadv - Local Pool?
Adv/Disadv - P2Pool Network?


I've been using Method #2 for awhile to supposedly help lower speed miners while keeping P2Pool shares flowing with P2Pool diff 1 work, but my understanding on this may not be right.
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
Cheers for taking the time for to write that up zvs. It helps  to learn from others with experience.
Now if people will do it... =p

Also, you might have high latency to those three p2pools I suggested to --addnode, just look at the list on http://p2pool-nodes.info/ and find some other well connected ones if so.  I wouldn't add any w/ an average getblocktemplate time of over .3s, since those are probably overloaded as is... well, either that, or they may be experiencing this issue (as referenced above):



immediate action is recommended in such cases

... and I thought I'd add that most orphans directly after a block is solved are unavoidable, as p2pool will (usually) orphan the share that was directly before the block solve (or it may have been a few seconds after, which is the reason for it doing that... but 95% of the time it's a legit share that just gets jacked). 
hero member
Activity: 1246
Merit: 501
either their bandwidth is saturated or their Amiga is having issues.  

Impossible.  Amigas never have issues.  Until the Guru Meditation arrives.
sr. member
Activity: 257
Merit: 250
Cheers for taking the time for to write that up zvs. It helps  to learn from others with experience.
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
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
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
Can we possibly have a standard operating procedure regarding , host requirements and node installation , tips to help people run on p2pool as efficiently as possible. Is my GBT latency too high ? Does it matter ? Why it matters. My node shows X kb incoming X kb outgoing , is that ideal ? , if not why. Do I need lots of RAM and unlimited bandwidth.



Here is a snapshot of my rig on p2pool , can I do anything to improve my efficiency.

Is that a local p2pool?  Is all the DOA caused by the specific ASIC equipment?  I can mine to remote host (~200ms to Germany) and get about 1-2% DOA, w/ vid card (200ms flat should average out to less than 1% DOA (.667%), but you have some local & remote delay, maybe multiple workers, etc)..  an overloaded CPU could cause more DOA also

i think you got lucky with zero orphans and just 6 outgoing connections, unless maybe those 6 outgoing connections were handpicked by you... re:  set the max outgoing to zero and using --p2pool-node for all 6

Jump to: