rich1.0npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynhttps://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynnjumphttps://nostr.ae📅 Original date posted:2021-12-16 📝 Original message: This is quite a common request, and we've used a solution I like to call the "Poor man's rendez-vous". It basically routes a payment through all the parties that are to be paid, with the last one accepting the payment for all participants. The payment is atomic, once the circuit is set up no participant can cheat the others and it's seamless from the payer's perspective. Let's say user `A` wants to pay `B` and `C` atomically. `B` gets 10ksat and `C` gets 90ksat out of a total of 100ksat: 1) `C` creates an invoice with payment hash `H` for 90ksat and sends it to `B` 2) `B` creates an invoice with payment hash `H` (same as the first invoice, but `B` doesn't know the preimage) for 100ksat (maybe plus a tiny bit for routing fees between `B` and `C`). 3) `A` receives an invoice which appears to be from `B` for the expected total of 100ksat. 4) `A` proceeds to pay the invoice to `B` like normal 5) `B` receives the incoming payment, but doesn't have the preimage for `H`, so they must forward to `C` if they want to receive their share. `B` then proceeds to pay the 90ksat invoice from `C`, which reveals the preimage to them, and they can turn around and claim the incoming `100ksat` (covering both `B` and `C` share) It's a poor man's version because it requires creating two invoices and `B` sees two payments (100ksat incoming, 90ksat outgoing), but the overall outcome is the desired one: either both parties get paid or noone gets paid. This can trivially be extended to any number of parties (with reduced success probability), and will remain atomic. It also doesn't require any changes on the sender side, and only minimal setup between the payees. The crux here is that we somehow need to ensure `H` is always the same along the entire chain of payments, but with a good coordination protocol that should be feasible. Regards, Christian Ronan McGovern <Ronan at trelis.com> writes: > Hi folks, I'm Ronan - based in Dublin and building Trelis.com (simple > payment links to accept Lightning). > > I'm wondering if there is a way to create an invoice that splits the > payment to two lightning addresses? > > If not, what would be required to develop this? > * A protocol change? > * Could it be built with the current protocol (I see an app on LN Bits to > split but it doesn't seem to work). > > Many thanks, Ronan > > Ronan McGovern > www.Trelis.com > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev