Thread

What do you mean exactly, who is the recipient of the ln payment? In theory there is no issue with doing MPP in a swap I think. The recipient of the ln payment can wait until all htlcs are received (the full amount), then lock funds onchain to the payment hash. When the sender of the htlcs spends the utxo with the preimage the recipient can see the preimage on the chain and settle the htlcs with it. This seems unrelated to using MPP or not.

Imagine alice and bob are involved in submarine swap. Alice pays LN invoice and gets on-chain sats. What if multiple users paid this LN invoice? Can this be used to fund a shared UTXO?

In a swap the senders of the lightning htlcs know the preimage (instead of the recipient like in a normal ln payment). I think it wouldn't be save for multiple senders of htlcs to know the preimage as they could then try to steal from each other if the other htlcs route through a node they control. Also the swap counterparty would have to lock an output to a condition which can be collaboratively unlocked. Well you could probably give each sender a separate invoice, and then create a fat script which locks to all hashes, but then they would all have to collaboratively agree on a claim tx which seems complicated and prone to failure. What is much more realistic is just batching pending swaps while the locking tx is unconfirmed by adding additional outputs to the locking tx until it gets confirmed if it happens that multiple people do swaps with the provider at roughly the same time. This is already done by Electrum for example.

What about this? https://docs.lightning.engineering/lightning-network-tools/lnd/amp

I don't think AMP would help solve the issue of one party being able to steal the funds of the other sending parties in the concept of collaboratively paying a single lightning invoice. At least one of the sending parties still has access to the full preimage and could use it to steal htlcs of the other sending parties.