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