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

[smooth]

I'm going try P2pool again, running it locally.  I intend to point one Ant S1 at it.  I have a DSL connection with only 768k up speed.  Any suggestions/recommendations?

Block incoming connections (or if you have a firewall, just don't forward the port) to bitcoind. That will prevent people from using your node to download the blockchain. In my experience that is the single most important tuning item.

[1714277962]

1714277962

[1714277962]

1714277962

[1714277962]

1714277962

[1714277962]

1714277962

[jedimstr]

I'm going try P2pool again, running it locally.  I intend to point one Ant S1 at it.  I have a DSL connection with only 768k up speed.  Any suggestions/recommendations?

Block incoming connections (or if you have a firewall, just don't forward the port) to bitcoind. That will prevent people from using your node to download the blockchain. In my experience that is the single most important tuning item.

But also potentially detrimental to the integrity of the Bitcoin network... at least allow a few incoming connections (like say 6) versus the crazy high defaults.

[smooth]

Block incoming connections (or if you have a firewall, just don't forward the port) to bitcoind. That will prevent people from using your node to download the blockchain. In my experience that is the single most important tuning item.

But also potentially detrimental to the integrity of the Bitcoin network... at least allow a few incoming connections (like say 6) versus the crazy high defaults.

No that won't work. Even one incoming connection will still periodically (and not infrequently) be used to download the blockchain in my experience, and when this happens it really hurts your p2pool performance and earnings. The reason zero is an effective setting here is that it disables block chain downloads. If you don't like people doing it this way, convince the bitcoin developers to add a feature to directly limit blockchain downloads.

I understand the effect on bitcoin peer-to-peer and that is a downside, but it is a tradeoff you have to make if you want to efficiently run a p2pool node with limited resources.

What you can do if you want to help the bitcoin p2p, and what I do myself, is allow incoming connections on another node (on a different network) where you don't care about the performance impact the way you do for p2pool. Keep the p2pool node quiet.

It would be nice if there were better tuning options on bitcoin to rate-limit people using your node to download the blockchain, and likewise if bitcoin were able to download the blockchain from multiple sources (bittorrent style) to put less load on each individual source, but neither of those features exist currently.

[smooth]

p2pool.info not working?

I see two recent blocks that don't show up.

[dellech]

p2pool.info not working?

I see two recent blocks that don't show up.

and check your address on blockchain.info ... mine shows only the first of the two blocks and a big red bar on top of the page saying "Warning! this bitcoin address contains transactions which may be double spends. You should be extremely careful when trusting any transactions to or from this address." 

[PatMan]

Blockchain.info are having problems.

[smooth]

Both blocks show up on blockexplorer.com

http://blockexplorer.com/block/0000000000000000a4ef1303d77c174ea88d200f7974b4f3e4effb5f343d84c2
http://blockexplorer.com/block/00000000000000007537d9c121b900f912b37d30e826f5c4c068443e41ba3530

[CartmanSPC]

Block incoming connections (or if you have a firewall, just don't forward the port) to bitcoind. That will prevent people from using your node to download the blockchain. In my experience that is the single most important tuning item.

But also potentially detrimental to the integrity of the Bitcoin network... at least allow a few incoming connections (like say 6) versus the crazy high defaults.

No that won't work. Even one incoming connection will still periodically (and not infrequently) be used to download the blockchain in my experience, and when this happens it really hurts your p2pool performance and earnings. The reason zero is an effective setting here is that it disables block chain downloads. If you don't like people doing it this way, convince the bitcoin developers to add a feature to directly limit blockchain downloads.

I understand the effect on bitcoin peer-to-peer and that is a downside, but it is a tradeoff you have to make if you want to efficiently run a p2pool node with limited resources.

What you can do if you want to help the bitcoin p2p, and what I do myself, is allow incoming connections on another node (on a different network) where you don't care about the performance impact the way you do for p2pool. Keep the p2pool node quiet.

It would be nice if there were better tuning options on bitcoin to rate-limit people using your node to download the blockchain, and likewise if bitcoin were able to download the blockchain from multiple sources (bittorrent style) to put less load on each individual source, but neither of those features exist currently.

Will this affect the lower chance of orphans blocks feature? I think the default when incoming connections is closed is to have 8 outgoing...so will going from 120 to 8 increase the chance of an orphan block? I realize that all the other nodes broadcast as well but if they all start blocking incoming connections will we see in increase in orphans?

[smooth]

Will this affect the lower chance of orphans blocks feature? I think the default when incoming connections is closed is to have 8 outgoing...so will going from 120 to 8 increase the chance of an orphan block?

No (well maybe a tiny bit, but not significantly), because the block will be broadcast to bitcoin p2p by all of the p2pool nodes, not just yours.

Also, keep in mind that you can't really send out to multiple connections "simultaneously" since you only have pipe. If anything more connections will make it take longer before anyone receives the whole block, since they'll be competing for your (small) bandwidth.

Also, there is no way you can effectively maintain 120 connections on a low bandwidth connection. You better be reducing that a lot (as indicated on the tuning thread). Once you reduce it to a handful anyway you might as well go all the way to zero and not get hit with block chain downloads.

I realize that all the other nodes broadcast as well but if they all start blocking incoming connections will we see in increase in orphans?

Not everyone is on a limited-bandwidth residential connection, or running on modest node hardware. Let the guys with bigger connections and nodes carry the load. I don't recommend this for everyone, just someone trying to run a p2pool node with very limited resources.

Again, if you don't want to make compromises, you can't effectively run p2pool at all. It's questionable to even run a bitcoin node at all on a bandwidth-capped connection at this point.

[CartmanSPC]

Ok, didn't realize you were speaking to nodes with limited resources. I happen to be one of the "guys with bigger connections"....100 Mbps with burstable to 1 Gbps in a data center. Daemons on a separate dedicated server than p2pool.

[smooth]

Ok, didn't realize you were speaking to nodes with limited resources. I happen to be one of the "guys with bigger connections"....100 Mbps with burstable to 1 Gbps in a data center. Daemons on a separate dedicated server than p2pool.

I recommend that you allow lots and lots of incoming connections to make up for the rest of us

Also, in your case (and possibly others, not sure) you should addnode your bitcoin to the high speed relay. Do you know how to do that?

[CartmanSPC]

Also, in your case (and possibly others, not sure) you should addnode your bitcoin to the high speed relay. Do you know how to do that?

Nope

Also, one of the daemons got hung up once...in 8 months...not bad...but there is something about sending email alerts from the daemon I've been meaning to look into...can you point me in the right direction for that?

[smooth]

Not sure what you mean by email alerts. I will PM you about the high speed relay.

[Lyddite]

If anyone can put this up on the front page, I'm sure it'll help others out that are using Bitfury / Megabigpower rigs:
I have tested this out on V1, V2 and V3 M-boards and images!

HOW TO SET UP P2POOL

...SNIP....

Thanks for this!!

After some looking through the source for a few minutes a then found this post via google which confirmed my suspicions!

-Lyddite

[mdude77]

Bitcoin 0.9.0 is out.  Safe to upgrade for p2pool?  From the looks of it, downgrading could be a hassle.

M

[PatMan]

Running it on my workstation but gonna wait until the "official" release is released before updating my mining wallet - just in case  

EDIT: Oops - it's now official.......

[cr1776]

Been running the RCs and now final without issue.

Bitcoin 0.9.0 is out.  Safe to upgrade for p2pool?  From the looks of it, downgrading could be a hassle.

M

[IYFTech]

Been running the RCs and now final without issue.

Bitcoin 0.9.0 is out.  Safe to upgrade for p2pool?  From the looks of it, downgrading could be a hassle.

M

Nix or doze?

[mitak64]

Yesterday I upgraded to 0.9.0 64bit (Windows).
My "dead" dropped from 130-160G to about 60G !

[stewdk]

Yesterday I upgraded to 0.9.0 64bit (Windows).
My "dead" dropped from 130-160G to about 60G !

Nice! What does your Bitcoind GetBlockTemplate Latency graph look like?