Hello! I'm the guy who sent the transactions. At my service CoinByCall.com a python script is constantly (once per minute or so) checking whether users have reached their configured payout-threshold, and if so, sends a shell command to bitcoind (sendfrom... ) running on a Linux box, telling it to send the payout-amount to the users' configured BTC address. The system has been working like this fine since June 2013. Around the time serje didn't receive his payout I had the system synchronize a lot of user accounts (yet unaccounted calls -> accounted calls) so their balance would be up-to-date as the system was really lagging behind. However, the associated wallet where coins were sent from always had a balance of 2 BTC or more AFAIK. But it's true that I was buying more BTC during this time (a period of 10-15 hours) than usual. Could it be that my bitcoind sent coins from an "amount of coins" that I bought that was still unconfirmed, even though my wallet had enough confirmed coins (always 2+ BTC)? Sorry for the lame terminology, I hope you get what I mean.
I checked the transactions around the time serje's was sent and indeed, there are about 15 or so transactions that even today still have 0 confirmations.
Yes, it could, transactions rely on other transaction's hashes (TXID), you can mutilate a transaction without invalidating it, and, change it's hash (TXID) before it's in a block (or, even after, but, you'd have to generate a longer chain, so, considered super hard/impossible at that point). It's really not recommended to send any transactions that rely on unconfirmed transactions due to the fact that they'll rely on a transaction that could easily be changed, on top of that, it's basically a "no." to chain transactions to different users using transactions that aren't confirmed, like:-
Address A sends transaction1 to AddressB and customerA
Address B sends transaction2 to AddressC and customerB
Now, if transaction1 is mutilated, then, transaction2 is invalidated. Either batch transactions if you have zero confirmed TXIN (Really? Are you that poor? Get more spread out funds for your system), so, transaction1 sends to lots of customers at the same time (And thus, you don't have to rely on different transactions as often, as, you batch them up), make your system delay transactions until you have TXINs that are confirmed, or, simply have more funds spreadout, next time you're transferring money to your system, instead of putting in 50BTC at once, send it a transaction that gives it 500 0.1 inputs, that way, it can always have an unspent input of > 0 confirmations.
EDIT:- Imagine this:-
Key:-
Black = You
Red = Customer(s)
Green = Invalidated due to upstream issues
You, 1MyAwesomeAddress sends money to customer one (1CustomersAddress) in TXID#1, however, some ass changes your transaction and rebroadcasts it as TXID#2, now, before either one is confirmed, you send TXID#3 to 1SecondCustomersAddress, but, rely on TXID#1. TXID#2 is now confirmed, and, TXID#1 is now orphaned, this means anything downstream from TXID#1 is also orphaned, I.E., TXID#3. Customer one still gets their money, and, you still keep your change in 1MyAwesomeOtherAddress, but, any customers in the chain onward from there are fucked, and, you'll have to spend quite a while to go through your logs to try and work out what you owe who (Not a fun job).
