Thank you, but it's not really that complicated.
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.
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?
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.
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).
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?