Hi ThePiachu,
I really like what you've done with vanity pool! This has a lot of potential.
Thank you, but it's not really that complicated.
You might want to overhaul this a little bit before it becomes more popular. It ought to behave more like a standard web service, with one URL to do everything, rather than two. And if you're going to use POST, the example code shouldn't put the parameters in a query string, it should use x-www-form-urlencoded. But you already know all of this, and are just trying to look like an upstart, and I respect that.
I guess you are right about the two strings, kind of silly of me to split them up. I'll probably just add the additional functionality to the /getWork address and delete the reference to the other one in the protocol specification, while still supporting it for awhile.
As for "knowing all of this", you give me a bit too much credit - I'm not really that proficient of a web programmer. I do a lot of projects because I know nothing about the field - my bachelor's thesis was about AI and used OpenGL, didn't know much about either before I started, and my master's thesis was about Bitcoin, Google App Engine and Go, also haven't used any before I started. When it comes to web stuff, I'm still learning a lot.
So, could you elaborate a bit more?
Indeed it found a match for "1Testo2" on vanitypooltest.appspot.com, which took a few hours on a cluster of AMD 5830s. Unfortunately, while the address to receive the bounty passed validation, it wasn't valid in this case -- the bounty is in testnet coins, and the address is a regular net address. The pool server replied with an error about the address not appearing to be valid, which is good, but it's unclear what the pool server did with the bounty.
From what I can see, the bounty was claimed by someone with the public key of
C2042FBA7ABE6DF861F7EF45E297EB684BE107D8CC4752F7740E7141FCD22470
Which uses the additive split-key mining. I programmed the Pool to not do anything with the bounty if some data is incorrect - be it an invalid key or Bitcoin address. This way the coins don't get lost or stolen by someone providing a valid solution without the proper means to pay. I figured this would be the fairest - I could implement a Pool that would register a solution without a valid payout address, but it is a bit wrong in my opinion.
If all the data is correct, the Pool will attempt to send the bounty and clean everything up. I'm currently in the process of adding in some extra error handling and pushing the payout onto a separate thread. As Bitcoind is on a different server than the Pool, I can't expect both of them to be able to communicate all of the time. But that will be in the next version I'm preparing. For now some errors can occur - at some point I got a bug that allowed me to pay myself the bounty twice over (happened due to the call to Bitcoind timing out - the payment went through, but it did not register in the Pool).