William Casarin [ARCHIVE] on Nostr: đ Original date posted:2021-12-16 đ Original message: Hey Christian, On Thu, ...
đ
Original date posted:2021-12-16
đ Original message:
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
đ Original message:
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