Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2017-12-28 📝 Original message: Mark Friedenbach <mark at ...

📅 Original date posted:2017-12-28
📝 Original message:
Mark Friedenbach <mark at friedenbach.org> writes:
> Splitting a single payment into multiple invoices has bad semantic
> properties. Beyond implementation difficulties it also makes the
> payment no longer atomic. You can end up in a situation where part of
> a transaction has gone through but then channel capacity has been
> exhausted. The. What do you do?

We are indeed working on a solution for multipath payments, and they are
pretty simple to implement if the sender and recipient know how to
handle them. Re-use the same HTLC secret along all paths and the
atomicity is re-established. The only blocker is that it increases
complexity on the recipient, e.g., how do I tell whether the partial
payment is all I'll ever get, or whether there is more incoming, when do
I abort waiting, and similar concerns. That's the reason it didn't make
it into the v1.0 spec, but we are confident that it'll be added soon.

It is technically already possible to do so, if you hack together the
recipient node to wait for all parts of the payment before releasing the
secret. No need for multiple invoices.

> While an annoying (and potentially exploitable) edge case for
> payments, it also makes it basically impossible in practice to build
> higher level smart contracts on top of lightning channels as
> primitives, since those constructs typically use a single HTLC
> revelation as the decision gate between multiple contingent outcomes.

Absolutely, that's why we want to have the payment contingent on a
single secret, or on secrets that can be derived from one another.

> I had always assumed the protocol limits were training wheels, and
> would be shocked and dismayed if that were not the case (and would
> immediately begin work on an alternative fork because such limits
> would make lightning useless for my intended applications).

They are training wheels, we just decided for our own implementations
that we want to limit individual potential losses due to bugs. It is
trivial to change that on a per-channel level, and we have all the
pieces in place to perform an upgrade using the feature bits, no need to
fork lightning just yet :-) You just need to agree on using larger
amounts with your peer, on the peer layer, there is nothing preventing
the use of large channels in the multi-hop layer.

HTH,
Christian