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 <zmnsc...@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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
