I understand they use your bet as an input, but what does that mean and how do they do it? Can they use the standard bitcoind as a server against which to run the API from?
This is oversimplified, but here's one sequence showing a serie of payment transactions:
Miner --> You --> Me --> SatoshiDice --> Me
So you send half a bitcoin to me and I use a client that lets me send it instantly to SatoshiDICE. SatoshiDICE then includes at least part of that payment in their win or loss return payout.
Once your payment to me confirms, then mine to SatoshiDICE can confirm. Once my payment to SatoshiDICE is confirmed, then their payout back to me can confirm.
So if you cheated me and your payment to me was a double spend it will then never confirm (reaching 6 confirmations). And in turn, my transaction to SatoshiDICE will never confirm. And in turn, the SatoshiDICE payout transaction back to me will never confirm.
So it doesn't matter that I saw a payout transaction from SatoshiDICE right away, I can't spend it anywhere until it confirms.
Because even a transaction with one or two transactions can get orphaned due to a block reorg and a double spend attack, even if you see a confirmation that doesn't mean the transaction will clear. That is why, unless there is recourse, only six transactions is the recommended number of confirmations to require.
Here's an example of the transactions for a losing 0.02041833 BTC bet:
You can see the flow visually here:
- http://blockchain.info/tree/16104343 (click on the orange dot for the 0.01569037 BTC payment, which was one of the two inputs that paid for the bet.)
If SatoshiDice paid out as quickly as they possibly could then what say an attacker did the following when sending bitcoins to make a bet:
- If the bet wins, the attacker receives the winnings and does nothing further, or
- If the bet loses, then the attacker tries to get a double spend of the bitcoins out to the majority of the network. If successful, they essentially get their SatoshiDice bet back.
Even fractions of a second would make a difference to the potential success of such an attack, so if SatoshiDice has, say, a 10 second delay before they payout, then the attack may become virtually impossible to achieve unless the attacker somehow cut SatoshiDice off from the majority of the network (very difficult to achieve).
You create a transaction with a Transaction Output ID and they pay you out creating a transaction using that Transaction Output ID as the Transaction Input ID. So if your payment doesn't go through, theirs doesn't either.