Implement non-interactive payments by including the preimage in the Sphinx e2e payload

[Roasbeef]

With the current implementation there are two ways to send a payment to a remote node:

1. Receive an invoice from them, and fulfill that invoice using the SendPayment RPC.
2. Both the sender and receiver have been started with the --debug_htlc flag, and the sender sends a payment using the hard-coded "debug" preimage value within the HTLC.

A third mode is possible which is similar to the second payment route, but can be used in a "production" network as it'll properly generate a brand new preimage with each payment. This third mode is what I've been calling "sphinx send" (or "onion send", dunno). In this mode the sender generates the preimage for a targeted payment, and includes the pre-image either in the e2e payload, or the per-hop payload within the Sphinx packet embedded within the outgoing HTLC.

It is important to note, that this mode should not be used for retail or b2c payments. This is due to the fact that one is unable to properly obtain assigned proof-of-payment receipt as the sender generates the pre-image instead of the receiver int his mode. However, for paying a friend of LN, or other cases which don't require a verifiable proof-of-payment, then this mode allows for non-interactive payments. If a remote node accepts such payments (which should be denoted it it's global_features vector), then the node can simply advertise it's public key and that is all that's needed for other modes to send them payments.

Steps To Completion

• Modify the logic in the routing module to accept an additional attribute to routing.LightningPayment request struct which toggles if a sphinx_send should be attempted or not. If so, then the last per-hop-payload should be modified to include a preimage generated by the sending node.

• Within the peer struct's htlcManager goroutine, when an incoming HTLC arrives and we're the exit node but we can't find the preimage within the invoiceManager, then the per-hop-payload should be checked for a valid pre-image. If one matches, then that should be used to settle the HTLC, and all logic should proceed as normal.

• The SendPaymentRequest struct should also be modified to add sphinx_send bool. On the server side, this bool should be passed into routing.LightningPayment request struct.

• Finally, the additional argument should be added to the lncli tool.

• A set of bits in the global_features should be allocated to signal knowledge of this new feature. If a user attempts to trigger a sphinx_send to a node that doesn't have these bits advertised, then the payment should fail.

A set of integration tests should be added to ensure the proper propagation and handling of sphinx_send payments within the network.

[BitfuryLightning]

Can I take this?

[Roasbeef]

I consider this issue to be of a rather low priority. It doesn't require any modifications to the spec instead, but instead should be coupled with a signaling mechanism to use the extra bytes in the payload to signal that some, or all of the remaining per-hop payloads are to be decrypted as they're a complete package.

It's worth nothing though, that this feature isn't incompatible with obtaining a signed receipt as the encrypted error replies can slightly abused to (using the extra payload bytes to signal) request a signed invoice for a particular amount, returning the replay over an encapsulated "error".

[Roasbeef]

Adding to the description in the issue, the following change needs to be made in lightning-onion:

• Rather than _discarding) the currently un-used payload when parsing a sphinx packet, the value should instead be embedded within the HopData as a new field of type []byte

To accompany this change, the htlcswitch.ForwardingInfo struct should be modified to either opaquely embed the unused per-hop data, or create a set of abstractions around the unused payload, the first of which would define the interpretation and parameters for this feature.

We have a choice here w.r.t whether to define a generic extension mechanism now that uses 2-bytes to denote the interpretation of the payload, and then extend the payload over excess hops in the sphinx packet, or just use the 8+8+4+12 bytes to encode the payment pre-image in full.

[stevenroose]

Is there a spec for this so that other implementations can receive these payments?

[andrewshvv]

Hey @stevenroose ! No there is no yet, but I have implementation of it locally.

[meeDamian]

Wouldn't it make more sense to add a requestinvoice method to a spec, that would return a short-lived invoice to a requesting node?

[Roasbeef]

This is a single shot. It also doesn't require changes at the core, it's end to end. On Jun 27, 2018 9:55 PM, "Damian Mee" <notifications@github.com> wrote: Wouldn't it make more sense to add a requestinvoice method to a spec, that would return a short-lived invoice to a requesting node? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#132 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA87LmQmVv-7WUMdg6YjKhXtPdGexLulks5uBGGugaJpZM4L-Xsw> .

[Roasbeef]

Will be fixed by #2455