Ah, thanks for that explanation on stale shares. That makes sense.
I'm still a little confused about what you are ultimately trying to do. So two questions:
1. What is ultimate goal? Are you trying to run a public pool?
2. What do you consider the "backend" of a pool? Is it the part that manages assigning work, and keeping track of what work is done, etc? I am confused by this because of the stuff you mentioned with redirecting packets. I thought backend would be on the "server" side of the pool. But if that's the case, why would you have to mess with sending packets to BTCGuild? That would imply that you are doing some work on the mining client side, and not the server side. I'm sure i'm missing something, can you please explain what?
Don't worry about your quality of code. Everyone has to learn somewhere. I'm sure we could learn from each other.
1: No if i were trying to run a pool I'd just run the already existing pool software, pushpool. The ultimate goal is to have a competing pool backend that's easy to setup and expand with new protocols and functions.
2: I think you need to know some more about how the bitcoin system works so i'll try and explain it:
A simple flow chart of it would look like this:
-> miner requests work
<- bitcoin client responds with workdata wich consists of midstate, data, hash1 and target
| miner now keeps working on the data by hashing it and then increasing some specific bytes in the data field untill it overflows, then requests new work. Inside this "loop" it checks if the resulting hash is below the specified target and if that's true it returns the work to the server where it's verified and if correct a block get solved.
-> so miner either returns result or request new work
<- server responds accordingly
The process for a miner connected to a pool is very similar, the only difference is that the a few things in the block is changed. For one the payout address in the solved block is set to the pool's, secondly the target (AKA difficulty) is set to 0 because it allows everyone to participate, even CPU miners wich can't realisticly solve a block at the current difficulty alone.
Another significant change is that when results are submitted back to the pool, it stores the work as a "share" if it's valid and if it's above the target specified by the network it's submitted to the bitcoin client running behind the pool software so the pool gets rewareded the credits for the block.
Now as for the part that's confusing you: basically instead of my pool software getting data from a bitcoin client in server mode i get it from a pool because to the outside world they work the exact same way except that as mentioned before the difficulty is set to 0 wich lets me debug the recieving, storing and sending of work much quicker than if i had to solve a real block instead of just a share
I guess what's confusing you the most is my way of coding, because instead of writing lots of code knowing that it will work and then later write unittests to prove it, i "shotgun debug" my way through the writing
Also i'm glad you look at the code quality that way haha
anyway PM me if you want to exchange instant messenger informations of some kind like skype or MSN as it's a bit easier to get you up and running that way
---------------
Markm, I'm not entirely sure what your point is? is it a feature request of some kind?
