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 <ro...@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
