Author

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

sr. member
Activity: 263
Merit: 250
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.
sr. member
Activity: 263
Merit: 250
@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.
member
Activity: 99
Merit: 10
@forrestv - have you considered adding a string to the coinbase to identify p2pool?
+1
sr. member
Activity: 448
Merit: 250
@forrestv - have you considered adding a string to the coinbase to identify p2pool?
legendary
Activity: 2912
Merit: 1060
Sweet can't wait to bring back my jalapeno!
sr. member
Activity: 447
Merit: 250
What determines your # of incoming connections? Just uptime? It seems like the longer I leave my node up, the more I get?
legendary
Activity: 1904
Merit: 1002
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://bitcointalksearch.org/topic/poolyrralnet-p2pool-backed-mining-pool-alpha-234841

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.
hero member
Activity: 516
Merit: 643
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.
member
Activity: 106
Merit: 10
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
hero member
Activity: 516
Merit: 643
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.
sr. member
Activity: 448
Merit: 250
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?
hero member
Activity: 516
Merit: 643
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.
sr. member
Activity: 476
Merit: 250
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?
hero member
Activity: 896
Merit: 1000
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).
sr. member
Activity: 447
Merit: 250
Alright, I'll wait it out a few more days and check efficiency again.

On a more positive note: WE FOUND A BLOCK!!!! AT LAST!!!
newbie
Activity: 8
Merit: 0
bahaha 5 days later, well done all
sr. member
Activity: 476
Merit: 250
Been testing my upgraded Jally on p2pool after the reports that BFL asics seemed to be doing OK. After around 18 hours, I'm seeing this:



Efficiency seems OK? DOA is high though, should I be worried about that? Guess I will let it run a few more days and see how payouts go once we start actually solving some blocks.

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?

To little data to make judgements. At 108 total shares stale+doa rate is (23.1 +- 11.Cool%. I mean that the real rate could be up to 34.9%, which gives efficiency of 83%. So to be sure, you need to wait to get more stats (several hundreds total shares).
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
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 don't even know what IP he mines to, which I guess is part of the problem.  I think he's on a private node, probably with just 6 outgoing connections.

oh, I know it was that address since my orphan showed up in the 'headers' list... then I go to the parent share and click on child, and it shows what replaced your orphaned share (if it works the way I think it does, that replacement is actually dictated by the share that comes after it)
zvs
legendary
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
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).

Isn't all that's required the base latency of the jalapeno?  How do they work?  Does it do work for 2s then spit out results?  1s?  1000ms should result in 10% DOA.

The orphans shouldnt deviate from what you'd get from using a GPU
hero member
Activity: 896
Merit: 1000
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).
Jump to: