📅 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
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 13:04:50
in reply to nevent1q…pfau
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 13:04:50Event JSON
{
"id": "a5d9b4b51ff5cb56cb0dbd8e183f4fd1d4d9c32a47b52fb76d4f269aaacd64d8",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315890,
"kind": 1,
"tags": [
[
"e",
"8c6278694c01face680b94987df6ea625124b2f1ccfcb1675ab1dc9b1b77fdd4",
"",
"root"
],
[
"e",
"f42c60752230d62191b2e706aab40206f66b6298f9553df11e2ea7016716d36e",
"",
"reply"
],
[
"p",
"6fb2fd1f8df298fef3464d220666d5ae7184dfe89dc5cc7d3a177579986c31cb"
]
],
"content": "📅 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",
"sig": "fc8f74d18290e918332124a568f3e9352863d7a89361feb03584951be9a902c5eece5fcd8b60b6b9d2918c0cca7599c67e3a5bac154ad02afb12433ca62e9ff9"
}