[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[PatMan]

Hey guys, any first impressions on Matts fork - how's it running? Well pleased it's in python too.....

[1714053244]

1714053244

[1714053244]

1714053244

[windpath]

Check out https://github.com/TheBlueMatt/p2pool. Once I get some testing I'll pull request that and see if I can wake forrest from his drug-induced slumber.

...
How can I verify p2pool has connected to the relay network?

Remove the addnode and run p2pool with --relay-network public.YOUR_REGION.relay.mattcorallo.com

Thanks Matt!

Code:

Initializing work...
RELAY NETWORK: Connected to relay node with protocol version prioritized panther
RELAY NETWORK: Connected to bitcoind with protocol version 70002
RELAY NETWORK: Finished connect handshake with bitcoind
     ...success!

[phelix]

How often does p2pool query namecoind getblockaux? I would like to make sure the namecoind internal recalculation time step makes sense.

Can anyone answer this for phelix?  I haven't been able to dig through the code thoroughly to find any polling time. You can start in work.py to see the calls to get the merged work (around line 62):

Code:

       # MERGED WORK

        self.merged_work = variable.Variable({})

        @defer.inlineCallbacks
        def set_merged_work(merged_url, merged_userpass):
            merged_proxy = jsonrpc.HTTPProxy(merged_url, dict(Authorization='Basic ' + base64.b64encode(merged_userpass)))
            while self.running:
                auxblock = yield deferral.retry('Error while calling merged getauxblock on %s:' % (merged_url,), 30)(merged_proxy.rpc_getauxblock)()
                self.merged_work.set(math.merge_dicts(self.merged_work.value, {auxblock['chainid']: dict(
                    hash=int(auxblock['hash'], 16),
                    target='p2pool' if auxblock['target'] == 'p2pool' else pack.IntType(256).unpack(auxblock['target'].decode('hex')),
                    merged_proxy=merged_proxy,
                )}))
                yield deferral.sleep(1)
        for merged_url, merged_userpass in merged_urls:
            set_merged_work(merged_url, merged_userpass)

        @self.merged_work.changed.watch
        def _(new_merged_work):
            print 'Got new merged mining work!'

Thanks for pointing me to the right place. Looks like it is sleeping one seconds between queries. From some other part in the code it seems the timeout is 5 seconds and it will retry up to a 30 times. OK.

[PatMan]

Looks like the new Tube miners can be added to the "not compatible" list of miners.......

Apparently, they only work with ghash  

I absolutely definitely won't be getting one of those then......

[coinme.info]

Hey guys, any first impressions on Matts fork - how's it running? Well pleased it's in python too.....

Doesn't seem to work on a Windows Server 2012 R2.

Freshly installed all the requirements and I can run P2Pool ok using Matts source from Github including merge mining.

However once I add the --relay-network public.us-west.relay.mattcorallo.com to the startup I get this.



I took out the merged mining stuff as well just in case and ran with just plain jane BTC p2pool, same thing.

Any ideas?

Back to using 13.4 precompiled from forrestv with the java relay which works well BTW.

[windpath]

Hey guys, any first impressions on Matts fork - how's it running? Well pleased it's in python too.....

Doesn't seem to work on a Windows Server 2012 R2.

Freshly installed all the requirements and I can run P2Pool ok using Matts source from Github including merge mining.

However once I add the --relay-network public.us-west.relay.mattcorallo.com to the startup I get this.

[IMG ]https://i.imgur.com/fFysLTL.jpg[/img]

I took out the merged mining stuff as well just in case and ran with just plain jane BTC p2pool, same thing.

Any ideas?

Back to using 13.4 precompiled from forrestv with the java relay which works well BTW.

So far its running well on my local Mac, 1 share found with good luck.

Have not moved it to the production node yet, however production node runs Ubuntu and Matt maintains the PPA so I imagine no problems...

[Matt Corallo]

Hey guys, any first impressions on Matts fork - how's it running? Well pleased it's in python too.....

Doesn't seem to work on a Windows Server 2012 R2.

Freshly installed all the requirements and I can run P2Pool ok using Matts source from Github including merge mining.

However once I add the --relay-network public.us-west.relay.mattcorallo.com to the startup I get this.

I took out the merged mining stuff as well just in case and ran with just plain jane BTC p2pool, same thing.

Any ideas?

Back to using 13.4 precompiled from forrestv with the java relay which works well BTW.

Strange, that flag is explicitly stated in the python docs...can you try the latest push?

[coinme.info]

Hey guys, any first impressions on Matts fork - how's it running? Well pleased it's in python too.....

Doesn't seem to work on a Windows Server 2012 R2.

Freshly installed all the requirements and I can run P2Pool ok using Matts source from Github including merge mining.

However once I add the --relay-network public.us-west.relay.mattcorallo.com to the startup I get this.

I took out the merged mining stuff as well just in case and ran with just plain jane BTC p2pool, same thing.

Any ideas?

Back to using 13.4 precompiled from forrestv with the java relay which works well BTW.

Strange, that flag is explicitly stated in the python docs...can you try the latest push?

Hi Matt

Looks like the latest update you made has fixed it.

Tried it first with just BTC and then with merged mining options added to start up.



Can see the connection on network stats as well.

Image   PID   Address   Send (B/sec)   Receive (B/sec)   Total (B/sec)
python.exe   3500   rn-sea1.relay.mattcorallo.com   0   423   423

Whatever you changed made the web pages load at normal speed as well.
The were very slow with the previous sources.

I need to run it for while to see if the GBT latency can equal or better the 13.4 version with the java as it was was 100ms higher in the previous try.

FYI running:
Python 2.7.8
Twisted: 14.0.0
Zope.Interface: 4.1.1
python win32 api: 219
python win32 api wmi wrapper: 1.4.9

Found I had to install the 32bit versions as there is no python win32 api wmi wrapper for 64bit and it won't install to the 64bit python dir.
Found this out on a 2008 server so just did plain 32bit python install as per your readme.

PS.. looks like GBT latency is settling in to what I was getting with 13.4 and java.

:-)

[CartmanSPC]

Found I had to install the 32bit versions as there is no python win32 api wmi wrapper for 64bit and it won't install to the 64bit python dir.
Found this out on a 2008 server so just did plain 32bit python install as per your readme.

You can get the 64 bit version to work but it's more effort than it's worth. I just do 32 bit as well.

[coinme.info]

Found I had to install the 32bit versions as there is no python win32 api wmi wrapper for 64bit and it won't install to the 64bit python dir.
Found this out on a 2008 server so just did plain 32bit python install as per your readme.

You can get the 64 bit version to work but it's more effort than it's worth. I just do 32 bit as well.

Good to know I wasn't overlooking something simple.

All it would need is for that python win32 api wmi wrapper to be updated to 64bit as all the other requirements have 64bit versions now.

GBT latency seems to be hovering around double the latency of the 13.4 version with the java relay.

Will run up 13.4 on the 2008 server with the java relay and compare the two overnight.

[EErik]

but hey guys what's going on? in the last 20 days p2p lost about 70 out of 250 active users / addesses (although the hashrate scores 1ph more), share diff of the pool is very high for those who do not have a farm, I personally with 3 th / s i have not done a good share in the last 20 hours ... there is no way of remodulating the share diff of p2p so that it is not so difficult for small-scale miners have a decent payout and a little more stable? ok accept the variance I can tolerate, but it seems clear that many users they are leaving the pool

E

[jedimstr]

Any update on the Namecoin merged mining issues?  I still have my Namecoin-qt down and continuing to MM with Devcoin and Ixcoin for now. 
Even worse, I'm doing this on a Mac so they don't have updated QT wallets yet so I'm back a few versions.

[phelix]

Any update on the Namecoin merged mining issues?  I still have my Namecoin-qt down and continuing to MM with Devcoin and Ixcoin for now. 
Even worse, I'm doing this on a Mac so they don't have updated QT wallets yet so I'm back a few versions.

With the latest improvements (https://github.com/namecoin/namecoin) the client can deal even with the extreme load the network has been experiencing recently (waves of 36MB of hundreds huge TXs in minutes, legit TXs though). We are still running some tests and working on binaries.

[pmorris]

Looks like the new Tube miners can be added to the "not compatible" list of miners.......

Basic question but do we know why some hardware isn't working well with p2pool?

I assume the hardware is driven by the same mining software like cgminer? Which is using the same protocols to talk to p2pool (stratum?) as GHash.

So is it something to do with polling frequency / latency that is p2pools fault or what?

[mdude77]

Looks like the new Tube miners can be added to the "not compatible" list of miners.......

Basic question but do we know why some hardware isn't working well with p2pool?

I assume the hardware is driven by the same mining software like cgminer? Which is using the same protocols to talk to p2pool (stratum?) as GHash.

So is it something to do with polling frequency / latency that is p2pools fault or what?

From what I've observed with my S2, it's not capable of restarting work every 30 seconds like p2pool requires.

M

[kgb2mining]

My node running Matt's fork with the embedded python-based relay code has been up for almost 24 hours now.  Initial reports seem that it's doing very well in general - over 110% efficiency for long periods, currently at 115%.  19 shares so far, all good - 0/0 orph/dead.

So, at the very least it's not hurting it at all, and hopefully is helping.  Will need to run longer to see how the share rates and efficiency do... I seem to see that as it goes along, getting past the 40 share mark is when I start seeing orphans/dead pop up.

On a side note tho - anyone seeing their DOA rates climb higher over the past week or so?  I was happily running around 3-4% DOA for the longest time but now I'm seeing it in the 6-8% range quite a lot.  Still better than the pool average, but I'm wondering if there's a core reason for the rates rising.  (and yes I've changed my S3's down from the default queue 4096, and I've tried 0 and 1 with neither being any majorly different).

[kgb2mining]

but hey guys what's going on? in the last 20 days p2p lost about 70 out of 250 active users / addesses (although the hashrate scores 1ph more), share diff of the pool is very high for those who do not have a farm, I personally with 3 th / s i have not done a good share in the last 20 hours ... there is no way of remodulating the share diff of p2p so that it is not so difficult for small-scale miners have a decent payout and a little more stable? ok accept the variance I can tolerate, but it seems clear that many users they are leaving the pool

E

My opinion is that a lot of the smaller miners are getting out of the game completely with difficulty rising and bitcoin prices falling or stagnant.  Also a lot of older hardware is dropping out, sometimes being replaced by smaller numbers of better equipment (remember miners means addresses, not people - I've got 5 different mining addresses running for just myself).  P2pool is seeing more of that because of the low usage rate to begin with.  I think the barrier to entry these days is at minimum an S1, more likely an S3, 400GH/s to get anything worth of a payout.

However, with 3TH/s you should be seeing more shares than that, at least one every 3-4 hours on average I would think.  Could be just variance - how long have you been up and running?  Typically when you first start with p2pool you should let it settle in for at least 3 days, more likely about a week before things start evening out and get more consistent.  I remember when I first switched over to p2pool it was very slow in the first few days even on 7TH/s, then by the next week we were doing well.

[kgb2mining]

Any update on the Namecoin merged mining issues?  I still have my Namecoin-qt down and continuing to MM with Devcoin and Ixcoin for now. 
Even worse, I'm doing this on a Mac so they don't have updated QT wallets yet so I'm back a few versions.

I pulled the latest repo and rebuilt namecoind late last week, and since then merged mining has been working fine on my node.  Now, I'm on Ubuntu LTS, no gui, and using the commandline versions only, built from source so not sure how that exactly compares to your setup.

[kgb2mining]

Looks like the new Tube miners can be added to the "not compatible" list of miners.......

Basic question but do we know why some hardware isn't working well with p2pool?

I assume the hardware is driven by the same mining software like cgminer? Which is using the same protocols to talk to p2pool (stratum?) as GHash.

So is it something to do with polling frequency / latency that is p2pools fault or what?

From what I've observed with my S2, it's not capable of restarting work every 30 seconds like p2pool requires.

M

I'll second that thought.  It's the 30-second work restart that is the problem.  Along with trying to figure out a way to better deal with the larger per-share diff for small miners, this has been one of the largest issues needing to be fixed.  However, I'm not sure where the solution lies if it's on the p2pool side, or more on the manufacturers/hardware.  Someone who's been around longer might have a more accurate explanation.

[RoadStress]

What configuration do I need to setup a node?

Edit: Anyone wants to help me setup an Iceland node?