From jb55 at jb55.com  Thu Dec 16 17:05:42 2021
From: jb55 at jb55.com (William Casarin)
Date: Thu, 16 Dec 2021 09:05:42 -0800
Subject: [Lightning-dev] Split payments within one LN invoice
In-Reply-To: <87wnk46e0a.fsf@gmail.com>
References: <CAMMBWotO1hq6_PvXcg+cTbST8sizqsjXXNv3ukdF9Mq=4DsGYw@mail.gmail.com>
 <87wnk46e0a.fsf@gmail.com>
Message-ID: <20211216170542.h73xw4p2her2ctjp@quiver>

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