Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-04 📝 Original message: darosior via ...
📅 Original date posted:2020-02-04
📝 Original message:
darosior via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> Hi Pavol,
>
>> 1) Is c-lightning going to support Sphinx or other form of
>> spontaneous payments?
>
> I think cdecker is working on integrating keysend to his noise plugin
> (https://github.com/lightningd/plugins/pull/68).
The keysend functionality is implemented in the noise plugin and I am
planning to pull the keysend part out of the plugin, since that part is
really trivial to implement (`htlc_accepted` hook that checkes the
payment_hash against the preimage in the onion, then tell `lightningd`
to resolve directly).
As a side note: Sphinx-send is a terrible misnomer, since sphinx is the
name of our onion construction, keysend is the proper name to use in
this case.
>> 2) Can a lightning node (such as lnd or c-lightning) send a push
>> notification (e.g. to a webhook) when it receives or routes a
>> payment? If yes, is this notification cryptographically signed (for
>> example with the node's private key)? Is this documented somewhere?
>
> C-lightning sends notifications (and hooks, but it doesn't seem to be
> your usecase here) for typical events such as "I received an HTLC
> !". You can make a plugin which registers to these lightningd
> notifications sends encrypted push notifs. Doc here
> https://lightning.readthedocs.io/PLUGINS.html#event-notifications :-).
You can have a plugin subscribe to HTLC related events (such as
`forward_event` [1], or `invoice_payment` [2], to get notified about
forwardings or invoices being paid. What you do with that notification
then is up to you. It could queue the event in kafka, call out to a
webhook, or log a message with a log management system. You can
arbitrarily transform the event in the plugin, including issuing calls
to `signmessage` which will create a signature for the event message,
thus allowing you to prove authenticity of the message. You'd most
likely need to canonicalize the message before signing, since JSON is
not the best format for canonical serialization, i.e., decoding and
re-encoding can result in subtle changes, which could then fail
signature verification, but that should not be a major issue.
Cheers,
Christian
📝 Original message:
darosior via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> Hi Pavol,
>
>> 1) Is c-lightning going to support Sphinx or other form of
>> spontaneous payments?
>
> I think cdecker is working on integrating keysend to his noise plugin
> (https://github.com/lightningd/plugins/pull/68).
The keysend functionality is implemented in the noise plugin and I am
planning to pull the keysend part out of the plugin, since that part is
really trivial to implement (`htlc_accepted` hook that checkes the
payment_hash against the preimage in the onion, then tell `lightningd`
to resolve directly).
As a side note: Sphinx-send is a terrible misnomer, since sphinx is the
name of our onion construction, keysend is the proper name to use in
this case.
>> 2) Can a lightning node (such as lnd or c-lightning) send a push
>> notification (e.g. to a webhook) when it receives or routes a
>> payment? If yes, is this notification cryptographically signed (for
>> example with the node's private key)? Is this documented somewhere?
>
> C-lightning sends notifications (and hooks, but it doesn't seem to be
> your usecase here) for typical events such as "I received an HTLC
> !". You can make a plugin which registers to these lightningd
> notifications sends encrypted push notifs. Doc here
> https://lightning.readthedocs.io/PLUGINS.html#event-notifications :-).
You can have a plugin subscribe to HTLC related events (such as
`forward_event` [1], or `invoice_payment` [2], to get notified about
forwardings or invoices being paid. What you do with that notification
then is up to you. It could queue the event in kafka, call out to a
webhook, or log a message with a log management system. You can
arbitrarily transform the event in the plugin, including issuing calls
to `signmessage` which will create a signature for the event message,
thus allowing you to prove authenticity of the message. You'd most
likely need to canonicalize the message before signing, since JSON is
not the best format for canonical serialization, i.e., decoding and
re-encoding can result in subtle changes, which could then fail
signature verification, but that should not be a major issue.
Cheers,
Christian