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

[stepkrav]

gyverlb, the thread in your signature is awsome. I've been diggin around and haven't found it till now. Should be more visible imo. Perhaps adding it at the wiki?

[1714306977]

1714306977

[1714306977]

1714306977

[1714306977]

1714306977

[gyverlb]

gyverlb, the thread in your signature is awsome. I've been diggin around and haven't found it till now. Should be more visible imo. Perhaps adding it at the wiki?

Glad you like it.

The Bitcoin wiki is frustrating: I can't easily reach most pages because my preferred language is French in my browser. I'm always redirected to French pages with less content or even no content at all. Damn wiki I can read English just fine, show it to me! I'm not going to edit a wiki that wouldn't even let me see the content I create by default.

That's a shame though a Wiki would indeed be more suited for the content in the tuning guide. I especially miss the ability to use anchors and links to them, the creation of a table of contents and the ability to edit only a chapter instead of the whole post...

[daemondazz]

Your pool node (http://cryptominer.org) doesn't seem to publish its default pages (couldn't find them).

Yeah, I moved it to an alternate URL when I first set the node up because I wasn't sure if there was anything which could be considered confidential. I just haven't got around to reverting it yet. It's at http://cryptominer.org:9332/s/

What is the average efficiency you get with such a setup? I stopped using a remote node in the early days while I had large amounts of stales and low efficiency and I wonder if it got better since.

Right now, with 20 hours of uptime, it's 6.5% DOA and 112% efficiency.

I have a couple my miners I keep switching between the BTC node and TRC node, so I'm not sure if that effects things much. At the moment everything is pointed at the BTC node.

[gyverlb]

Right now, with 20 hours of uptime, it's 6.5% DOA and 112% efficiency.

Hum quite good. May I know how much ping time do you have between your miners and your node? This way I can report it as a workable solution in the tuning guide. I'd like to find out the latency between miner and node where efficiency starts to suffer so your configuration is a good reference.

I have a couple my miners I keep switching between the BTC node and TRC node, so I'm not sure if that effects things much. At the moment everything is pointed at the BTC node.

It probably takes a little more time to get a useful average because you have less hashrate on average but it shouldn't effects things either way.

[daemondazz]

thanks daemondazz, i'm interested in the scheme you use. Any caveat i should have in mind? For example it would be wise to use a payout address not from the bitcoind, right?

It's always a good idea. Your wallets shouldn't have a public IP address but P2Pool certainly should.

Definitely specify the -a option and point it to an address in a wallet that is not on your p2pool server.

Other than that, just follow gyverlb's guide

[daemondazz]

Hum quite good. May I know how much ping time do you have between your miners and your node? This way I can report it as a workable solution in the tuning guide. I'd like to find out the latency between miner and node where efficiency starts to suffer so your configuration is a good reference.

I have 2x 7950's (approx 500-600MH/s ea) and 1x 7870 (approx 400-500MH/s) with a 32ms RTT and another 7870 with a 19ms RTT.

I have two USB ASICMINERs on the way, they will be going into blades in the datacentre, so that'll be another 600MH/s with a 0.1ms RTT.

[daemondazz]

Ok, I have someone else who is now donating hashrate to me on cryptominer.org:

Code:

darryl@server1:~# bitcoind validateaddress N45qLhKASG8mJAvN3zFHdGiu8i7LhPhVQP
{
    "isvalid" : false
}

Averaging 200MH/s since midnight local, about 12 hours ago.

EDIT: Ok, turns out that's a Namecoin address:

Code:

darryl@server1:~# namecoind validateaddress N45qLhKASG8mJAvN3zFHdGiu8i7LhPhVQP
{
    "isvalid" : true,
    "address" : "N45qLhKASG8mJAvN3zFHdGiu8i7LhPhVQP",
    "ismine" : false
}

[gyverlb]

I have 2x 7950's (approx 500-600MH/s ea) and 1x 7870 (approx 400-500MH/s) with a 32ms RTT and another 7870 with a 19ms RTT.

Thanks, I've updated the guide to make it clear mining on a remote node should be doable with low RTTs.

[ok]

Thanks, but this still doesnt' help us. How to merge stratum-forrestv with stratum-mining-proxy?

stratum-mining-proxy uses the stratum package, which is somewhere on your computer if you're running stratum-mining-proxy, and is what the patch needs to be applied to.

Thank you! It works.
Now I successfully installed new stratum package and proxy is working, just look:

Code:

$ python mining_proxy.py -gp 5001 -sp 5002 -o localhost -p 9332
2013-05-27 10:22:17,862 INFO proxy jobs.<module> # Using C extension for midstate speedup. Good!
2013-05-27 10:22:17,871 ERROR proxy mining_proxy.main # Stratum host/port autodetection failed
Traceback (most recent call last):
  File "mining_proxy.py", line 178, in main
    new_host = (yield utils.detect_stratum(args.host, args.port))
  File "/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py", line 1070, in _inlineCallbacks
    result = g.send(result)
  File "/home/pioruns/stratum-mining-proxy/mining_libs/utils.py", line 69, in detect_stratum
    header = f.response_headers.get('x-stratum', None)[0]
TypeError: 'NoneType' object has no attribute '__getitem__'
2013-05-27 10:22:17,871 WARNING proxy mining_proxy.main # Stratum proxy version: 1.5.2
2013-05-27 10:22:17,873 WARNING proxy mining_proxy.test_update # Checking for updates...
2013-05-27 10:22:18,265 WARNING proxy mining_proxy.main # Trying to connect to Stratum pool at localhost:9332
2013-05-27 10:22:18,268 INFO stats stats.print_stats # 1 peers connected, state changed 1 times
2013-05-27 10:22:18,268 INFO proxy mining_proxy.on_connect # Connected to Stratum pool at localhost:9332
2013-05-27 10:22:18,268 INFO proxy mining_proxy.on_connect # Subscribing for mining jobs
2013-05-27 10:22:18,303 WARNING proxy mining_proxy.main # -----------------------------------------------------------------------
2013-05-27 10:22:18,304 WARNING proxy mining_proxy.main # PROXY IS LISTENING ON ALL IPs ON PORT 5002 (stratum) AND 5001 (getwork)
2013-05-27 10:22:18,304 WARNING proxy mining_proxy.main # -----------------------------------------------------------------------
2013-05-27 10:22:18,304 INFO proxy client_service.handle_event # Setting new difficulty: 0.999984741211
2013-05-27 10:22:18,306 INFO proxy client_service.handle_event # New job 8850090419252557308580900352527982298 for prevhash 385766c3, clean_jobs=True
2013-05-27 10:22:29,931 INFO proxy client_service.handle_event # Setting new difficulty: 0.999984741211
2013-05-27 10:22:29,933 INFO proxy client_service.handle_event # New job 82294000856594409674845997521737547736 for prevhash 385766c3, clean_jobs=True
2013-05-27 10:22:41,372 INFO proxy client_service.handle_event # Setting new difficulty: 0.999984741211
2013-05-27 10:22:41,374 INFO proxy client_service.handle_event # New job 285117993302263092594898950693479724933 for prevhash 385766c3, clean_jobs=True

Why do you need a stratum proxy any way?

Tomorrow (hopefully today if time permits) I will be testing BE Blade on this proxy

Hi there lenny, please let me know if you were successful with setting up you BE Blade with the stratum proxy on p2pool. Thx

Unfortunately, no success...
Blade just do not connect to stratum proxy on p2pool. There is not error message at all.
I would like really to have some developer in it, I can donate my Blade worktime to debug this.

There seems to be no way to get p2pool working with ASICs, either directly or through the stratum proxy.
Devs, please accept lenny's offer and get those ASICs working on this pool!

[daemondazz]

There seems to be no way to get p2pool working with ASICs, either directly or through the stratum proxy.
Devs, please accept lenny's offer and get those ASICs working on this pool!

I'm happy to have a look into this, although I'm not a "dev" yet I do have an interest in getting it working as I'm working on an ASIC project.

I haven't read up fully on the problem, is it purely related to Stratum, or is there some other issue?

[ok]

There seems to be no way to get p2pool working with ASICs, either directly or through the stratum proxy.
Devs, please accept lenny's offer and get those ASICs working on this pool!

I'm happy to have a look into this, although I'm not a "dev" yet I do have an interest in getting it working as I'm working on an ASIC project.

I haven't read up fully on the problem, is it purely related to Stratum, or is there some other issue?

There seems to be a problem related both to getwork and stratum mining. P2Pool seems not capable of keeping up with the number of connections that the ASIC devices attempt when connecting to the pool either using getwork or stratum.

[Mogumodz]

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.2/

0.8.2 is out of RC and Released into the wild.

[bitpop]

I welcome everyone to use my public node, very fast and reliable, see signature

[Bitmong]

I don't know the exact reason why getblocktemplate affected efficiency and even if it's still the case today as forrestv might have changed something that removes this problem. It was still the case very recently (like less than 2 months ago) when getblocktemplate took more than 0.2s. I don't check often how it affects p2pool but I'm doing it right now (in fact I'm studying how the block size and fee limits affect getblocktemplate in the current situation, checking the efficiency is just a bonus). If the behavior of p2pool changed I'll know it in the following days and will be able to update my guide. For now I still recommend to keep it under 0.2s to be safe.

Some recent findings on P2Pool efficiency on my node.

My node is directly connected to the Internet with Ethernet, 100 Mbit/s downstream and 10 Mbit/s upstream. The node is a Phenom four-core processor, with SSD disk. I have 7 mining rigs connected to the node via LAN.

All numbers below are with current (April 2013) P2Pool from Github.

When my configuration was incorrect and Bitcoind could only make outgoing connections, my efficiency was between 95% and 99%.

After fixing the configuration problem, efficiency rose to 110-115% level. I have now 30-40 connections to the Bitcoin network.

When the getblocktemplate latency started to appear, my efficiency was still between 110-115%. My getblocktemplate latency was about 30 seconds at that time.

I have now upgraded to the 0.8.2rc3 version, and the getblocktemplate latency decreased to about 0.1 seconds, but it has increased to 0.9 seconds since the upgrade (in four hours).

Current efficiency after two hours from the upgrade is 102.4%. Well, I think one cannot deduce anything from that yet, maybe the stopping and restarting of bitcoind caused some orphans.

I'll report the efficiency back to this thread after 24 hours have passed with this new bitcoind version.

So, now the pool has run for over 24 hours with the new bitcoind version and:

Code:

# default is 500000, 1000000 is the maximum allowed and will fit more transactions (more fees)
blockmaxsize=1000000
#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.00001
# Same but for relaying the tx to our peers
minrelaytxfee=0.00001

settings.

I have found 70 shares now, 7 orphan and 5 dead, for stale rate of 17.1% (10-28% interval). Pool stale rate is 20.4% now, so efficiency is 104% (90-113% interval).

One thing I remembered was that I have downclocked my CPU to 1.2 GHz from the default clock rate of 2.5 GHz or so to save a little CPU. That might affect things a bit. I might check that at some point.

bitcoind getblocklatency is 0.93 seconds now, so it is much better than the 30 seconds earlier. I think the CPU frequency affects this latency the most, and was likely the reason my latency was 30s with the old bitcoind version.

[K1773R]

I don't know the exact reason why getblocktemplate affected efficiency and even if it's still the case today as forrestv might have changed something that removes this problem. It was still the case very recently (like less than 2 months ago) when getblocktemplate took more than 0.2s. I don't check often how it affects p2pool but I'm doing it right now (in fact I'm studying how the block size and fee limits affect getblocktemplate in the current situation, checking the efficiency is just a bonus). If the behavior of p2pool changed I'll know it in the following days and will be able to update my guide. For now I still recommend to keep it under 0.2s to be safe.

Some recent findings on P2Pool efficiency on my node.

My node is directly connected to the Internet with Ethernet, 100 Mbit/s downstream and 10 Mbit/s upstream. The node is a Phenom four-core processor, with SSD disk. I have 7 mining rigs connected to the node via LAN.

All numbers below are with current (April 2013) P2Pool from Github.

When my configuration was incorrect and Bitcoind could only make outgoing connections, my efficiency was between 95% and 99%.

After fixing the configuration problem, efficiency rose to 110-115% level. I have now 30-40 connections to the Bitcoin network.

When the getblocktemplate latency started to appear, my efficiency was still between 110-115%. My getblocktemplate latency was about 30 seconds at that time.

I have now upgraded to the 0.8.2rc3 version, and the getblocktemplate latency decreased to about 0.1 seconds, but it has increased to 0.9 seconds since the upgrade (in four hours).

Current efficiency after two hours from the upgrade is 102.4%. Well, I think one cannot deduce anything from that yet, maybe the stopping and restarting of bitcoind caused some orphans.

I'll report the efficiency back to this thread after 24 hours have passed with this new bitcoind version.

So, now the pool has run for over 24 hours with the new bitcoind version and:

Code:

# default is 500000, 1000000 is the maximum allowed and will fit more transactions (more fees)
blockmaxsize=1000000
#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.00001
# Same but for relaying the tx to our peers
minrelaytxfee=0.00001

settings.

I have found 70 shares now, 7 orphan and 5 dead, for stale rate of 17.1% (10-28% interval). Pool stale rate is 20.4% now, so efficiency is 104% (90-113% interval).

One thing I remembered was that I have downclocked my CPU to 1.2 GHz from the default clock rate of 2.5 GHz or so to save a little CPU. That might affect things a bit. I might check that at some point.

bitcoind getblocklatency is 0.93 seconds now, so it is much better than the 30 seconds earlier. I think the CPU frequency affects this latency the most, and was likely the reason my latency was 30s with the old bitcoind version.

no need to downclock, thats sutpid!

[furball]

I have found 70 shares now, 7 orphan and 5 dead, for stale rate of 17.1% (10-28% interval). Pool stale rate is 20.4% now, so efficiency is 104% (90-113% interval).

One thing I remembered was that I have downclocked my CPU to 1.2 GHz from the default clock rate of 2.5 GHz or so to save a little CPU. That might affect things a bit. I might check that at some point.

bitcoind getblocklatency is 0.93 seconds now, so it is much better than the 30 seconds earlier. I think the CPU frequency affects this latency the most, and was likely the reason my latency was 30s with the old bitcoind version.

I've found that the biggest influencer on latency has been the txfee settings. Some people might consider 0.9s latency as still quite high so it might worth trying to tune your txfee settings and see if it comes down even further.

Try setting them to 0.0002 and see if that helps you and then decide if you want to lower it to include more transactions for more fees.

[spiccioli]

Unfortunately, no success...
Blade just do not connect to stratum proxy on p2pool. There is not error message at all.
I would like really to have some developer in it, I can donate my Blade worktime to debug this.

I've made some tests yesterday using cgminer 2.5.10 with a BFL FPGA pointed to the mining proxy (connected to p2pool with forrestv patch) and it does not work if I try using getwork (I get back an error which says that user credentials are wrong).

If I let cgminer switch to stratum, that is if I don't use --fix-protocol then it starts mining without problems.

You can add -P -D to the cgminer command line to see what goes wrong.

I'm running the mining proxy on a fedora 16 pc and cgminer on an ubuntu 12.x server.

spiccioli

[lenny_]

Unfortunately, no success...
Blade just do not connect to stratum proxy on p2pool. There is not error message at all.
I would like really to have some developer in it, I can donate my Blade worktime to debug this.

I've made some tests yesterday using cgminer 2.5.10 with a BFL FPGA pointed to the mining proxy (connected to p2pool with forrestv patch) and it does not work if I try using getwork (I get back an error which says that user credentials are wrong).

If I let cgminer switch to stratum, that is if I don't use --fix-protocol then it starts mining without problems.

You can add -P -D to the cgminer command line to see what goes wrong.

I'm running the mining proxy on a fedora 16 pc and cgminer on an ubuntu 12.x server.

spiccioli

That's only your local problem. I am using patched stratum proxy with forrestv patch. Stratum proxy to p2pool works 100% fine with my cgminer, both on getwork and stratum ports.
Blade pointed to that proxy (getwork port) just sits and do nothing, while I am successfully mining with cgminer on it, at same time.

[rav3n_pl]

I've made some tests yesterday using cgminer 2.5.10 with a BFL FPGA pointed to the mining proxy (connected to p2pool with forrestv patch) and it does not work if I try using getwork (I get back an error which says that user credentials are wrong).

Maybe update cgminer?

[spiccioli]

I've made some tests yesterday using cgminer 2.5.10 with a BFL FPGA pointed to the mining proxy (connected to p2pool with forrestv patch) and it does not work if I try using getwork (I get back an error which says that user credentials are wrong).

Maybe update cgminer?

Why should I? Getwork is so old and cgminer 2.5.10 has been released around february this year, maybe I could try an older version of cgminer...

spiccioli