> 1) The risk that the merchant's web server will be compromised and the attacker will redirect refunds

> 2) The risk that the merchant will miss payments because they miss a POST to the payment_url (maybe the customer's machine crashes during the HTTPS handshake)

> If payments are a lot more common than refunds, then (2) will outweigh (1).

I think that's oversimplifying.  (1) is theft, (2) is payment processing. Reliable payment processing with refund handling is not simple nor free, but it should be secure. The cost of (2) depends primarily on the failure rate, which we can only guess at this point, and secondarily on how much manual intervention is required to recover.

(2) is perhaps more of a problem if wallets broadcast before POST. It's trading one failure mode (funds sent but not claimed) for another (coins marked as spent but not). Either way, you fix it by just retrying the POST. But only with Transmit-After-ACK can the payer's wallet detect the failure automatically, and even recover automatically (simply unlock the outputs, or to be sure, spend them back to self).

Since merchants get to choose whether to have a POST url, they get to decide if the cost of keeping their server up is worth it. I think eventually there are enough benefits to Transmit-After-ACK that it will become a supported use case.

Thanks Mike for explaining the threat.

[Aside] I was reading Peter's fidelitybond writeup for his idea on contract value accounting, and he points to Stephan's post from last September on payer-encoded metadata (https://bitcointalk.org/index.php?topic=108423.msg1178438#msg1178438) which Timo applies here. As a relative newcomer, this is what I am loving most about Bitcoin.