Why is it necessary for Multi-Path Payments in Lightning to be Atomic?

Question

One way of achieving multi-path payments in lightning is by having the sender use the hash sent by the receiver to send multiple payments along different paths. The mailing list entry proposing atomic multi-path payments describes a downside where

the sender fails to actually satisfy all the payment flows, then the receiver can still just pull the monies (and possibly not disperse a service, or w/e).

But if I understand correctly, if the receiver pulls any flow before all paths are complete, the sender will still end up with the invoice and pre-image which they can use to prove the payment went through, and if the receiver refuses to provide some service, the sender has the same recourse as in the case where the payment was a single-path payment paid in full. Why then, is it necessary to have this atomic multi-path scheme, which makes use of unused bits in the lightning protocol that could potentially be used for something else?

Answer 1

You are pointing out trust issues that exist with any payment mechanism. You can pay for your coffee at Starbucks and still be denied your coffee. That is exactly the case you are pointing out. But, the protocol that is listed provides other benefits that help honest people make payments without having their funds stolen by straddling intermediaries, avoid headaches of refund or use balances across multiple channels to make payment. The concept of sound money transaction involves sending money to other party in a trustless way involving as little friction as possible. This protocol exactly achieves that.

1. Partial payments: Assume payments along some routes completes while payment along others fail to go through. The receiver, assuming he is honest, now has only two alternatives. Request the remaining payment, or refund the amount. In case of refund, you will again have to pay fees to route the payment which means loss of money in fees. The protocol provides way in which either the entire payment goes through or none of it goes through.
2. Straddling Intermediaries: Assume a malicious party has channels open with multiple people. Suppose you send your payment along multiple paths with the same payment hash, then this malicious intermediary might use the payment pre-image he learns in the channel he operates along the first path to settle transactions in the channel along the second path.
3. Use multiple channel balances: Assume you have channel opened across multiple people but none of the channel balance is sufficient to make the payment that is requested. Your only way of sending payment now involves on-chain transaction (either direct Bitcoin on-chain payment, or opening a new channel) which incurs significantly higher fees. With this protocol you can make use of multiple channel balances with fraction of the fee cost involved in an on-chain transaction.