When cgminer sends shares via stratum, it does not send the share and then wait for the response as this might slow down the sending of other shares. This means that the response back from the pool is processed separately from the share submission (to make the most of a truly multithreaded environment). However there is never a guarantee that the responses come back in the same order you send them. So cgminer stores a copy of each share as it sends it to the server in its own local database of submitted shares. When it gets a response back about that share from the pool, it deletes the copy of that share. Now stratum is meant to be an uninterrupted connection to the pool, and if you lose that connection, it is assumed that your "session" is no longer valid. So if you send some shares and get disconnected before you get a response, cgminer has to assume that those shares have been lost - otherwise it may end up keeping copies of heaps of shares that it will never get a response to and wastes memory. If you manage to reconnect, sometimes the pool will actually tell you "oh by the way those shares are ok" - however cgminer has now thrown out the record of what those shares were and can only say that the pool said a share was accepted or rejected. Then cgminer just says it's an "untracked share"." (c) ckolivas