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

[gyverlb]

So what's your solution for 10-15% rejects?

What matters is your efficiency vs the rest of P2Pool's network. As long as you average above 97% most of the time you should be fine. You can ignore transient variations: I think (didn't check the code) P2Pool compares your overall stale shares since the node startup vs the recent stale share rate of the network so recent changes in the network make the value computed for efficiency move around.

If your 10-15% are the total rejects as reported by your node, there's no problem (I have 10+% rejects and am usually slightly over 100% efficiency).
If it's the amount of rejects as reported by your miner (should be the amount reported as DOA by P2Pool), then either :

• you can afford a better setup (less network latency between node and miners and more CPU power if P2Pool is running on a weak CPU): do that
• you can't: consider other pools based on what you value most (variance in income, total expected income, admin policies, ...)

In the end everyone choose their pool based on their needs. At a time I even split my mining power across several pools. If some of your gear gets high rejects but not all of it, you might want to split too.

[1715207468]

1715207468

[1715207468]

1715207468

[lenny_]

I think we completely misunderstand each other.
I am talking about:
my FPGA hardware doing 0.01% rejects or less on Bitminter using Stratum. Same hardware, exactly same configuration doing 15% rejects on p2pool. I tried to tweak config and got slightly better results about 10% but that's still not the main case. 15% - That's reported by miner and by p2pool stats as well. That's wasting resources, nothing else. When we invest our money and time in something, we should do it right. FPGAs just react too slow to change nonce every couple of seconds, to top of that add remote node's bitcoind latency + network latency + time to prepare getwork etc... This is just not working for LP= 10s, it's a disaster. No one is mining of remote p2pool nodes as it will just not work as it is right now.
If you guys are saying there is no solution for that - so beware, because one day p2pool will die.

[gyverlb]

I think we completely misunderstand each other.
I am talking about:
my FPGA hardware doing 0.01% rejects or less on Bitminter using Stratum. Same hardware, exactly same configuration doing 15% rejects on p2pool. I tried to tweak config and got slightly better results about 10% but that's still not the main case. 15% - That's reported by miner and by p2pool stats as well.

That's much too high. I have ~2.5% rejects on all my Spartan6 (CM1 and Icarus with MPBM). I have 2.6% rejects on my GPUs (5870 and 5970 with cgminer).
So I really don't see any problem with FPGAs and P2Pool: in fact they react slightly faster than my GPUs (cgminer autotune the intensity on each one to react in 50ms).

That's wasting resources, nothing else. When we invest our money and time in something, we should do it right.

They don't waste resource, a share is only rejected if it both arrives too late and doesn't solve a block so there's no,zero,0 income wasted by these rejects. I repeat: rejects don't reduce the pool's income.

FPGAs just react too slow to change nonce every couple of seconds

Now that's mixing your particular configuration which is clearly not optimized for p2pool and plain FUD (since when the target is a couple of seconds?).

, to top of that add remote node's bitcoind latency + network latency + time to prepare getwork etc... This is just not working for LP= 10s, it's a disaster.

Nope, it isn't a disaster: I earned more with p2pool in 6 months than I would have on a 100% PPS pool since I started (I keep track of each and every payment and compare it to my theoretical income on a no fee PPS pool).

No one is mining of remote p2pool nodes as it will just not work as it is right now.

Probably depends on the actual node and who connects to it: some have better connectivity than others. I used to mine on one of my rented VPS servers with a 45ms round-trip time with my miners and it worked OK (it was around 98% efficiency IIRC).

If you guys are saying there is no solution for that - so beware, because one day p2pool will die.

I think p2pool is for geeks who like to setup and tune everything themselves. When you can host a node properly (for me this means locally on a host with a good CPU, 2GB RAM on a Linux server dedicated to bitcoind+p2pool, a SSD to store bitcoind's data and with a good QoS setup so that both bitcoind and p2pool don't suffer from other traffic on your WAN connection) and configure a backup pool it's arguably the most reliable and profitable option.

It's not for everyone, but if you are a serious miner and have the network connection and hardware available it's simply the best solution. From what you wrote there are surprising latencies in your setup: it probably isn't for you.

[K1773R]

They don't waste resource, a share is only rejected if it both arrives too late and doesn't solve a block so there's no,zero,0 income wasted by these rejects. I repeat: rejects don't reduce the pool's income.

most ppls are being scared of because they think their rejects are wasted work, donst matter how often u say it, dosnt help we would need somewhat like a FAQ explaining it maybe.

[twmz]

I can't downgrade the bitcoind that p2pool.info gets information from quickly.  I may be able to do it in a day or two.  Until then, FYI, that p2pool.info may be confused or just plain wrong about blocks and orphans (and luck and round duration).

[K1773R]

I can't downgrade the bitcoind that p2pool.info gets information from quickly.  I may be able to do it in a day or two.  Until then, FYI, that p2pool.info may be confused or just plain wrong about blocks and orphans (and luck and round duration).

in 1-2 days the invalid 0.8 chain is gone, u dont have to do anything in this case since ur bitcoind isnt mining. just wait in this case.

[twmz]

I can't downgrade the bitcoind that p2pool.info gets information from quickly.  I may be able to do it in a day or two.  Until then, FYI, that p2pool.info may be confused or just plain wrong about blocks and orphans (and luck and round duration).

in 1-2 days the invalid 0.8 chain is gone, u dont have to do anything in this case since ur bitcoind isnt mining. just wait in this case.

Yeah, I have been following the developments and it sounds like soon, there will a patch to 0.8 that I'll install instead of downgrading.  Still, I advise not trusting p2pool.info for now.

[lenny_]

Pool Hashrate: 166 GH/s
Come on guys, stop your miners! Move mining machines to any other 0.7 central pool, like BTCGUild until it's all sorted.
P2pool work now against main blockchain.
Read: https://bitcointalk.org/index.php?topic=152030.200

[K1773R]

Pool Hashrate: 166 GH/s
Come on guys, stop your miners! Move mining machines to any other 0.7 central pool, like BTCGUild until it's all sorted.
P2pool work now against main blockchain.
Read: https://bitcointalk.org/index.php?topic=152030.200

no need to move away aslong u need 0.7, still this dosnt matter anymore.

[lenny_]

I think we completely misunderstand each other.
I am talking about:
my FPGA hardware doing 0.01% rejects or less on Bitminter using Stratum. Same hardware, exactly same configuration doing 15% rejects on p2pool. I tried to tweak config and got slightly better results about 10% but that's still not the main case. 15% - That's reported by miner and by p2pool stats as well.

That's much too high. I have ~2.5% rejects on all my Spartan6 (CM1 and Icarus with MPBM). I have 2.6% rejects on my GPUs (5870 and 5970 with cgminer).
So I really don't see any problem with FPGAs and P2Pool: in fact they react slightly faster than my GPUs (cgminer autotune the intensity on each one to react in 50ms).

That's wasting resources, nothing else. When we invest our money and time in something, we should do it right.

They don't waste resource, a share is only rejected if it both arrives too late and doesn't solve a block so there's no,zero,0 income wasted by these rejects. I repeat: rejects don't reduce the pool's income.

FPGAs just react too slow to change nonce every couple of seconds

Now that's mixing your particular configuration which is clearly not optimized for p2pool and plain FUD (since when the target is a couple of seconds?).

, to top of that add remote node's bitcoind latency + network latency + time to prepare getwork etc... This is just not working for LP= 10s, it's a disaster.

Nope, it isn't a disaster: I earned more with p2pool in 6 months than I would have on a 100% PPS pool since I started (I keep track of each and every payment and compare it to my theoretical income on a no fee PPS pool).

No one is mining of remote p2pool nodes as it will just not work as it is right now.

Probably depends on the actual node and who connects to it: some have better connectivity than others. I used to mine on one of my rented VPS servers with a 45ms round-trip time with my miners and it worked OK (it was around 98% efficiency IIRC).

If you guys are saying there is no solution for that - so beware, because one day p2pool will die.

I think p2pool is for geeks who like to setup and tune everything themselves. When you can host a node properly (for me this means locally on a host with a good CPU, 2GB RAM on a Linux server dedicated to bitcoind+p2pool, a SSD to store bitcoind's data and with a good QoS setup so that both bitcoind and p2pool don't suffer from other traffic on your WAN connection) and configure a backup pool it's arguably the most reliable and profitable option.

It's not for everyone, but if you are a serious miner and have the network connection and hardware available it's simply the best solution. From what you wrote there are surprising latencies in your setup: it probably isn't for you.

Can you please share your settings with me? cgminer is able to get similar results?

[maqifrnswa]

Can you please share your settings with me? cgminer is able to get similar results?

Many people have said this, but I want to make sure lenny_ understands: The 10-15% "rejects" you see in p2pool have nothing to do with a decrease in income nor with wasted work. 10-15% rejects on p2pool is the same as 2-2.5% rejects on any other pool. The reason is that the p2pool sharechain is different (in behaviour) than the bitcoin blockchain.

I'm periodically fighting FUD of "p2pool sucks because they have a ridiculous reject ratio." I then explain it to people, with examples showing how you make more money with a 10-15% reject rate on p2pool than you would on a 2% reject rate on another pool. A few days later, someone else pops up and says the same thing.

The 10 second LPs have nothing to do with lost income and does not create a disaster, the sharechain is different than the blockchain.

This is a phenomenal description of p2pool:

I think p2pool is for geeks who like to setup and tune everything themselves. When you can host a node properly (for me this means locally on a host with a good CPU, 2GB RAM on a Linux server dedicated to bitcoind+p2pool, a SSD to store bitcoind's data and with a good QoS setup so that both bitcoind and p2pool don't suffer from other traffic on your WAN connection) and configure a backup pool it's arguably the most reliable and profitable option.

It's not for everyone, but if you are a serious miner and have the network connection and hardware available it's simply the best solution.

[Proofer]

I just upgraded p2pool from 11.1 to 11.2, and am informed that I need to update twisted. I'm running Ubuntu 11.04. Synaptic shows that I have python-twisted 10.2.1 installed and also indicates that is the latest version. Does this mean I must upgrade Ubuntu or ... ?

[mdude77]

This is a phenomenal description of p2pool:

I think p2pool is for geeks who like to setup and tune everything themselves. When you can host a node properly (for me this means locally on a host with a good CPU, 2GB RAM on a Linux server dedicated to bitcoind+p2pool, a SSD to store bitcoind's data and with a good QoS setup so that both bitcoind and p2pool don't suffer from other traffic on your WAN connection) and configure a backup pool it's arguably the most reliable and profitable option.

It's not for everyone, but if you are a serious miner and have the network connection and hardware available it's simply the best solution.

Aside from the fact p2pool's 90 day "luck" is at 88.5%, and 30 day "luck" is at 57.1%.  Aside from that, yes, it's great.

M

[gyverlb]

Aside from the fact p2pool's 90 day "luck" is at 88.5%, and 30 day "luck" is at 57.1%.  Aside from that, yes, it's great.

M

I don't see what luck has to do with greatness. Past luck doesn't guarantee future luck...

[kano]

Can you please share your settings with me? cgminer is able to get similar results?

Many people have said this, but I want to make sure lenny_ understands: The 10-15% "rejects" you see in p2pool have nothing to do with a decrease in income nor with wasted work. 10-15% rejects on p2pool is the same as 2-2.5% rejects on any other pool. The reason is that the p2pool sharechain is different (in behaviour) than the bitcoin blockchain.

I'm periodically fighting FUD of "p2pool sucks because they have a ridiculous reject ratio." I then explain it to people, with examples showing how you make more money with a 10-15% reject rate on p2pool than you would on a 2% reject rate on another pool. A few days later, someone else pops up and says the same thing.
...

Sorry, you are incorrect, since you have ignored pointing out the 2nd part of the reject issue:

The problem with 10-15% rejects is that means others on p2pool with 4-5% rejects are getting a greater proportion of each block vs their hash rate.

Yes if EVERYONE was mining at 10% rejects, then everyone would get the same proportion of income vs their hash rate.

However, those with better reject rates get a proportionately better payment rate and that extra comes from those with the worse reject rates.

[organofcorti]

Good question, heading out but want to think about it a bit more later. I think it may has to do with conditional probability, which ties into gambler's fallacy (unless I'm reading this too quickly). ......

I just realised that I'd been misunderstanding you. The answer is simple to explain.

If the last n blocks are sufficiently unlucky that for 95 runs of n block solvings out of 100 those n blocks will have required fewer shares to solve, then by definition, the next n blocks will have a 95% probability of being "luckier" than the last n blocks.

Examples:
1. If one block required 3*D of D1 equivalent shares to be solved (CDF = ~ 0.95), then there is a 95% probability that the next block will take less than 3*D D1 equivalent shares to be solved.

2. If the last ten block required 15.7*D of D1 equivalent shares to be solved (CDF = ~ 0.95), then there is a 95% probability that the next ten blocks block will take less than 15.7*D of D1 equivalent shares to be solved.

As for my original example,
I have discovered
a trulymarvelous
proof of this, which
this margin is too
narrow to contain.

[mdude77]

Aside from the fact p2pool's 90 day "luck" is at 88.5%, and 30 day "luck" is at 57.1%.  Aside from that, yes, it's great.

M

I don't see what luck has to do with greatness. Past luck doesn't guarantee future luck...

Are you here for greatness or coins?  If the former, grats.  If the latter, you could do better at the most expensive PPS pool.

M

[gyverlb]

Aside from the fact p2pool's 90 day "luck" is at 88.5%, and 30 day "luck" is at 57.1%.  Aside from that, yes, it's great.

M

I don't see what luck has to do with greatness. Past luck doesn't guarantee future luck...

Are you here for greatness or coins?  If the former, grats.  If the latter, you could do better at the most expensive PPS pool.

M

Seems you didn't read me, so I repeat:

Past luck doesn't guarantee future luck...

[K1773R]

Past luck doesn't guarantee future luck...

Past luck dosnt affect future's luck at all...

[gyverlb]

Past luck doesn't guarantee future luck...

Past luck dosnt affect future's luck at all...

My point exactly (I was just paraphrasing the "past performance doesn't guarantee future results" disclaimer seen in investment contracts).

People using the "current" luck (which in fact is past luck) of a pool to decide if it's a good one to mine at simply don't understand mining.

I could understand using variance to choose a pool and admittedly it is not good on p2pool currently due to low hashrate.