From Ronan at trelis.com Fri Dec 17 18:29:39 2021 From: Ronan at trelis.com (Ronan McGovern) Date: Fri, 17 Dec 2021 18:29:39 +0000 Subject: [Lightning-dev] Split payments within one LN invoice In-Reply-To: References: <87wnk46e0a.fsf@gmail.com> <20211216170542.h73xw4p2her2ctjp@quiver> Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: