Thanks for the feedback!

>At the same time, I can pretend to be many, many small nodes, which I'll program to side with my arbiters if someone challenges them as being corrupt.

I was already thinking about weighting each node's width on the selection surface, in other words making certain nodes more or less likely to be selected, based on the strength of their proof of CPU. That just didn't make it into this draft and should solve the problem you're describing.

>Can't I just DDoS the other nodes...

That would be a pretty powerful DDoS if it can take down enough of the network to leave your nodes as a majority. I don't think even Bitcoin could stand up to that either, since in theory it would let you launch 51% attacks. You do have a point that letting arbiters defer computation to any node of their choosing could be a problem, though.

>If all it takes to write to a DHT node is some user's signature...

All content on the DHT belongs to various user accounts. If the user is going to be able to deploy application content to their account element on the DHT, they will need to be able to unilaterally sign their content and upload it. It isn't possible to forge arbitration logs because it can be easily checked that the correct nodes were selected based on the hash of the initiating request, and also the signatures of the arbiters on the log can be checked to ensure they are who they claim they are. I'm not quite sure what you're trying to say with that last part.

>What steps do you take in the sandbox to prevent the (untrusted) code from denying service to participants?

Assuming the VM is secure, the only thing that you would be able to do is have nodes execute some extremely long-running task, but that would depend on you have effectively unlimited funds. So, if money is no object to the attacker, I suppose they could DoS the network, but at that point it would be indistinguishable from regular activity. Also, since it's not possible to select which nodes fulfil your request, you would inevitably end up DoS'ing some of your own nodes as well.

>No entropy in the sandbox will limit the things you can do here. You can't (safely) do cryptography, for example.

A lack of entropy is crucial for reproducibility of solutions. The VM would still have access to deterministic pseudorandom numbers, seeded by the request body, but any true randomness would break verifiability. Also, it wouldn't be wise to perform cryptography on the network anyway since the nodes doing the processing would potentially be able to peek at the data and also record the keys. VAPUR offers verifiability of computation, but not secrecy of computation.

>Have you heard of Permacoin? You can have proof-of-storage without arbiters or a DHT.

I looked into it. It seems interesting, though I'm not sure if it's a good fit for something like this. I'll have to think about it some more to see if I can work in something like it somehow.

>Even then, Permacoin is slow--way too slow...

VAPUR will be considerably slower than conventional centralized web services, though it should be possible for it to operate with speeds comparable to TOR, and potentially somewhat faster with enough optimization. Confirmation by the blockchain isn't required for requests to complete: that only occurs after the request is already completed and the nodes want to cash in on their work. I will need to put some effort into finding ways to make the data stored more compact, however.

>Regarding presentation...

I completely agree. I threw this paper together in a fit of inspiration and only did some minor editing. I just wanted someone else to check what I'm doing before I put too much work into a dead end.

Anyway, thanks again for the feedback.