Re: [Lightning-dev] Split payments within one LN invoice

2021-12-16 Thread Christian Decker
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

Re: [Lightning-dev] A blame ascribing protocol towards ensuring time limitation of stuck HTLCs in flight.

2021-12-16 Thread ZmnSCPxj via Lightning-dev
Good morning Bastien, > * it's impossible for a node to prove that it did *not* receive a message: > you can prove knowledge, >   but proving lack of knowledge is much harder (impossible?) Yes, it is impossible. If there could exist a proof-of-lack-of-knowledge, then even if I personally

Re: [Lightning-dev] Split payments within one LN invoice

2021-12-16 Thread William Casarin
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

Re: [Lightning-dev] Split payments within one LN invoice

2021-12-16 Thread ZmnSCPxj via Lightning-dev
Good morning William, > 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? Probably not *yet*; it needs each intermediate payee (i.e. the one that is not the last one) to sign an invoice for which it does not know