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

[GrapeApe]

OK, so I've been looking at my orphans for the last 10 days or so.... about 33% of them occur after a block solve.

i guess i should also mention that 50% of them are orphaned by

1CTgYxMTY5j6SLytKeMsBWAXuUc6yNKcAe

and i know he isnt using an asic, so why so slow?

How do you know it was that address, and is it wrong to assume that you have his ip address? If so ban him don't send any more work his way. Not that it matters but that address has a huge balance by the way...

nah, he's a major contributor to p2pool.  i think he's been mining it for years.   i'm just whining and wish he had a faster setup.  =p

I can confirm that this address is mining since ages. The user behind may have changed his/her rigs since then but when the P2Pool mining started it was either GPU or FPGA based, seems the hashrate is fairly constant too: it always was around 50-60GH/s (computed from the payouts).

If he is reading this thread, he should definitely upgrade his setup: he's probably able to shave quite a few more bitcoins by lowering his bitcoind latency (which is probably the reason why his setup is orphaning zvs shares on occasion instead of building on top of them). This should help us too: he may have mined orphan blocks (not sure of the probabilities though).

I didn’t mean to sound so cold about it....

On another note I’m happy to hear that some are mining their jals on here.  I am waiting on mine and want to stay here. I read that someone has raised the difficulty to 6000 on it.  As salfter asked earlier won't this risk  throwing out good work or is the point to just get the efficiency up regardless of what it throws out. Which brings up another question if jals are throwing out easier work and the efficiency is acceptable, isn't that good for lower hash rate miners?

[forrestv]

In the next couple days, I'm going to release a hard-forking change to P2Pool that will make the following changes:

Global changes
* Increase last transaction extranonce length from 4 bytes to 8 bytes, so full 4-byte Stratum workunits can be efficiently generated (which will prevent the need for the avalon branch)
* Delay payout calculation 1 share so that payouts can be calculated ahead of time, reducing latency between a new share being received and work being distributed to miners
* Option to set a "dust target," which increases your share difficulty so that you don't get payouts below that target

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Litecoin network
* Decrease SPREAD (number of blocks a share's payout is spread over, on average) from 12 blocks to 3 blocks, significantly decreasing the dust payouts generated for miners who get a share less often than every 3 blocks the pool finds

Warnings will be spammed to miners (UPGRADE REQUIRED) once 50% of each P2Pool's mining power has upgraded and the changes will take effect 12 hours after 95% of the mining power has been upgraded, as usual.

If anyone has any recommendations for additional changes or comments on these, please respond.

[daemondazz]

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Will this increase the sharechain from 1 day to 3 days?

[forrestv]

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Will this increase the sharechain from 1 day to 3 days?

I was planning on keeping it the same for now. The only disadvantage a long sharechain has is making P2Pool take a long time to start up and download shares, along with increased memory usage.

[Krellan]

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Will this increase the sharechain from 1 day to 3 days?

I was planning on keeping it the same for now. The only disadvantage a long sharechain has is making P2Pool take a long time to start up and download shares, along with increased memory usage.

I'm rather happy with all the changes, except this one.  Going from 10 seconds/share to 30 seconds/share, but without also increasing the sharechain length, means that there will be much fewer paid shares per found block.

24 hours at 10 seconds each = 8640 shares.  At 30 seconds each = only 2880 shares.

I have a rather slow node (only one Eurupter, it does 320 MH/s), so I have to be pretty lucky to squeeze in my shares during the 24 hour window of opportunity, otherwise they expire unpaid.  When the block was found recently, my node was pretty far down on the list.  Under these new rules, I might not be on the list at all.

That takes away one of the big reasons to do shared pool mining: consistent and steady payouts over time, instead of having to play the lottery for a rare big payout.

Please reconsider?

Is there a problem now with the payout being spread too thin?  I didn't think there was.  If that is a problem, then there would be reason to reduce the shares per block.  Otherwise, since you're already doing a hard fork, now would also be a great time to also stretch the sharechain to 3 days, instead of 1 day, which would keep the number of paid shares per block the same.

Josh

[forrestv]

I'm rather happy with all the changes, except this one.  Going from 10 seconds/share to 30 seconds/share, but without also increasing the sharechain length, means that there will be much fewer paid shares per found block.

24 hours at 10 seconds each = 8640 shares.  At 30 seconds each = only 2880 shares.

I have a rather slow node (only one Eurupter, it does 320 MH/s), so I have to be pretty lucky to squeeze in my shares during the 24 hour window of opportunity, otherwise they expire unpaid.  When the block was found recently, my node was pretty far down on the list.  Under these new rules, I might not be on the list at all.

That takes away one of the big reasons to do shared pool mining: consistent and steady payouts over time, instead of having to play the lottery for a rare big payout.

Please reconsider?

Is there a problem now with the payout being spread too thin?  I didn't think there was.  If that is a problem, then there would be reason to reduce the shares per block.  Otherwise, since you're already doing a hard fork, now would also be a great time to also stretch the sharechain to 3 days, instead of 1 day, which would keep the number of paid shares per block the same.

Sorry about the confusion and your time spent writing a long post - the sharechain length is set in terms of number of shares, not time, and I meant that the number of shares (8640) will remain the same, so you have nothing to worry about! The new sharechain will indeed be 3 days long.

[notme]

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

Will this increase the sharechain from 1 day to 3 days?

I was planning on keeping it the same for now. The only disadvantage a long sharechain has is making P2Pool take a long time to start up and download shares, along with increased memory usage.

I'm rather happy with all the changes, except this one.  Going from 10 seconds/share to 30 seconds/share, but without also increasing the sharechain length, means that there will be much fewer paid shares per found block.

24 hours at 10 seconds each = 8640 shares.  At 30 seconds each = only 2880 shares.

I have a rather slow node (only one Eurupter, it does 320 MH/s), so I have to be pretty lucky to squeeze in my shares during the 24 hour window of opportunity, otherwise they expire unpaid.  When the block was found recently, my node was pretty far down on the list.  Under these new rules, I might not be on the list at all.

That takes away one of the big reasons to do shared pool mining: consistent and steady payouts over time, instead of having to play the lottery for a rare big payout.

Please reconsider?

Is there a problem now with the payout being spread too thin?  I didn't think there was.  If that is a problem, then there would be reason to reduce the shares per block.  Otherwise, since you're already doing a hard fork, now would also be a great time to also stretch the sharechain to 3 days, instead of 1 day, which would keep the number of paid shares per block the same.

Josh

If you want to stay with p2pool, but desire lower variance perhaps you can consider one of the p2pool pooling options available in this thread: https://bitcointalk.org/index.php?topic=234841.0

The first option is a ruby based proxy which logs all pseudoshares and then redirects all shares to the same p2pool address.  As a miner all you have to do is change your pool address.  The other option is a python patch for p2pool that logs all pseudoshares.  You can then run the node with a 100% fee and split up the payments based on the logs.  Source code is available for both, but I'm not sure if there is a public pool for the patch option yet.  I run a server with the ruby proxy solution, but I welcome you to start your own pool with either codebase.

[freshzive]

What determines your # of incoming connections? Just uptime? It seems like the longer I leave my node up, the more I get?

[bitpop]

Sweet can't wait to bring back my jalapeno!

[daemondazz]

@forrestv - have you considered adding a string to the coinbase to identify p2pool?

[yxxyun]

@forrestv - have you considered adding a string to the coinbase to identify p2pool?

+1

[wtogami]

@forrestv - have you considered adding a string to the coinbase to identify p2pool?

There is no need.  It can be identified automatically by forrestv's payout txo.

[wtogami]

Litecoin-0.6.9.1 now recommended for all LTC p2pool nodes.
You MUST follow directions and connect to a supernode
Important bug fixes, August 15th hardfork deadline, plus reduced fee!
https://forum.litecoin.net/index.php/topic,4615.0.html

The release for the general public on Litecoin.org is coming real soon.  You can help smooth the transition of the network to the lower fee by upgrading the entire p2pool LTC network to be capable of relaying newfee transactions.  Follow the directions and add two or three supernodes to your litecoin.conf.

[salfter]

I'm seeing only 84% efficiency with mine. What settings are you using? My miner name has +256 appended to it. A poster in the BFL forums is using /6000 and is getting results more like yours than mine. Given that share difficulty is only 1080 as I write this, though, wouldn't setting difficulty too high risk throwing out valid shares?

What would be a good input to have to guess how good these ASICs are would be people comparing what their efficiency was with low-latency mining devices (GPUs/Icarus/Cairnsmore1/Ztex/...) and what is their efficiency with their BFL ASIC without any p2pool node reconfiguration.
If they have a mixed setup, knowing the total hashrate of the low-latency devices and the total hashrate of the BFL ASICs can do too.

Warning: don't use different payout addresses on your node: it currently adds latency in the P2Pool process and would lower efficiency.

Currently they don't seem horrible: 84% efficiency is the worst I'm aware of. It's bad but not far from what is good enough to make it almost as good as most pools (I consider the 90-95% range to be where P2Pool starts to be the best solution for mining).
Try to tune your setup according to my guide to see if you can reach a better efficiency (see my sig).

I've done that...average bitcoind latency seems to be hanging around 300 ms since the upgrade to 0.8.2.  With 0.8.1, I was seeing multiple-second latencies.  Over the weekend, efficiency went up slightly to around 86%.  I've switched from +256 to /6000 to see if that makes any difference; it's only been running a few minutes, but the 204 rejected shares to 642 accepted shares so far isn't much different than what I was already getting. I double-checked my router QoS settings; p2pool traffic is running at a high priority.

One thing: my P2Pool node is at home, but my Jalapeños are at work. Ping times tend to run 30-50 ms; both LANs are connected through Cox. Would even this little bit of added latency be enough to throw my efficiency into the basement?

By "don't use different payout addresses," are you suggesting that I should use an address from the bitcoind wallet, or only that I shouldn't use the "mine-to-the-address-in-the-username" feature (which I don't use)?

In any case, it looks like I should see some benefit from the upcoming changes to P2Pool. I'd like to see the concept succeed, so I think I can stick with it at least a little while longer.

[Krellan]

Sorry about the confusion and your time spent writing a long post - the sharechain length is set in terms of number of shares, not time, and I meant that the number of shares (8640) will remain the same, so you have nothing to worry about! The new sharechain will indeed be 3 days long.

NICE!!

Thanks!!

 

Josh

[gyverlb]

[...]
One thing: my P2Pool node is at home, but my Jalapeños are at work. Ping times tend to run 30-50 ms; both LANs are connected through Cox. Would even this little bit of added latency be enough to throw my efficiency into the basement?

According to zvs results in a similar setup, no: he achieved high efficiency with much higher ping times (and one other user reported high efficiency at around 30ms too).
Can you find out if your network connection has some headroom left? The most reliable way would be to monitor your P2Pool host public network interface with a low monitor interval to detect spikes under the 10s interval, then check what your network usage is by graphing the data: spikes up to your downlink or uplink max capacity should be the exception.

By "don't use different payout addresses," are you suggesting that I should use an address from the bitcoind wallet, or only that I shouldn't use the "mine-to-the-address-in-the-username" feature (which I don't use)?

If you have only one miner you are using a single payout address whichever way you configured it. If you have several miners, either use names to connect to the P2Pool node to use its configured (or automatically generated, but not advisable) payout address (my preferred configuration which makes nice graphs for each miner) or use the same address for all miners (if you don't want multiple graphs).

In any case, it looks like I should see some benefit from the upcoming changes to P2Pool. I'd like to see the concept succeed, so I think I can stick with it at least a little while longer.

These are world changing indeed. I've always felt that 10s interval was a bit low (and argued about it with forrestv on IRC in the early days of P2Pool IIRC) but this was a compromise (new miners will have to wait a bit longer to get their full payouts with the new 30s interval). The dust removing and payout computation delay are very nice too.

[gyverlb]

These are world changing indeed. I've always felt that 10s interval was a bit low (and argued about it with forrestv on IRC in the early days of P2Pool IIRC) but this was a compromise (new miners will have to wait a bit longer to get their full payouts with the new 30s interval). The dust removing and payout computation delay are very nice too.

In fact I believe that most node efficiencies will converge to 100% with these changes which is really good (although it will probably reduce my income as I'm in the 110-115% range most of the time...).

As tuning P2Pool/bitcoind won't bring much benefit this will help with people still insisting on running nodes generating low block sizes and make our income even slightly higher. This could even deprecate much of what I spent quite some time writing in my guide :-(

[Subo1977]

Hi has anyone Problems with Bitcoind connectet to other Bitcoind nodes over Tor and connectet to local p2pool?

[salfter]

[...]
One thing: my P2Pool node is at home, but my Jalapeños are at work. Ping times tend to run 30-50 ms; both LANs are connected through Cox. Would even this little bit of added latency be enough to throw my efficiency into the basement?

According to zvs results in a similar setup, no: he achieved high efficiency with much higher ping times (and one other user reported high efficiency at around 30ms too).
Can you find out if your network connection has some headroom left? The most reliable way would be to monitor your P2Pool host public network interface with a low monitor interval to detect spikes under the 10s interval, then check what your network usage is by graphing the data: spikes up to your downlink or uplink max capacity should be the exception.

nload says my P2Pool node (running just bitcoind, P2Pool, and cgminer & CryptoSwitcher (the latter two for GPU-mining altcoins)) is averaging 1.04 Mbps upstream, which is about two-thirds of what's available to me IIRC.  This is with P2Pool reporting 7 outbound peers and 12 inbound peers.  Should it be using this much bandwidth?

[freshzive]

[...]
One thing: my P2Pool node is at home, but my Jalapeños are at work. Ping times tend to run 30-50 ms; both LANs are connected through Cox. Would even this little bit of added latency be enough to throw my efficiency into the basement?

According to zvs results in a similar setup, no: he achieved high efficiency with much higher ping times (and one other user reported high efficiency at around 30ms too).
Can you find out if your network connection has some headroom left? The most reliable way would be to monitor your P2Pool host public network interface with a low monitor interval to detect spikes under the 10s interval, then check what your network usage is by graphing the data: spikes up to your downlink or uplink max capacity should be the exception.

nload says my P2Pool node (running just bitcoind, P2Pool, and cgminer & CryptoSwitcher (the latter two for GPU-mining altcoins)) is averaging 1.04 Mbps upstream, which is about two-thirds of what's available to me IIRC.  This is with P2Pool reporting 7 outbound peers and 12 inbound peers.  Should it be using this much bandwidth?

It is most likely Bitcoind not p2pool. My bitcoind was using nearly all of my 2mbit upstream, so I lowered the maxconnections variable from 125 (default) to 20 and it dropped that down to around 200kbps. I haven't noticed any increase in orphans (or bitcoind latency) with the change.