What's to prevent someone from using bitcoin at a store like subway and double spending to buy the sandwich before a confirmation is made? Since subway obviously isn't going to wait for a confirmation, can't a person send bitcoin to subway and at the same time send that bitcoin to another address?
Add a comment
|
2 Answers
RBF exploits are possible for 0 confirmation transactions.
The risk/reward is tiny so some merchants will accept small transactions and make delivery without waiting for a confirmation first.
99.9% of the people who have both the competence and lack of morality to double spend in this manner would not waste their time on such a low value theft.
All merchants should wait for (at least) 1 confirmation of possible but the risk is too small for many people to care when selling sandwiches. Any merchant selling a yacht should be waiting for multiple confirmations anyway so the RBF exploit should not be relevant for high value transactions.
-
3This has literally nothing to do with RBF, that's misinformation. A 0-conf transaction is exactly that: no confirmation, no certainty, no guarantee. There are a hundred ways to pull of double spends, with or without RBF flag set. And all of them already existed before the RBF flag was introduced in the first place.– JannesMay 19, 2016 at 17:49
By default there is no way for a merchant to prevent a double spend whilst a transaction is in 0-conf state.
Lets assume for a second that all miners are simply motivated by fees and do not observe default mining policy (i.e. First Seen Safe (FSS), RBF-FSS and friends...) and continue to accept transactions that contain spent UTXOs. If you think about it that way, there are methods for a merchant to incentivise miners to favour the original transaction over the double spend transaction.
The merchant may elect to use a CPFP (Child pays for parent) transaction to increase the value of all subsequent transactions that are dependent on the preceding transaction that is being double spent. By doing so, miners will be incentivised to accept the original transaction over the double spent transaction.
The CPFP method is only effective contingent on the acceptance of the preceding transaction, so it may not work if the entire Bitcoin network only implements FSS as there would be an inherent inconsistent state of unconfirmed transaction (i.e. some partition of nodes P1 might think that the double spend is the valid transaction; while the other partition P2 might think the original transaction is the valid transaction).
In summary, to date, there are no known methods to accept zero-confirmation transactions due to how the reference client is implemented as it will reject transactions that contain spent UTXOs. So either the doublespent transaction will be accepted or the original will be accepted.
