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

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.


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.

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.

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

Any serious P2Pool user, one serious enough to have ASICs, should definitely have their own P2Pool node...

I don't think ASICs will need any special support. P2Pool can provide getwork results fast enough for hundreds of GH/s (from a normal computer) and could be optimized for more. In addition, any timestamp rolling multiplies that.

Yes, there's a bug that Smoovius reported on the Litecoin P2Pool, which would also apply to the Bitcoin one. P2Pool's memory usage can grow without bound after a fork like this if you maintain connections to people mining on both forks. P2Pool is unable to forget about the children of the root node that connects the two forks, due to that operation simply not being implemented. (I assumed that one fork would always lose eventually, resulting in a linear chain whose last node can be forgotten about.)

Anyway, it's fixed in git, and after some more testing, I'll release v9 and the switchover will be triggered when v9 becomes popular. Restarting P2Pool after the switch would have been enough to fix this, but many people don't have something auto-restarting P2Pool if it crashes or even check up on it often.

The switchover happened on the Litecoin P2Pool about a week ago, and went flawlessly other than this issue.

It should have a mean of approximately 10 s, and be larger than 30 s about 5% of the time.

It looks like you didn't.. strange. Try again, and if that doesn't work, delete all the *.pyc files.

Did you restart P2Pool after upgrading?

Yes, there's the --bitcoind-rpc-port and --bitcoind-p2p-port arguments. Try running "run_p2pool.exe --help".

Maybe try starting run_p2pool.exe from the command-line? It sounds like p2pool isn't receiving the "--net litecoin" argument at all...

Some messages on the console still mention "bitcoind" even if it's trying to connect to litecoind. Maybe pastebin the output?

You do know about the Windows binaries, right? If you don't want to use them, you can unzip the Windows binary to extract ltc_scrypt.pyd and use it.

If you're set on compiling that library yourself, you need to install MinGW.

Yes, that message is a result of a new feature in v8:


P2Pool nodes indicate to their peers which transactions they have in memory so that peers don't need to send the full transaction when, for example, they produce a share containing that transaction. This is to reduce latency below what would result from using something like Bitcoin's "inv"/"getdata" messages, where sending a peer a transaction it doesn't yet know about takes three round-trips instead of one.

"Transaction rescued from peer latency cache" means that your node had a transaction in its memory, determined that it was no longer necessary to retain it, and forgot about it. Meanwhile, a peer is trying to forward the transaction to you and sees that you already have it, so it sends only the transaction hash instead of the full transaction. Were it not for the first node buffering the transaction for a few seconds before truly forgetting about it, sending the transaction hash instead of the full transaction would result in the first node not knowing about the transaction.

There are some possible optimizations for the new transaction handling, which could be causing this by introducing some new latency. I'll look into it over the next few days.

Yeah, it's a bug. EDIT: The fix is in the git repo. (:

Can you zip up and send me your log file? (It's at data/bitcoin/log) I think you were on a fork for some reason, since at that time, my node was saying "Pool: 349GH/s". I suspect that your bitcoind is messed up somehow. What does getinfo show?

Nothing has actually happened yet. The switchover happens at 95% upgraded, and until then, nothing should change.

I think the jump in the pool's stale rate was someone joining with a lot of misconfigured miners (FPGAs?). Looking at http://forre.st:9332/static/graphs.html?Day , the good (non-stale) hashrate didn't decline.

You're not doing exactly the same thing. You're cd'ing in first. Maybe this is because getcwd() from within a symlinked directory returns the original directory name?

P2Pool uses the argv[0] (the path that you give to run_p2pool.py) to find its directory, so it's looking at "~/src/p2pool", and the symlink does nothing. I think it would make most sense to rename it to p2pool_8.2 and run p2pool as "python ~/src/p2pool_8.2/run_p2pool.py". (: