Re: [Lightning-dev] Split payments within one LN invoice
Good morning Ronan, > If there is a payment to go from party A to be split between parties B & C, > is it possible that only one of B or C would need a plugin? > > If all receiving parties need a plugin that is quite limiting. Thanks, Ronan Given N payees, only N - 1 need the plugin. The last payee in a chain of payees issues a normal invoice (C-Lightning plugin not needed). Then the previous payee takes in that invoice, and emits a new invoice, using the plugin. This goes on until the first payee is reached. The first payee then issues its invoice to the payer. To follow your example, where A pays to both B and C: * C issues a normal invoice (no plugin needed). * C hands its invoice over to B. * B receives the invoice from C and issues a plugin-provided command (`addtoinvoice`?), which creates another invoice * B hands its invoice over to A. * A pays the invoice (no plugin needed). As another example, suppose we have you paying cdecker, jb55, and ZmnSCPxj. Let us sort them in alphabetical order. * ZmnSCPxj issues a normal invoice (no plugin needed). * ZmnSCPxj hands its invoice over to jb55. * jb55 issues a plugin-provided command, giving it the invoice from ZmnSCPxj and getting out a larger invoice. * jb55 hands its invoice over to cdecker. * cdecker issues a plugin-provided command, giving it the invoice from jb55 and getting out a larger invoice. * cdecker hands over its invoice to Ronan. * Ronan pays the invoice (no plugin needed). Regards, ZmnSCPxj > > On Fri, Dec 17, 2021 at 3:06 PM ZmnSCPxj wrote: > > > Good morning cdecker, > > > > > I was looking into the docs [1] and stumbled over `createinvoice` which > > > does almost what you need. However it requires the preimage, and stores > > > the invoice in the database which you don't want. > > > > Indeed, that is precisely the issue, we need a `signfakeinvoice` command, > > as we cannot know at invoice creation time the preimage, and our invoice > > database currently assumes every invoice has a preimage known and recorded > > in the database. > > > > > > > > However if you have access to the `hsm_secret` you could sign in the > > > plugin itself, completely sidestepping `lightningd`. Once you have that > > > it should be a couple of days work to get a PoC plugin for the > > > coordination and testing. From there it depends on how much polish you > > > want to apply and what other systems you want to embed it into. > > > > Well, the point of an `hsmd` is that it might be replaced with a driver to > > an actual hardware signing module (H S M). > > The `lightningd`<->`hsmd` interface includes commands for invoice signing, > > and `signfakeinvoice` would essentially just expose that interface, so an > > HSM has to support that interface. > > So a plugin cannot rely on `hsm_secret` existing, as the signer might not > > be emulated in software (i.e. what we do now) but be an actual hardware > > signer that does not keep the secret keys on the same disk. > > This is the reason why we (well, I) created and exposed `getsharedsecret`, > > in theory a plugin could just read `hsm_secret`, but we want to consider a > > future where the HSM is truly a hardware module. > > > > Regards, > > ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
If there is a payment to go from party A to be split between parties B & C, is it possible that only one of B or C would need a plugin? If all receiving parties need a plugin that is quite limiting. Thanks, Ronan On Fri, Dec 17, 2021 at 3:06 PM ZmnSCPxj wrote: > Good morning cdecker, > > > I was looking into the docs [1] and stumbled over `createinvoice` which > does almost what you need. However it requires the preimage, and stores the > invoice in the database which you don't want. > > Indeed, that is precisely the issue, we need a `signfakeinvoice` command, > as we cannot know at invoice creation time the preimage, and our invoice > database currently assumes every invoice has a preimage known and recorded > in the database. > > > > > However if you have access to the `hsm_secret` you could sign in the > plugin itself, completely sidestepping `lightningd`. Once you have that it > should be a couple of days work to get a PoC plugin for the coordination > and testing. From there it depends on how much polish you want to apply and > what other systems you want to embed it into. > > Well, the point of an `hsmd` is that it might be replaced with a driver to > an actual hardware signing module (H S M). > The `lightningd`<->`hsmd` interface includes commands for invoice signing, > and `signfakeinvoice` would essentially just expose that interface, so an > HSM has to support that interface. > So a plugin cannot rely on `hsm_secret` existing, as the signer might not > be emulated in software (i.e. what we do now) but be an actual hardware > signer that does not keep the secret keys on the same disk. > This is the reason why we (well, I) created and exposed `getsharedsecret`, > in theory a plugin could just read `hsm_secret`, but we want to consider a > future where the HSM is truly a hardware module. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
Good morning cdecker, > I was looking into the docs [1] and stumbled over `createinvoice` which does > almost what you need. However it requires the preimage, and stores the > invoice in the database which you don't want. Indeed, that is precisely the issue, we need a `signfakeinvoice` command, as we cannot know at invoice creation time the preimage, and our invoice database currently assumes every invoice has a preimage known and recorded in the database. > > However if you have access to the `hsm_secret` you could sign in the plugin > itself, completely sidestepping `lightningd`. Once you have that it should be > a couple of days work to get a PoC plugin for the coordination and testing. > From there it depends on how much polish you want to apply and what other > systems you want to embed it into. Well, the point of an `hsmd` is that it might be replaced with a driver to an actual hardware signing module (H S M). The `lightningd`<->`hsmd` interface includes commands for invoice signing, and `signfakeinvoice` would essentially just expose that interface, so an HSM has to support that interface. So a plugin cannot rely on `hsm_secret` existing, as the signer might not be emulated in software (i.e. what we do now) but be an actual hardware signer that does not keep the secret keys on the same disk. This is the reason why we (well, I) created and exposed `getsharedsecret`, in theory a plugin could just read `hsm_secret`, but we want to consider a future where the HSM is truly a hardware module. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
I was looking into the docs [1] and stumbled over `createinvoice` which does almost what you need. However it requires the preimage, and stores the invoice in the database which you don't want. However if you have access to the `hsm_secret` you could sign in the plugin itself, completely sidestepping `lightningd`. Once you have that it should be a couple of days work to get a PoC plugin for the coordination and testing. From there it depends on how much polish you want to apply and what other systems you want to embed it into. Each recipient will have to run the plugin otherwise they'd not understand how to handle the payment, and creating an invoice requires a bit more work (each payee needs to coordinate to be part of the Rendez-vous), but from the senders point of view it's all seamless. As for whether this is better suited for the protocol itself: could be, probably not though. We let everybody experiment and then formalize and standardize the best ideas from the community, so it may make its way into the spec, but would need to be implemented, tested and popular enough to warrant everybody having to implement yet another feature. In this case it's more for a bLiP, which are less formal and better match the fact that only a small part of the network needs to implement it (only payees need to coordinate and forward, senders and everybody else doesn't care). Cheers, Christian [1] https://lightning.readthedocs.io/lightning-createinvoice.7.html On Fri, 17 Dec 2021, 11:22 Ronan McGovern, wrote: > Hi ZmnSCPxj, > > So, are you saying there needs to be a new command "signfakeinvoice" at > the protocol level? > > If that was there, how much work/hours would it be to build the poor man's > rendez-vous at the application level? > > If the above were to be implemented, when the payer pays the invoice, it's > then automatically split and sent to two (or more) recipients? > > Lastly, would it make more sense to have split payments at the protocol > level? > > Thanks, Ronan > > On Thu, Dec 16, 2021 at 11:44 PM ZmnSCPxj wrote: > >> 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 the >> preimage. >> Maybe call such a command `signfakeinvoice`. >> >> However, if a command to do the above is implemented (it would have to >> generate and sign the invoice, but not insert it into the database at all), >> then intermediate payees can use `htlc_accepted` hook for the "rendez-vous". >> >> So to generate the invoice: >> >> * Arrange the payees in some agreed fixed order. >> * Last payee generates a normal invoice. >> * From last payee to second, each one: >> * Passes its invoice to the previous payee. >> * The previous payee then creates its own signed invoice with >> `signfakeinvoice` to itself, adding its payout plus a fee budget, as well >> as adding its own delay budget. >> * The previous payee plugin stores the next-payee invoice and the >> details of its own invoice to db, such as by `datastore` command. >> * The first payee sends the sender the invoice. >> >> On payment: >> >> * The sender sends the payment to the first hop. >> * From first payee to second-to-last: >> * Triggers `htlc_accepted` hook, and plugin checks if the incoming >> payment has a hash that is in this scheme stored in the database. >> * The plugin gathers `htlc_accepted` hook invocations until they sum up >> to the expected amount (this handles multipath between payees). >> * The plugin marks that it has gathered all `htlc_accepted` hooks for >> that hash in durable storage a.k.a. `datastore` (this handles a race >> condition where the plugin is able to respond to some `htlc_accepted` >> hooks, but the node is restarted before all of them were able to be >> recorded by C-Lightning in its own database --- this makes the plugin skip >> the "gathering" step above, once it has already gathered them all before). >> * The plugin checks if there is already an outgoing payment for that >> hash (this handles the case where our node gets restarted in the meantime >> --- C-Lightning will reissue `htlc_accepted` on startup) >> * If the outgoing payment exists and is pending, wait for it to >> resolve to either success or failure. >> * If the outgoing payment exists and succeeded, resolve all the >> gathered `htlc_accepted` hooks. >> * If the outgoing payment exists and failed, fail all the gathered >> `htlc_accepted` hooks. >> * Otherwise, perform a `pay`, giving `maxfeepercent` and `maxdelay` >> based on its fee budget and delay budget. >> When the `pay` succeeds or fails, propagate it to the gathered >> `htlc_accepted` hooks. >> * The last payee just receives a normal payment using the normal >> invoice-receive scheme. >> >> Regards, >> ZmnSCPxj >> >
Re: [Lightning-dev] Split payments within one LN invoice
Hi ZmnSCPxj, So, are you saying there needs to be a new command "signfakeinvoice" at the protocol level? If that was there, how much work/hours would it be to build the poor man's rendez-vous at the application level? If the above were to be implemented, when the payer pays the invoice, it's then automatically split and sent to two (or more) recipients? Lastly, would it make more sense to have split payments at the protocol level? Thanks, Ronan On Thu, Dec 16, 2021 at 11:44 PM ZmnSCPxj wrote: > 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 the > preimage. > Maybe call such a command `signfakeinvoice`. > > However, if a command to do the above is implemented (it would have to > generate and sign the invoice, but not insert it into the database at all), > then intermediate payees can use `htlc_accepted` hook for the "rendez-vous". > > So to generate the invoice: > > * Arrange the payees in some agreed fixed order. > * Last payee generates a normal invoice. > * From last payee to second, each one: > * Passes its invoice to the previous payee. > * The previous payee then creates its own signed invoice with > `signfakeinvoice` to itself, adding its payout plus a fee budget, as well > as adding its own delay budget. > * The previous payee plugin stores the next-payee invoice and the > details of its own invoice to db, such as by `datastore` command. > * The first payee sends the sender the invoice. > > On payment: > > * The sender sends the payment to the first hop. > * From first payee to second-to-last: > * Triggers `htlc_accepted` hook, and plugin checks if the incoming > payment has a hash that is in this scheme stored in the database. > * The plugin gathers `htlc_accepted` hook invocations until they sum up > to the expected amount (this handles multipath between payees). > * The plugin marks that it has gathered all `htlc_accepted` hooks for > that hash in durable storage a.k.a. `datastore` (this handles a race > condition where the plugin is able to respond to some `htlc_accepted` > hooks, but the node is restarted before all of them were able to be > recorded by C-Lightning in its own database --- this makes the plugin skip > the "gathering" step above, once it has already gathered them all before). > * The plugin checks if there is already an outgoing payment for that > hash (this handles the case where our node gets restarted in the meantime > --- C-Lightning will reissue `htlc_accepted` on startup) > * If the outgoing payment exists and is pending, wait for it to > resolve to either success or failure. > * If the outgoing payment exists and succeeded, resolve all the > gathered `htlc_accepted` hooks. > * If the outgoing payment exists and failed, fail all the gathered > `htlc_accepted` hooks. > * Otherwise, perform a `pay`, giving `maxfeepercent` and `maxdelay` > based on its fee budget and delay budget. > When the `pay` succeeds or fails, propagate it to the gathered > `htlc_accepted` hooks. > * The last payee just receives a normal payment using the normal > invoice-receive scheme. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
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 the preimage. Maybe call such a command `signfakeinvoice`. However, if a command to do the above is implemented (it would have to generate and sign the invoice, but not insert it into the database at all), then intermediate payees can use `htlc_accepted` hook for the "rendez-vous". So to generate the invoice: * Arrange the payees in some agreed fixed order. * Last payee generates a normal invoice. * From last payee to second, each one: * Passes its invoice to the previous payee. * The previous payee then creates its own signed invoice with `signfakeinvoice` to itself, adding its payout plus a fee budget, as well as adding its own delay budget. * The previous payee plugin stores the next-payee invoice and the details of its own invoice to db, such as by `datastore` command. * The first payee sends the sender the invoice. On payment: * The sender sends the payment to the first hop. * From first payee to second-to-last: * Triggers `htlc_accepted` hook, and plugin checks if the incoming payment has a hash that is in this scheme stored in the database. * The plugin gathers `htlc_accepted` hook invocations until they sum up to the expected amount (this handles multipath between payees). * The plugin marks that it has gathered all `htlc_accepted` hooks for that hash in durable storage a.k.a. `datastore` (this handles a race condition where the plugin is able to respond to some `htlc_accepted` hooks, but the node is restarted before all of them were able to be recorded by C-Lightning in its own database --- this makes the plugin skip the "gathering" step above, once it has already gathered them all before). * The plugin checks if there is already an outgoing payment for that hash (this handles the case where our node gets restarted in the meantime --- C-Lightning will reissue `htlc_accepted` on startup) * If the outgoing payment exists and is pending, wait for it to resolve to either success or failure. * If the outgoing payment exists and succeeded, resolve all the gathered `htlc_accepted` hooks. * If the outgoing payment exists and failed, fail all the gathered `htlc_accepted` hooks. * Otherwise, perform a `pay`, giving `maxfeepercent` and `maxdelay` based on its fee budget and delay budget. When the `pay` succeeds or fails, propagate it to the gathered `htlc_accepted` hooks. * The last payee just receives a normal payment using the normal invoice-receive scheme. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
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
Re: [Lightning-dev] Split payments within one LN invoice
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 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
Re: [Lightning-dev] Split payments within one LN invoice
On Wed, Dec 15, 2021 at 01:59:49PM -0800, William Casarin wrote: Hey Ronan, On Wed, Dec 15, 2021 at 05:33:51PM +, Ronan McGovern wrote: 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). This is typically done at the application level. The fountain podcasting app works this way and it seems to work okish. The tricky part is what to do when the payment partially fails. Perhaps you keep trying with exponential backoff until the payment completes for all parties. If this was handled at the protocol level, would you fail the entire transaction if one of the channels failed? This is the kind of business logic that would be tricky when designing a protocol-level solution to this. I think it's reasonable to handle this at the application level for now, but perhaps some standard protocols might be useful in the future. Cheers, Will ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Split payments within one LN invoice
Hey Ronan, On Wed, Dec 15, 2021 at 05:33:51PM +, Ronan McGovern wrote: 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). This is typically done at the application level. The fountain podcasting app works this way and it seems to work okish. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
