{"type":"rich","version":"1.0","author_name":"npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","author_url":"https://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-12-28\n📝 Original message:\nMark Friedenbach \u003cmark at friedenbach.org\u003e writes:\n\u003e Splitting a single payment into multiple invoices has bad semantic\n\u003e properties. Beyond implementation difficulties it also makes the\n\u003e payment no longer atomic. You can end up in a situation where part of\n\u003e a transaction has gone through but then channel capacity has been\n\u003e exhausted. The. What do you do?\n\nWe are indeed working on a solution for multipath payments, and they are\npretty simple to implement if the sender and recipient know how to\nhandle them. Re-use the same HTLC secret along all paths and the\natomicity is re-established. The only blocker is that it increases\ncomplexity on the recipient, e.g., how do I tell whether the partial\npayment is all I'll ever get, or whether there is more incoming, when do\nI abort waiting, and similar concerns. That's the reason it didn't make\nit into the v1.0 spec, but we are confident that it'll be added soon.\n\nIt is technically already possible to do so, if you hack together the\nrecipient node to wait for all parts of the payment before releasing the\nsecret. No need for multiple invoices.\n\n\u003e While an annoying (and potentially exploitable) edge case for\n\u003e payments, it also makes it basically impossible in practice to build\n\u003e higher level smart contracts on top of lightning channels as\n\u003e primitives, since those constructs typically use a single HTLC\n\u003e revelation as the decision gate between multiple contingent outcomes.\n\nAbsolutely, that's why we want to have the payment contingent on a\nsingle secret, or on secrets that can be derived from one another.\n\n\u003e I had always assumed the protocol limits were training wheels, and\n\u003e would be shocked and dismayed if that were not the case (and would\n\u003e immediately begin work on an alternative fork because such limits\n\u003e would make lightning useless for my intended applications).\n\nThey are training wheels, we just decided for our own implementations\nthat we want to limit individual potential losses due to bugs. It is\ntrivial to change that on a per-channel level, and we have all the\npieces in place to perform an upgrade using the feature bits, no need to\nfork lightning just yet :-) You just need to agree on using larger\namounts with your peer, on the peer layer, there is nothing preventing\nthe use of large channels in the multi-hop layer.\n\nHTH,\nChristian"}