š
Original date posted:2021-12-17
š Original message:
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
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-09 13:04:52
in reply to nevent1qā¦8lvy
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 13:04:52Event JSON
{
"id": "16d6026b9731b9c0cc1467128ad5c242fe8db4dfd983f94a06f441ebdfea428d",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315892,
"kind": 1,
"tags": [
[
"e",
"8c6278694c01face680b94987df6ea625124b2f1ccfcb1675ab1dc9b1b77fdd4",
"",
"root"
],
[
"e",
"52b9f22296f4cf5d5719a82af0aad6c3c97b09d2f238045f22d058b194777a07",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "š
Original date posted:2021-12-17\nš Original message:\nGood morning cdecker,\n\n\u003e 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.\n\nIndeed, 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.\n\n\u003e\n\u003e 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.\n\nWell, the point of an `hsmd` is that it might be replaced with a driver to an actual hardware signing module (H S M).\nThe `lightningd`\u003c-\u003e`hsmd` interface includes commands for invoice signing, and `signfakeinvoice` would essentially just expose that interface, so an HSM has to support that interface.\nSo 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.\nThis 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.\n\nRegards,\nZmnSCPxj",
"sig": "696b77965af6c29a86138a55d95007e32eb9ea77adf29836e048dc7eb7565c56aeabd322b7458d648badffdba381f7bcac419baaac58617709d32a25b08e76ea"
}