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

[sEpuLchEr]

oooiii... what happen to the hashrate??

Are you guys all stuck trying to get pypy to work or merge mining? LOL.

[mahrens917]

Reddit has an up voted thread asking if p2pool is worth it compared to other pools.  Take a look and you can add your comments: http://www.reddit.com/r/BitcoinMining/comments/2sqi3l/miners_of_reddit_do_you_have_statistics_on/

[mdude77]

oooiii... what happen to the hashrate??

Are you guys all stuck trying to get pypy to work or merge mining? LOL.

Don't forget the hashrate isn't really the hashrate.  It's a calculated value based on how many shares have been submitted in the last X minutes.

Could easily be bad luck across the board.

M

[windpath]

Reddit has an up voted thread asking if p2pool is worth it compared to other pools.  Take a look and you can add your comments: http://www.reddit.com/r/BitcoinMining/comments/2sqi3l/miners_of_reddit_do_you_have_statistics_on/

Thx for posting, also a thread on main Bitcoin Reddit:

http://www.reddit.com/r/Bitcoin/comments/2sqh0a/decentralising_mining_making_p2pool_more/

[mahrens917]

Well when recoding p2pool, It would be Nice to solve the "payload too long" issue as well.

Does somebody know how to deal with this?    

Please check this post: https://bitcointalk.org/index.php?topic=18313.msg10164796#msg10164796

 

What is Your Bitcoind GetBlockTemplate Latency? Has You p2pool node external IP to see stats?

Thanks for the reply!

Well my stats looks like this:

Code:

P2Pool Status
Local rate 	155.77 GH/s (DOA 3.67 GH/s / 2.35%) 	Shares 	Total: 2 (Orphan: 0, Dead: 1, Unknown: 1)
Global pool rate 	1.93 PH/s (DOA 321.61 TH/s / 16.67%) 	Share difficulty 	6,707,631.61
Current block value 		Expected time to share 	2d 3h 22m 33 s
Total node payout if block found NOW 		Expected time to block 	1d 3h 11m 10 s
Node peers 	[in] 2 / 30 [out] 	Node uptime 	2d 6h 35m 22 s
Node p2pool version 	13.5-73-g12ca9d8-dirty 	Protocol version 	1300
Node efficiency 	60.00% 	Node getwork latency 	305 ms
Node fee 	0% 	Node donation 	0%

Bitcoin Status
Network rate 	303.41 PH/s 	Blocks 	339,372
Current block 	998,775 bytes / 1,600 txs 	Block difficulty 	43,971,662,056.08958
Hashes to win 	9.22 EH 	Block probability per GH 	5.295015761671106e-12%
Total Bitcoins 		Expected time to block 	0h 0m 30 s
Exchange rate 		Block interval 	0h 10m 30 s
Connections 	[in] 12 / 523 [out] 	Node uptime 	2d 6h 37m 53 s
Node bitcoind version 	99900 	Protocol version 	70002
Relay fee 		Peer latency 	675 ms

I assume my Bitcoind GetBlockTemplate Latency is 675ms, right? From what I've read, the latencies are OK and they are stable when the "payload too long" error is not occurring. Only when the error comes up in the console of p2pool then those latencies are indeed skyrocketing. As I understand from the logs and statistics this payload error does not look like a cause from latencies, but latencies are the symptoms of the payload error. So where all the sudden arises this payload error from? Is it the "maxblocksize" of Bitcoind Core which is 1MB? Because the payload error is always in combination when the blocktime between blocks were +10mins (and +2000 transactions). Get the idea the problem comes from that direction.

Any thoughts?

Yes.
1) Switch to latest p2pool version.
 git clone https://github.com/forrestv/p2pool
2) to limit outgoing/incomming connections of p2pool use this settings:
 --max-conns 6 \
 --outgoing-conns 6 \
3) use 0.9.4.0 bitcoin core version with bitcoin.conf like this (nothing more is necessary):
 server=1
 rpcuser=your_rpc_user
 rpcpassword=your_rpc_password

Thanks for the tips.  I have the latest p2pool and bitcoind code and have limited my incoming and outgoing p2pool connections.  However, my bitcoin.conf file does set blockmaxsize, minrelaytxfee, maxconnections, blockminsize, blockprioritysize, and mintxfee.  Do you believe that one of those settings could cause this issue within p2pool?

[IYFTech]

I leave my conf file with the bear minimum needed, and I don't adjust my p2pool settings either - everything works perfectly using the standard settings for me apart from maxconnections to reduce the bandwidth usage - my ADSL line is shite  

[mahrens917]

Well when recoding p2pool, It would be Nice to solve the "payload too long" issue as well.

Does somebody know how to deal with this?    

Please check this post: https://bitcointalk.org/index.php?topic=18313.msg10164796#msg10164796

 

So doing some digging, the "payload too long" error comes about when a packet's length is greater than max_payload_length.  This can be seen in p2pool/util/p2protocol.py.

This is called from p2pool/bitcoin/p2p.py and p2pool/p2p.py where it sets max_payload_length to 1,000,000.

I am going to change the code to print out the packet size, as well as, change the max_payload_length to twice the size.  I will let the code run for awhile and see what happens and report back.

[Gumara]

I have one question. Is it recommended to give the address with the -a flag and save this address is always the same? Does it make a difference?

[idonothave]

Well when recoding p2pool, It would be Nice to solve the "payload too long" issue as well.

Does somebody know how to deal with this?    

Please check this post: https://bitcointalk.org/index.php?topic=18313.msg10164796#msg10164796

 

What is Your Bitcoind GetBlockTemplate Latency? Has You p2pool node external IP to see stats?

Thanks for the reply!

Well my stats looks like this:

Code:

P2Pool Status
Local rate 	155.77 GH/s (DOA 3.67 GH/s / 2.35%) 	Shares 	Total: 2 (Orphan: 0, Dead: 1, Unknown: 1)
Global pool rate 	1.93 PH/s (DOA 321.61 TH/s / 16.67%) 	Share difficulty 	6,707,631.61
Current block value 		Expected time to share 	2d 3h 22m 33 s
Total node payout if block found NOW 		Expected time to block 	1d 3h 11m 10 s
Node peers 	[in] 2 / 30 [out] 	Node uptime 	2d 6h 35m 22 s
Node p2pool version 	13.5-73-g12ca9d8-dirty 	Protocol version 	1300
Node efficiency 	60.00% 	Node getwork latency 	305 ms
Node fee 	0% 	Node donation 	0%

Bitcoin Status
Network rate 	303.41 PH/s 	Blocks 	339,372
Current block 	998,775 bytes / 1,600 txs 	Block difficulty 	43,971,662,056.08958
Hashes to win 	9.22 EH 	Block probability per GH 	5.295015761671106e-12%
Total Bitcoins 		Expected time to block 	0h 0m 30 s
Exchange rate 		Block interval 	0h 10m 30 s
Connections 	[in] 12 / 523 [out] 	Node uptime 	2d 6h 37m 53 s
Node bitcoind version 	99900 	Protocol version 	70002
Relay fee 		Peer latency 	675 ms

I assume my Bitcoind GetBlockTemplate Latency is 675ms, right? From what I've read, the latencies are OK and they are stable when the "payload too long" error is not occurring. Only when the error comes up in the console of p2pool then those latencies are indeed skyrocketing. As I understand from the logs and statistics this payload error does not look like a cause from latencies, but latencies are the symptoms of the payload error. So where all the sudden arises this payload error from? Is it the "maxblocksize" of Bitcoind Core which is 1MB? Because the payload error is always in combination when the blocktime between blocks were +10mins (and +2000 transactions). Get the idea the problem comes from that direction.

Any thoughts?

Yes.
1) Switch to latest p2pool version.
 git clone https://github.com/forrestv/p2pool
2) to limit outgoing/incomming connections of p2pool use this settings:
 --max-conns 6 \
 --outgoing-conns 6 \
3) use 0.9.4.0 bitcoin core version with bitcoin.conf like this (nothing more is necessary):
 server=1
 rpcuser=your_rpc_user
 rpcpassword=your_rpc_password

Thanks for the tips.  I have the latest p2pool and bitcoind code and have limited my incoming and outgoing p2pool connections.  However, my bitcoin.conf file does set blockmaxsize, minrelaytxfee, maxconnections, blockminsize, blockprioritysize, and mintxfee.  Do you believe that one of those settings could cause this issue within p2pool?

Do You know the reason for each one parameter in Your bitcoin.conf file? If no, or they are not really necessary from very good reason, remove them. Give it a chance to work.

[corrow]

Well when recoding p2pool, It would be Nice to solve the "payload too long" issue as well.

Does somebody know how to deal with this?    

Please check this post: https://bitcointalk.org/index.php?topic=18313.msg10164796#msg10164796

 

So doing some digging, the "payload too long" error comes about when a packet's length is greater than max_payload_length.  This can be seen in p2pool/util/p2protocol.py.

This is called from p2pool/bitcoin/p2p.py and p2pool/p2p.py where it sets max_payload_length to 1,000,000.

I am going to change the code to print out the packet size, as well as, change the max_payload_length to twice the size.  I will let the code run for awhile and see what happens and report back.

If I'm correct the 'maxblocksize' is hardcoded to 1MB into the Bitcoin protocol. So I guess changing the payload length does do the trick within P2Pool code (until the blocksize will be increased). Well it is still unclear to me what part of the code you have changed. Logically it had to do with Bitcoin Core which is responsible for "packaging" the block and verify the hash of it. It would be awesome if you still could update us with news. I've also updated my Bitcoin Core and I'm waiting for a long blocktime with lots of transactions to debug my new setup. So, I'll keep you guys posted! Thanks!

[idonothave]

I have one question. Is it recommended to give the address with the -a flag and save this address is always the same? Does it make a difference?

Depends on what You preffer. If to mine to local wallet (where bitcoin daemon is running) or to exteral wallet. I preffer to mine to external wallet with -a option. Easier and more comfortable for me.

[mahrens917]

Well when recoding p2pool, It would be Nice to solve the "payload too long" issue as well.

Does somebody know how to deal with this?    

Please check this post: https://bitcointalk.org/index.php?topic=18313.msg10164796#msg10164796

 

So doing some digging, the "payload too long" error comes about when a packet's length is greater than max_payload_length.  This can be seen in p2pool/util/p2protocol.py.

This is called from p2pool/bitcoin/p2p.py and p2pool/p2p.py where it sets max_payload_length to 1,000,000.

I am going to change the code to print out the packet size, as well as, change the max_payload_length to twice the size.  I will let the code run for awhile and see what happens and report back.

If I'm correct the 'maxblocksize' is hardcoded to 1MB into the Bitcoin protocol. So I guess changing the payload length does do the trick within P2Pool code (until the blocksize will be increased). Well it is still unclear to me what part of the code you have changed. Logically it had to do with Bitcoin Core which is responsible for "packaging" the block and verify the hash of it. It would be awesome if you still could update us with news. I've also updated my Bitcoin Core and I'm waiting for a long blocktime with lots of transactions to debug my new setup. So, I'll keep you guys posted! Thanks!

Yes, the block should not be coming into p2pool over 1,000,000 or perhaps it is sometimes coming in with a size of 1,024,000 (another meaning of MB).  Or perhaps p2pool or bitcoind is somehow corrupting it at certain times which is causing this issue.  We'll see and my logging should let us know a little better what is happening.

[corrow]

I see you're using an Rc version: v99900 - Maybe that's what's causing your errors. I only use the stable release versions for mining.......

OMG, Why I didn't saw that myself?  
I'm gonna deploy a stable release of Bitcoin Core to factor this out! Thanks!

I've been monitoring my P2Pool Node very closely since the update to the last Bitcoin Core version. I found out with Block #339.597 (which took about 50mins and had more than 2000tx did not grow beyond the the maxblocksize of 1.000.000! This is great news now the P2Pool did not gave any "playload too long" error at console. The update to a later Bitcoin Core did the trick. I would advise everyone to update their Bitcoin Core concerning this issue!

Thanks for the good help and your efforts everyone!!!

[K1773R]

I see you're using an Rc version: v99900 - Maybe that's what's causing your errors. I only use the stable release versions for mining.......

OMG, Why I didn't saw that myself?  
I'm gonna deploy a stable release of Bitcoin Core to factor this out! Thanks!

I've been monitoring my P2Pool Node very closely since the update to the last Bitcoin Core version. I found out with Block #339.597 (which took about 50mins and had more than 2000tx did not grow beyond the the maxblocksize of 1.000.000! This is great news now the P2Pool did not gave any "playload too long" error at console. The update to a later Bitcoin Core did the trick. I would advise everyone to update their Bitcoin Core concerning this issue!

Thanks for the good help and your efforts everyone!!!

be aware that the maxsize for a tx is 50kB. unfortunately hardcoded...

[jonnybravo0311]

Holy back to back blocks Batman!

[windpath]

Holy back to back blocks Batman!

No kidding! 3rd time is a charm....

Edit: Double checked to see if it was a record, that's our 2nd luckiest block since I've been tracking at %70,579

First place is still block 329431 at %180,136 (just 30 seconds after our previous block)
http://minefast.coincadence.com/p2pool-stats.php?blockoffset=100

[Prelude]

 

[yslyung]

Holy back to back blocks Batman!

No kidding! 3rd time is a charm....

Edit: Double checked to see if it was a record, that's our 2nd luckiest block since I've been tracking at %70,579

First place is still block 329431 at %180,136 (just 30 seconds after our previous block)
http://minefast.coincadence.com/p2pool-stats.php?blockoffset=100

more the merrier ! let's rock it

btw, what was the max or record for hitting the most # of blocks in 24hrs for p2p ?

[windpath]

btw, what was the max or record for hitting the most # of blocks in 24hrs for p2p ?

On February 16, 2013 16 blocks were found by P2Pool.

[minerpool-de]

A new german P2Pool Node was born. The Node has 16 GB RAM, 8 x 2,8 Xeon CPU Power an 1Gbit/s connection. 0% Fee for ever.

direct to Node: http://bitcoin.web-rss-verzeichnis.de:9332/static/
to the Intropage: http://bitcoin.web-rss-verzeichnis.de