This thing enables a whole business model, and it's good for a bunch of reasons. There won't be room for many sites like this, because the bounty will be held in a sort of escrow, and potential customers won't want to pay the bounty twice or three times. So they'll pick the site with the most compute power. The way it's shaping up, they'll also have to post a reward large enough to beat out the current top bounty on reward-to-difficulty in order to get their job prioritized.
Yeah, eventually the mining tools will probably be prioritizing the addresses to mine which will regulate the reward model better than any pre-set cost per character would (as far as I remember someone mentioned that in the Vanity Pool post). I'm also hoping some people/businesses will want to order their addresses in bulk, which could make things interesting...
I might have been too nitpicky about two URLs, that works fine, and it will do the job going forward. However, how would you change it in a backward-compatible way to support something like a case-insensitivity flag?
If I had to design it from scratch though, maybe the bitcoin JSON-RPC model would be a good choice.
Well, I'll probably want to do as much as I can with the current system, and if I won't be able to handle something important, I'll probably start making versions of the protocol.
While JSON-RPC model would probably be more than enough, I think keeping it the simplest for now would suffice. But hey, that's what the testing phase is for;).
Yep that was me. The payment did go through, and it shows up on block explorer. My testnet client unfortunately didn't see it because the transaction is on testnet2 and my client is on testnet3.
The pool keeps 20%, or 1 tBTC?
Currently the pool keeps 20%, might implement some cap or change the value if needed be. It all depends on how people will be using the Pool and what the costs of operation will be. The Pool and Bitcoind are running currently on two clouds, so the costs can change a lot with popularity of the service.