Circumventing spending by sending previous transaction using same input

Question

I will give a scenario because my problem might be confusing if explained otherwise.

Let's say a customer is checking out at a store using IOTA. Before the customer proceeds to checkout they send a transaction to the tangle that spends all IOTA from the input that would be used for the checkout. This transaction would be timed as to remain pending during the checkout process. Once the checkout process is complete the customer will have sent an IOTA transaction to the merchant. The customer exits the store and the initial transaction before checkout confirms before the transaction used for the checkout.

Will the merchant be defrauded of their funds? Or does the tangle have measure to prevent a transaction from being attached if there is a pending transaction using the same input?

Answer 1

This is theoretically possible, but if it were to become commonplace, merchants would require transactions to confirm before allowing the customer to leave with the product, as they do with credit cards today.

Answer 2

As far as I know, there is currently no feature in the node software that would prevent an attack like the one you described. Also, as of today the transaction (tx) timestamps are set by the user, so it is not necessarily easy for other nodes to determine which tx came "first" (but also not impossible if you look at how the tx reference each other).

But keep in mind that there are solutions for an attack like that and it is not always possible to play the attack this way.

First, once the malicious "first" tx is broadcasted to the tangle, the sender can not (easily) slow down the confirmation of the malicious transaction. The attack might just not work, because the first transaction gets confirmed, before the attacker sends/reveals the "second" checkout tx to the merchant (the merchant can easily detect, that the tx inputs are missing/invalid).

Second, the merchant could check during the checkout process if there's already an outgoing unconfirmed tx at the customer's input address and just not accept the payment. The merchant might not be able to tell, which tx came first, but for sure that they are conflicting -> only the customer has access to the seed. An already outgoing, broadcasted and conflicting tx is easy to detect, basically impossible to hide, and a clear red flag.

Third, even if the merchant does not detect the already broadcasted, unconfirmed and conflicting "first" tx, it achieves to outrun the second "checkout" tx and the merchant get's defrauded, there are ways to handle this. E.g. a reputation system: the merchant can just "punish" the customer's rating, because the fraud is quite easy to detect afterwards (even for a potential third party).