Quote from: forrestv on November 01, 2012, 12:29:20 AM

It's kind of hard to test with something that you're not even sure exists... Tongue

Anyway, with sane nTime rolling and adaptive pseudoshare targets, getworks can provide more than enough work to remote hosts with very low bandwidth. Everything for nTime rolling is already there (the HTTP header), and adaptive targets are disabled temporarily, but I'll re-enable them for the next release.

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

How hard would it be to implement GBT for ~~pyramining~~P2Pool? 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).

Edit: Pyramining is already setup how they want to and will probably continue in the same. GBT support for p2pool was what I meant to ask about.

I really don't see any issue with getwork. Why is GBT necessary?

P2Pool can handle reward halving.

EDIT: Getwork does have some problems with timestamp rolling. Depending on how ASIC miners handle it, it could work, but I'll start working on GBT support to allow timestamp rolling.

The main problem I see coming is that even the slowest announced ASIC (BFL's Jalapeno) can go faster than one getwork per second. Most devices are a lot faster. Pulling the work away from the pools and closer to the actual device is a decent looking way to deal with that. I'm not aware of any huge issues with timestamp rolling as long as they can get enough getwork blocks, especially after a longpoll when they need more new pieces of work to start working on the new block (small surges of getworks every 10 seconds when a block comes out seems excessive).