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

[furball]

Hi all,

Every now and then on my Litecoin P2Pool node I get the following messages :

"Failure: twisted.internet.error.ConnectBindError: Couldn't bind: 24: Too many open files"

I've adjusted my OS settings to the following to allow more open files but still seems to be happening every now and then.
* soft nofile 16384
* hard nofile 65536
* soft nproc 4096
* hard nproc 16384

If anybody could point me in the right direction it would be greatly appreciated.

F.

[azw409]

After upgrading bitcoind to 0.8.2, p2pool seems rock solid and has been up for over a week without a restart. No more big jumps in latency.

However it seems to have stopped finding blocks and my CGMiner hasn't found a block in two days so consequently my payout has fallen to 0 and stayed there for at least a day.

I mine at 275 MH/s and normally have a payout in the range 0.008 to 0.015 and probably find around 5 blocks a day. It seems highly unlikely that I would go 2 days with nothing and that my payout would fall to zero. Has anybody else experienced this and could there be a bug in p2pool as a result of running for so long without a restart ?

Thanks

[GrapeApe]

After upgrading bitcoind to 0.8.2, p2pool seems rock solid and has been up for over a week without a restart. No more big jumps in latency.

However it seems to have stopped finding blocks and my CGMiner hasn't found a block in two days so consequently my payout has fallen to 0 and stayed there for at least a day.

I mine at 275 MH/s and normally have a payout in the range 0.008 to 0.015 and probably find around 5 blocks a day. It seems highly unlikely that I would go 2 days with nothing and that my payout would fall to zero. Has anybody else experienced this and could there be a bug in p2pool as a result of running for so long without a restart ?

Thanks

Probably the recent rise in difficulty. I think we are all feeling it.

[Rassah]

So, how 'bout that crappy streak of bad luck these past few days, eh?

[bitpop]

Doesn't matter some days we get 4. Statistics bro

[xgtele]

bad luck sucks 

So, how 'bout that crappy streak of bad luck these past few days, eh?

[bitpop]

I like it, soon we get 5 payments in one day!

[bitpop]

Two LARGE payouts already today! Be patient fuckers.

[xgtele]

Two? I saw only this one http://blockexplorer.com/block/0000000000000026b9f1a978acd4d263b0889ed36bfa35106299b9a54f6b6e52

Two LARGE payouts already today! Be patient fuckers.

[bitpop]

Well like 8 hours ago.

[gyverlb]

Two? I saw only this one http://blockexplorer.com/block/0000000000000026b9f1a978acd4d263b0889ed36bfa35106299b9a54f6b6e52

Two LARGE payouts already today! Be patient fuckers.

Some people didn't get the memo: this block is only ~73kB with ~0.11BTC fees. With the current amount of transactions waiting confirmation (2500+, ~20MB, more than 25BTC in fees) generating such a short block is unlikely without messing with maxblocksize, mintxfee or minrelaytxfee.

With bitcoind 0.8.2 default configuration in the current situation my node would generate a ~450kB block with ~0.80BTC fees (look at your bitcoind getmininginfo to get the size of the block template and at P2Pool logs or interface for the fees' value).

Assuming the block was generated under similar circumstances that's nearly 3% income lost for everyone. At this point people should use the default bitcoind configuration if they don't fully understand how to tune it.

[bitpop]

So the node that got it screwed us?

[gyverlb]

So the node that got it screwed us?

"Screwed" is probably an exaggeration: that's only 3% on one block and the node lost these 3% too. That could be unintentional too (a freshly restarted node which didn't have the time to fill it's memory pool will generate a block with fewer transactions).

What's important is that it's not an exception: that's the second time I check recent P2Pool blocks and I found that they were small ones which missed potentially higher fee income.

[Subo1977]

So the node that got it screwed us?

"Screwed" is probably an exaggeration: that's only 3% on one block and the node lost these 3% too. That could be unintentional too (a freshly restarted node which didn't have the time to fill it's memory pool will generate a block with fewer transactions).

What's important is that it's not an exception: that's the second time I check recent P2Pool blocks and I found that they were small ones which missed potentially higher fee income.

whats the pro and cons of integrating MUCH TX in a P2Pool Block?

[gyverlb]

So the node that got it screwed us?

"Screwed" is probably an exaggeration: that's only 3% on one block and the node lost these 3% too. That could be unintentional too (a freshly restarted node which didn't have the time to fill it's memory pool will generate a block with fewer transactions).

What's important is that it's not an exception: that's the second time I check recent P2Pool blocks and I found that they were small ones which missed potentially higher fee income.

whats the pro and cons of integrating MUCH TX in a P2Pool Block?

pro: the block is worth more, P2Pool users earn more,
con: you might have to tune your setup to keep your efficiency (especially if you have a slow link, see the guide in my signature).

[wtogami]

So the node that got it screwed us?

"Screwed" is probably an exaggeration: that's only 3% on one block and the node lost these 3% too. That could be unintentional too (a freshly restarted node which didn't have the time to fill it's memory pool will generate a block with fewer transactions).

What's important is that it's not an exception: that's the second time I check recent P2Pool blocks and I found that they were small ones which missed potentially higher fee income.

whats the pro and cons of integrating MUCH TX in a P2Pool Block?

Larger blocks could increase the chances of losing the block as an orphan, but in the case of p2pool thanks to tx pre-forwarding this concern is mostly obviated.
The other drawback to too many tx's is GBT can take longer.  Normal pools do GBT far less often than p2pool.  During the recent spam txo attacks, you've seen p2pool miners increase the minimum tx fee so GBT would be much faster.  0.8.2 improved that performance issue a *lot* thanks to sipa.

[zvs]

So the node that got it screwed us?

"Screwed" is probably an exaggeration: that's only 3% on one block and the node lost these 3% too. That could be unintentional too (a freshly restarted node which didn't have the time to fill it's memory pool will generate a block with fewer transactions).

What's important is that it's not an exception: that's the second time I check recent P2Pool blocks and I found that they were small ones which missed potentially higher fee income.

whats the pro and cons of integrating MUCH TX in a P2Pool Block?

pro: you get to split an extra 0.96% in fees to everyone else (less than 0.25BTC), going by stat info on http://blockchain.info/stats   

con: you get a lot more orphans & more processing power is needed, not altogether related to the getblock latency, but actual transferring within the p2pool network itself

[gyverlb]

pro: you get to split an extra 0.96% in fees to everyone else (less than 0.25BTC), going by stat info on http://blockchain.info/stats  

These stats are obviously underestimating what you can get: they are based on what most miners do, not what they could do. The fees could easily be 2 to 2.5% with bitcoind 0.8.2 default settings.

con: you get a lot more orphans & more processing power is needed, not altogether related to the getblock latency, but actual transferring within the p2pool network itself

Not if you configure bitcoind and p2pool to lower their network traffic as (again...) explained by the guide in my signature.

TL;DR: I have an average ADSL connection and use it for several other traffic types (Bitcoind+P2Pool is ~30% of my BW).
I can even use 1MB blocks and lower minimum fees without lowering my efficiency (reaching 3 to 5% additional fee income).
I only had to limit the number of bitcoind (10) and P2Pool connections (5 outgoing + 5 incoming) to get this result.

[Decagrog]

My dgc p2pool start to use a lot of memory ( 288mb and rising ), it could be due to the number of shares downloaded? (in the data/digicoin folder there is shares.0 , shares.1, shares.2  of about 10mb each)  it's a normal behaviour?

[Subo1977]

pro: you get to split an extra 0.96% in fees to everyone else (less than 0.25BTC), going by stat info on http://blockchain.info/stats  

These stats are obviously underestimating what you can get: they are based on what most miners do, not what they could do. The fees could easily be 2 to 2.5% with bitcoind 0.8.2 default settings.

con: you get a lot more orphans & more processing power is needed, not altogether related to the getblock latency, but actual transferring within the p2pool network itself

Not if you configure bitcoind and p2pool to lower their network traffic as (again...) explained by the guide in my signature.

TL;DR: I have an average ADSL connection and use it for several other traffic types (Bitcoind+P2Pool is ~30% of my BW).
I can even use 1MB blocks and lower minimum fees without lowering my efficiency (reaching 3 to 5% additional fee income).
I only had to limit the number of bitcoind (10) and P2Pool connections (5 outgoing + 5 incoming) to get this result.

On my P2Pool-Node Hashes 5 GH/s. Thats a chance form 0.5%  to find one p2pool-Blocks.

So why should I reduce my efficency for every Payout to get once the tx-fees in 200 P2pool-Blocks?