rich1.0npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynhttps://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynnjumphttps://nostr.ae📅 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