Quote from: btchris on August 07, 2014, 11:09:42 PM

Quote from: CJYP on August 07, 2014, 08:36:35 PM

I did forget about jdillon's solution. Assuming it takes 13 seconds for a transaction to propagate through the network, and a block is found once every ten minutes (600 seconds), there's less than a 13/600 chance (oversimplified, but you get the idea) of a double spend getting into a block before the victim sees it, then another less than 13/600 chance of the transaction being included in a block before the scorched earth transaction is seen (if the scammer has a miner friend then all bets are off anyway remember). The merchant doesn't need to do any of this manually; their software will do it for them.

OK, I'll buy that. So there's a non-zero chance that the scammer will get away with it scot-free (get their btc back), but in every scamming attempt, the scam attempt will result in a 587/600 chance that the receiver doesn't receive any btc (unless they want to try a cat-and-mouse game of some sort with the scammer up until the next block is found).

A rational scammer will only try this scam if their expectancy is > 1, in other words if the refundable fee is < than some smallish %. But a scammer who places value on the thought that the receiver will not get paid can execute the attack at will (albeit in return for the surcharge), with the added bonus that they also might get their btc back.

This means that the vendor needs a higher refundable fee to discourage such practice, and they also need to add a non-refundable surcharge to cover their losses. As long as this surcharge is less than 3-ish percent, it will be comparable to credit cards (which removes an advantage of Bitcoin from a vendor's point of view).

Now that Bitcoin is gaining some public traction, explaining all this from a PR point of view would be just about disastrous, if you ask me. To consumers: you have to pay an extra 10%, but it's refundable. To vendors: any consumer who wants to can rip you off, even though they aren't likely to benefit financially, so it probably won't happen much.

But more importantly, what is it that we'd be left with? A more complicated system (both technically and PR-wise) that that accomplishes the same thing as what we had before: instant payments still aren't guaranteed, and so they cost the receiver. So where's the advantage?

If anything, I'd prefer a Pay by Fee that didn't include scorched earth. At least there I see some small advantage: nobody should trust zero-conf transactions (although I still don't like it).

So absolutely anyone who wants can become a criminal for absolutely no financial gain!
Remember, most physical goods stores have video cameras already to catch people who are shoplifting. Now we have a situation where for the potential scammer:
Risk:
- Guaranteed to lose the (small, but non-zero) extra money they paid (which can be increased slightly to account for this situation)
- Likely to become a criminal, and face a prison sentence
- Likely to be banned from the store for life, or at least have to wait around for one confirmation from then on whenever they go to the store
Reward:
- Small satisfaction that the store won't receive money

The number of people who would be willing to risk this is very small. Again, if the transaction is large enough that this happening occasionally poses an actual threat to the business, the business should be smart enough to make the customer wait for confirmations on either system.

EDIT: (late edit, but better late than never and there are no replies yet so it should be okay)
The advantage is as such:
Currently, accepting a 0 confirmation transaction runs the risk that a scammer will create a transaction (via software remember) paying a utxo to themselves, and another paying it to a merchant's address. They have some direct connection to the merchant - I don't know how they acquired this, but they have it (yes, that is possible if they can find the merchant's IP, which depending on the merchant might not be difficult). But the merchant and the scammer also have other direct connections. So the scammer simultaneously sends the transaction paying a utxo to the merchant, and the transaction paying it to themselves to all their other connections (with their software, not trying to manually click two buttons at once obviously). This gives them an advantage in network propagation, and the merchant sees the valid transaction. The merchant releases the items, and the scammer leaves; later the scammer's transaction is much more likely to end up in a block. This possibility makes it very risky to allow anyone to leave until their transaction has at least one confirmation.
With replace-by-fee and child-pays-for-parent, in the normal case, the merchant would immediately (via software, not manually) send a child transaction paying the temporary fee back to the customer. These would be confirmed in the same block in almost all cases, and the customer would never be without access to the temporary fee. The customer's software would pay this extra fee for them; the customer does not have to know about the fee at all (as long as they have enough bitcoin to cover it; if not they can stay around for a confirmation). The merchant's software would send the fee back for them; the merchant does not have to know about the fee at all. In the case of an attack as described above, the merchant's software would automatically send the scorched-earth transaction, costing the scammer his temporary fee and the entire balance of the transaction. Since almost nobody will be willing to pay just to screw a merchant out of a small amount of money, this is unlikely to happen and the merchant can allow the customer to leave immediately.