rich1.0npub1d7e068ud72v0au6xf53qvek44eccfhlgnhzuclf6za6hnxrvx89sc93exjhttps://nostr.ae/npub1d7e068ud72v0au6xf53qvek44eccfhlgnhzuclf6za6hnxrvx89sc93exjnjumphttps://nostr.ae📅 Original date posted:2021-12-16 📝 Original message: Hey Christian, On Thu, Dec 16, 2021 at 11:27:33AM +0100, Christian Decker wrote: >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. This is very cool, at least for a small number of parties. When I was working at a record label it was very common to split between 1-5 people on a given track, being able to atomically payout to individual artist's lightning nodes would have been super useful at the time (assuming a world where our artists ran lightning nodes). At some point I was testing 600-output bitcoin transactions as a payout method, but that looked like it was going to be economically infeasible sometime in the future. Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would it be, could it be done with a clightning plugin perhaps? Cheers, Will