Use MPP for receiving

[Kixunil]

I just experienced a very unpleasant surprise - I tried to receive amount that is bigger than any individual channel capacity but lower than the sum of channel capacities. Instead of expected MPP receive, I got a new channel opened.

In effect the wallet have just eaten 1% of my payment even when it didn't have to.

[pm47]

Unfortunately, it's not that simple: it depends on how the sender (which doesn't know the number and size of your channels, let alone their respective balances) decides to split the payment. This may very well have been an AMP payment, just not in a way that fits in your existing channels.

Had this been a trampoline payment, then there would have been a payment aggregation and resplit at the last trampoline node in the route, which is our node. Since our node knows exactly the channels and balances to your wallet, it would have done a "perfect split", and things would have worked the way you thought (there are still corner cases though). That's one of the nice feature of trampoline routing: AMP aggregation and resplit by intermediate nodes. Currently, only Phoenix->Phoenix (and possibly Electrum->Phoenix?) are full trampoline payments.

With the upcoming slice-in/out feature, in the future we may be able to only have a single channel for Phoenix, which would be another way of solving this.

[Kixunil]

Isn't some kind of workaround possible? The node already knows all channels and their balances, it also knows payment hash and already uses a custom protocol to communicate with the wallet. So I think it could be possible to just ignore standard LN protocol and split the payment knowing that the wallet will accept it.

As a stop gap solution the wallet could at least show a warning whenever an invoice with amount higher than channel capacity is created.

[t-bast]

So I think it could be possible to just ignore standard LN protocol and split the payment knowing that the wallet will accept it.

That's really not a route we want to take, as this would be a completely different protocol that wouldn't have the same security guarantees as "vanilla" LN.

I really think trampoline is a good solution to this problem, but it's still waiting for other implementations to offer widespread support. Splicing will help as well, because once we have splicing we only need one channel and all these MPP subtleties disappear.

[Kixunil]

Yeah, I guess splicing is better anyway. Especially if existing channels can be merged.

I'm curious what would change regarding security? The only issue I can see is the ability for the receiver to disclose the preimage before HTLCs are established for each channel but that should not be a problem for the sender and only harms the receiver. What am I missing?

[t-bast]

I'm curious what would change regarding security? The only issue I can see is the ability for the receiver to disclose the preimage before HTLCs are established for each channel but that should not be a problem for the sender and only harms the receiver.

But that's the point, it does harm the receiver. It becomes completely trusted as our node could just receive the money and forward it only partially (or even forward nothing).

[Kixunil]

Why would the receiver reveal preimage before all HTLCs are established?

[t-bast]

I think I misunderstood your initial comment.

What you suggest is that the Acinq node aggregates the incoming HTLCs instead of relaying them, and splits the amounts differently to match the existing channel liquidity, is that correct?

If that's the case, it's simply technically impossible without trampoline (and is exactly what trampoline addresses): the Acinq node cannot decrypt the onion to extract some of the fields that only the recipient can decrypt. Without those fields, we simply don't have enough information to create valid HTLCs to send to Phoenix.

[Kixunil]

Could the incoming message be forwarded to the wallet which would decrypt it and send back (using custom protocol) whatever necessary information to create HTLCs over multiple channels?

[t-bast]

It would be really a complex protocol to add with many potential edge cases for something that we'd rather fix "cleanly" with either trampoline or splicing. TBH I believe our time is better spent ensuring that trampoline and splicing make progress sooner than later instead of doing ad hoc throw-away protocols.

[Kixunil]

Fair, how's the work on splicing going? Are there plans to also enable merging existing channels?

[t-bast]

You can follow lightning/bolts#851 and lightning/bolts#863 for progress, we'll dedicate some work on this on the eclair/phoenix side soon.

[Kixunil]

Thanks!

[robbiehanson]

Related: Muun wallet has announced their intention to support trampoline payments:
https://twitter.com/MuunWallet/status/1487081876506525702