Add section for risk assessment recommendations?

[bitjson]

We should maybe add a section that makes ZCE risk assessment much clearer for prospective merchants. Consider:

• In-person vs. remote payments (much easier to execute multi-merchant timing attacks)
• Disposability of stolen goods (if goods are easy to resell, merchants are at higher risk of being included in a multi-merchant attack)
• Connected-ness of merchant (if merchant/processor has lots of connections around the network, they'll hear attempted attacks faster. Payment processors with many merchants can prevent attacks by disallowing conflicting ZCEs across merchants.)
• 2 second drop off: at ~2 seconds of monitoring, further attacks require replacement with a higher-value ZCE (and the merchant receiving that ZCE-secured payment has >99% chance of having already heard the double spend, canceling the transaction and reducing the attackers' payoff).
• Maintaining reversibility for 5 seconds (reducing attackers' expected payoff to 0)
• Larger escrows reducing monitoring requirements

A comment to start from:

Do you mean something like: Alice pays $10 ($10 ZCE) to Bob and $20 ($20 ZCE) to Charlie in the same instant using the same UTXO?

If Bob doesn't monitor for 5 seconds or have some reversibility, Bob could lose the $10 payment. The attacker loses $20 as miners take the larger ZCE, and Charlie gets the expected $20 payment. And both Bob and Charlie know some intentional fraud just occurred. If Charlie is monitoring or has some reversibility, Charlie may refuse to release the product to the attacker, since he knows some other merchant out there (Bob) was just defrauded of $10 by this attacker. (And he doesn't want to be an accomplice, since he's now holding some stolen money.)

In the worst case scenario, the attacker is multiple thieves attempting to withdraw cash from BCH ATMs in X locations. All attackers make their transaction at the same millisecond (timed in advance, since they can't communicate faster than the BCH network). The ATM company didn't read the CHIP and identify their increased risk, so they only have 100% escrows and also don't wait 5 seconds. Some percentage of the machines spit out money, and the attackers lose the highest value ZCE broadcasted. If the attackers have good enough coordination against an ultra-naive ATM company, they might e.g. lose $100 and gain $400 at a cost of say 6 people's time (1 coordinator, 5 thieves). Each thief now has ~2 seconds to get away before the alarms starts ringing.

So you can see, even perfectly-executed attacks against the worst-prepared merchants are hard to make profitable. As a merchant, you need to understand your risk-profile: if you're an ATM operator, you probably want a higher value escrow and maybe a 2 second wait. (Still faster than a bank-run ATM, but less than 1% chance of not hearing a competing ZCE.) If you're a hot dog stand, you're almost certainly fine with 100% escrow and an instant success screen. (The attacker doesn't get multiple chances without being recognized, and it's probably going to take them 5 seconds to be handed a hot dog anyways.)

And some other material:

Yes, but fortunately, we can definitively prevent that kind of fraud at the network level too, see this comment above.

Of course, it's worth noting that while miners can already defraud zero-conf transactions, they have only been caught doing it once (that's the link from Full-Value Escrow Requirement Footnote #2). So even if it's possible, it seems the logistics have never been worth the payoff.

Keep in mind that such an operation needs to keep making transactions even for blocks they don't mine. So not only do they need to dispose of the stolen goods, they also need to get rid of the goods they purchased with unsuccessful double-spends. To make such an operation profitable, you need both a very fungible good and an unusually naive merchant. (E.g. the 2013 attack was against a gambling website who made enough money to just ignore the fraud as an operational cost.)

Another scheme: the miner can attempt to mine all blocks with an unbroadcasted transaction. When they find a block, they double-spend using the same inputs before broadcasting the block with the prepared reversal transaction. However, this scheme requires a miner to hold on to a mined block for a critical 10+ seconds (even in the best case), which risks having the block left behind by the network finding an alternative.

Finally, miners can just passively attempt double spends of every transaction they normally make – a random, occasional 100% "discount". (No need to dispose of extra stolen goods.) Even here, the logistics are rough. Your chance of success is equal to your hash power, so small miners need to make enough transactions get lucky: find a block in the ~10 minutes after a normal transaction. But your transaction also has to have been anonymous – if you're paying a bill or checking out with your logged-in account, the merchant can find you and ask you to "try your payment again" later. If you're a bigger pool (e.g. >5% of network hash power), you have a better chance of getting lucky, but you also now have a serious reputation risks. (Not to mention a lot easier for the merchant to track down.)

However you approach it, this sort of fraud is not easy. So it would be nice to prevent, but we can take our time rolling out a network rule.