Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-17 📝 Original message: I was looking into the ...
📅 Original date posted:2021-12-17
📝 Original message:
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.
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.
Each recipient will have to run the plugin otherwise they'd not understand
how to handle the payment, and creating an invoice requires a bit more work
(each payee needs to coordinate to be part of the Rendez-vous), but from
the senders point of view it's all seamless.
As for whether this is better suited for the protocol itself: could be,
probably not though. We let everybody experiment and then formalize and
standardize the best ideas from the community, so it may make its way into
the spec, but would need to be implemented, tested and popular enough to
warrant everybody having to implement yet another feature. In this case
it's more for a bLiP, which are less formal and better match the fact that
only a small part of the network needs to implement it (only payees need to
coordinate and forward, senders and everybody else doesn't care).
Cheers,
Christian
[1] https://lightning.readthedocs.io/lightning-createinvoice.7.html
On Fri, 17 Dec 2021, 11:22 Ronan McGovern, <Ronan at trelis.com> wrote:
> Hi ZmnSCPxj,
>
> So, are you saying there needs to be a new command "signfakeinvoice" at
> the protocol level?
>
> If that was there, how much work/hours would it be to build the poor man's
> rendez-vous at the application level?
>
> If the above were to be implemented, when the payer pays the invoice, it's
> then automatically split and sent to two (or more) recipients?
>
> Lastly, would it make more sense to have split payments at the protocol
> level?
>
> Thanks, Ronan
>
> On Thu, Dec 16, 2021 at 11:44 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning William,
>>
>>
>> > Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would
>> > it be, could it be done with a clightning plugin perhaps?
>>
>> Probably not *yet*; it needs each intermediate payee (i.e. the one that
>> is not the last one) to sign an invoice for which it does not know the
>> preimage.
>> Maybe call such a command `signfakeinvoice`.
>>
>> However, if a command to do the above is implemented (it would have to
>> generate and sign the invoice, but not insert it into the database at all),
>> then intermediate payees can use `htlc_accepted` hook for the "rendez-vous".
>>
>> So to generate the invoice:
>>
>> * Arrange the payees in some agreed fixed order.
>> * Last payee generates a normal invoice.
>> * From last payee to second, each one:
>> * Passes its invoice to the previous payee.
>> * The previous payee then creates its own signed invoice with
>> `signfakeinvoice` to itself, adding its payout plus a fee budget, as well
>> as adding its own delay budget.
>> * The previous payee plugin stores the next-payee invoice and the
>> details of its own invoice to db, such as by `datastore` command.
>> * The first payee sends the sender the invoice.
>>
>> On payment:
>>
>> * The sender sends the payment to the first hop.
>> * From first payee to second-to-last:
>> * Triggers `htlc_accepted` hook, and plugin checks if the incoming
>> payment has a hash that is in this scheme stored in the database.
>> * The plugin gathers `htlc_accepted` hook invocations until they sum up
>> to the expected amount (this handles multipath between payees).
>> * The plugin marks that it has gathered all `htlc_accepted` hooks for
>> that hash in durable storage a.k.a. `datastore` (this handles a race
>> condition where the plugin is able to respond to some `htlc_accepted`
>> hooks, but the node is restarted before all of them were able to be
>> recorded by C-Lightning in its own database --- this makes the plugin skip
>> the "gathering" step above, once it has already gathered them all before).
>> * The plugin checks if there is already an outgoing payment for that
>> hash (this handles the case where our node gets restarted in the meantime
>> --- C-Lightning will reissue `htlc_accepted` on startup)
>> * If the outgoing payment exists and is pending, wait for it to
>> resolve to either success or failure.
>> * If the outgoing payment exists and succeeded, resolve all the
>> gathered `htlc_accepted` hooks.
>> * If the outgoing payment exists and failed, fail all the gathered
>> `htlc_accepted` hooks.
>> * Otherwise, perform a `pay`, giving `maxfeepercent` and `maxdelay`
>> based on its fee budget and delay budget.
>> When the `pay` succeeds or fails, propagate it to the gathered
>> `htlc_accepted` hooks.
>> * The last payee just receives a normal payment using the normal
>> invoice-receive scheme.
>>
>> Regards,
>> ZmnSCPxj
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211217/ad84b53b/attachment-0001.html>;
📝 Original message:
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.
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.
Each recipient will have to run the plugin otherwise they'd not understand
how to handle the payment, and creating an invoice requires a bit more work
(each payee needs to coordinate to be part of the Rendez-vous), but from
the senders point of view it's all seamless.
As for whether this is better suited for the protocol itself: could be,
probably not though. We let everybody experiment and then formalize and
standardize the best ideas from the community, so it may make its way into
the spec, but would need to be implemented, tested and popular enough to
warrant everybody having to implement yet another feature. In this case
it's more for a bLiP, which are less formal and better match the fact that
only a small part of the network needs to implement it (only payees need to
coordinate and forward, senders and everybody else doesn't care).
Cheers,
Christian
[1] https://lightning.readthedocs.io/lightning-createinvoice.7.html
On Fri, 17 Dec 2021, 11:22 Ronan McGovern, <Ronan at trelis.com> wrote:
> Hi ZmnSCPxj,
>
> So, are you saying there needs to be a new command "signfakeinvoice" at
> the protocol level?
>
> If that was there, how much work/hours would it be to build the poor man's
> rendez-vous at the application level?
>
> If the above were to be implemented, when the payer pays the invoice, it's
> then automatically split and sent to two (or more) recipients?
>
> Lastly, would it make more sense to have split payments at the protocol
> level?
>
> Thanks, Ronan
>
> On Thu, Dec 16, 2021 at 11:44 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning William,
>>
>>
>> > Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would
>> > it be, could it be done with a clightning plugin perhaps?
>>
>> Probably not *yet*; it needs each intermediate payee (i.e. the one that
>> is not the last one) to sign an invoice for which it does not know the
>> preimage.
>> Maybe call such a command `signfakeinvoice`.
>>
>> However, if a command to do the above is implemented (it would have to
>> generate and sign the invoice, but not insert it into the database at all),
>> then intermediate payees can use `htlc_accepted` hook for the "rendez-vous".
>>
>> So to generate the invoice:
>>
>> * Arrange the payees in some agreed fixed order.
>> * Last payee generates a normal invoice.
>> * From last payee to second, each one:
>> * Passes its invoice to the previous payee.
>> * The previous payee then creates its own signed invoice with
>> `signfakeinvoice` to itself, adding its payout plus a fee budget, as well
>> as adding its own delay budget.
>> * The previous payee plugin stores the next-payee invoice and the
>> details of its own invoice to db, such as by `datastore` command.
>> * The first payee sends the sender the invoice.
>>
>> On payment:
>>
>> * The sender sends the payment to the first hop.
>> * From first payee to second-to-last:
>> * Triggers `htlc_accepted` hook, and plugin checks if the incoming
>> payment has a hash that is in this scheme stored in the database.
>> * The plugin gathers `htlc_accepted` hook invocations until they sum up
>> to the expected amount (this handles multipath between payees).
>> * The plugin marks that it has gathered all `htlc_accepted` hooks for
>> that hash in durable storage a.k.a. `datastore` (this handles a race
>> condition where the plugin is able to respond to some `htlc_accepted`
>> hooks, but the node is restarted before all of them were able to be
>> recorded by C-Lightning in its own database --- this makes the plugin skip
>> the "gathering" step above, once it has already gathered them all before).
>> * The plugin checks if there is already an outgoing payment for that
>> hash (this handles the case where our node gets restarted in the meantime
>> --- C-Lightning will reissue `htlc_accepted` on startup)
>> * If the outgoing payment exists and is pending, wait for it to
>> resolve to either success or failure.
>> * If the outgoing payment exists and succeeded, resolve all the
>> gathered `htlc_accepted` hooks.
>> * If the outgoing payment exists and failed, fail all the gathered
>> `htlc_accepted` hooks.
>> * Otherwise, perform a `pay`, giving `maxfeepercent` and `maxdelay`
>> based on its fee budget and delay budget.
>> When the `pay` succeeds or fails, propagate it to the gathered
>> `htlc_accepted` hooks.
>> * The last payee just receives a normal payment using the normal
>> invoice-receive scheme.
>>
>> Regards,
>> ZmnSCPxj
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211217/ad84b53b/attachment-0001.html>;