Interesting. I hadn't thought about that before but I believe you are right.
No because they haven't accept bets at 0 confirmations for months now, ever since someone demonstrated a double-spend attack on them.
Interesting. If that's true, then it seems that binaryFate of luckyb.it is lying, or at least doesn't understand how Satosi Dice works and is falsely advertising his own service as "provably fair".
In another thread in a discussion about the dangers of using unconfirmed inputs, binaryFate stated that luckyb.it accepts 0 confirmations and implied that SatoshiDice does as well:
I'm an operator of luckyb.it, and payouts there typically have an unconfirmed input (the players' bets)
Transaction Malleability makes it a VERY BAD idea to be using unconfirmed inputs in your transactions. There is a very real possibility that the transaction ID of the player's bet will NEVER confirm (if a malleated version of it is confirmed instead). How do you handle this situation?
That is the point of doing it that way (
same for satoshidice btw), if the bet never confirms, the payout neither. Which is exactly what you want as a game operator, (from the operator point of view the malleability issue is the same as with "classic" double-spends).
Do you use any part of the player's transaction ID in determining whether the player wins?
Yes
we use part of player transaction ID to determine outcomes (same as satoshidice again), that is partly what makes the game provably fair.
Regardless of the errors that luckyb.it is making, as Rannasha has pointed out waiting for confirmations doesn't make SatoshiDice "provably fair" since they can mess with the transactionID before it is confirmed. The only way for them to be provably fair is to use something from the transaction that cannot be modified after transmitting (such as NTXID)
