I'm thinking something pre-configured (with the exception of the bitcoin wallet and payment address which will be created once the VM starts)

I don't think it's necessary to go this far. Some more details in the step-by-step instructions, so that they work without assuming the user's setup is 100% default would be enough.For instance, the instructions on http://p2pool.in/ might work for a user with a default setup (data folder for Bitcoin Core not modified) and who doesn't care about not knowing where the mined BTCs will arrive, but it's not enough for a user who moved around their data folder or wants to specify at the pool level the address where to receive BTCs. Also, it's not the case for me but maybe instructions to use a custom port (+/-IP) for Bitcoin RPC would be useful too.

Sure, this shouldn't be in the first hardfork. But something like this needs to happen. I thought the "enforced p2pool" concept was better. IE: no such thing as a pool that doesn't use p2pool. therefore there's no need to join a centralized pool, because p2pool is going to work better. which means pools lose power and machine owners get it back.

Has anyone else had any trouble with p2pool interfering with their bitcoind?

I run some software which queries the RPC interface periodically and it's been giving 500 read timeout errors. I bumped my rpc threads up to 100 and it helped but it was still doing it. I just killed p2pool and a lot of the read errors stopped but also the requests I was making were coming back a lot faster. Does p2pool hit RPC pretty hard?

I have not had trouble per say, but its important to recognize that GetBlockTemplate is an expensive call overhead wise, and its made often by p2pool. Keeping your eye on GBT latency in the graphs is a good way to gauge how its effecting your node.

So I'm looking at my p2pool window and see that my hash rate has suddenly dropped by 50% but no messages about losing contact with bitcoind. Then I look at my geth window and it starts complaining about having 0 peers. A few minutes pass and geth stops complaining and my p2pool hash rate returns to normal.

It would appear that now that I've plugged the python exploit causing the bitcoind memory leak with sandboxing and put a lid on the spam attack by boosting the txfees they've changed gears yet again and have found a new DoS attack to disconnect my connected peers. Looking at my p2pool graph I can see a 75% drop on peers for the last 5 hours.

Block pruning is currently incompatible with running a wallet due to the fact that block data is used for rescanning the wallet and importing keys or addresses (which require a rescan.) However, running the wallet with block pruning will be supported in the near future, subject to those limitations.

Libertarians: Diligently plotting to take over the world and leave you alone.

Block pruning is currently incompatible with running a wallet due to the fact that block data is used for rescanning the wallet and importing keys or addresses (which require a rescan.) However, running the wallet with block pruning will be supported in the near future, subject to those limitations.

Block pruning is currently incompatible with running a wallet due to the fact that block data is used for rescanning the wallet and importing keys or addresses (which require a rescan.) However, running the wallet with block pruning will be supported in the near future, subject to those limitations.

Yeah, that's running a wallet though. Which is different.

I can see where it might make it difficult to validate transactions. But a pruned node still keeps track of UTXOs so *shrug*