From ZmnSCPxj at protonmail.com Sat Dec 18 00:22:56 2021 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Sat, 18 Dec 2021 00:22:56 +0000 Subject: [Lightning-dev] Split payments within one LN invoice In-Reply-To: References: <87wnk46e0a.fsf@gmail.com> <20211216170542.h73xw4p2her2ctjp@quiver> Message-ID: 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