Quote from: kano on November 01, 2012, 12:00:33 AM

Quote from: btharper on October 31, 2012, 11:55:28 PM

Quote from: forrestv on October 31, 2012, 11:47:55 PM

Quote from: Krak on October 31, 2012, 11:35:58 PM

Quote from: forrestv on October 31, 2012, 11:32:44 PM

And anyone (everyone?) with an ASIC, having invested hundreds of dollars, will be a "serious miner" in my eyes...

Some people, such as myself, can't really afford the high bandwidth usage of running a node. That's the main reason I switched pools.

Really? P2Pool uses ~3 GB/month, normally. How much is too much for you?

With a normal pool, one getwork response/submit takes about 800 bytes of data, plus some HTTP stuff, so about 1KB for every 4 GH (2^32). At 1 GH/s, over a month, that's 650 MB (1 * (24*60*60*30) * (1000/4) / 1e6). It's probably a bit higher than that due to miners requesting more work than they need. In addition, that number scales linearly with the amount of hashing power you have, so with 3 GH/s, you're on par with P2Pool's bandwidth usage.

If I'd heard more complaints about bandwidth, I could have added an option to decrease the number of peers. Bandwidth usage is proportional to the number of peers you have, and 5 is probably enough, so you could halve the usage easily.

How hard would it be to implement GBT for pyramining? Seems like that would mitigate a few issues for remote miners anyway.

While I'm asking, is the P2Pool codebase setup for the block reward halving already? (I'd imagine so, but it gets messy otherwise)

Depending on the number of outstanding transactions and what transactions AREN'T being ignored, it is possible for GBT to use more bandwidth than GetWork ...

Whoops, I misspoke, corrected the original post. I meant to ask how hard it would be to setup support for GBT (or stratum, or anything else) in p2pool, as this would be one way to improve remote mining.