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