ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-17 📝 Original message: Good morning Ronan, > If ...
📅 Original date posted:2021-12-17
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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
📝 Original message:
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 <ZmnSCPxj at protonmail.com> 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