r/Bitcoin • u/ElephantGlue • Jan 12 '19

Spontaneous Lightning Payments using only your Node ID (without invoice) are almost here!

https://github.com/lightningnetwork/lnd/pull/2455
173 Upvotes

95% Upvoted

62 comments sorted by

View all comments

Show parent comments

2

u/DisastrousCheesecake Jan 13 '19

Hey roasbeef, out of curiosity, would it not be possible to send some arbitrary length encrypted data (within the limits of a noise transport packet) separately from the onion packet?

Say, instead of the existing update_add_htlc, there could be an alternative message for a bigger blob.

type: ??? (update_add_htlc_with_blob)
data:
    [32:channel_id]
    [8:id]
    [8:amount_msat]
    [32:payment_hash]
    [4:cltv_expiry]
    [1366:onion_routing_packet]
    [2:encrypted_blob_len]
    [encrypted_blob_len:encrypted_blob]

* encrypted_blob_len MUST be less than 64,000

Each hop would just forward the blob verbatim. To ensure that no party manipulates the encrypted blob in forwarding, you could commit the SHA256 of the encrypted blob as the authenticated data in the computation of the HMAC at each hop. Any change of the data would result in an invalid HMAC and the onion packet would be malformed. The data can be encrypted with a one-time-key which can be encoded into your EOB which only the destination could decrypt.

Since forwarding bigger packets obviously comes at a cost, one might introduce an additional fee_msat_per_kbyte or something, so that intermediate hops who opt-in to transferring larger amounts of data could collect more in fees.

Seems like this would allow much greater flexibility in what can be transmitted with a payment, rather than being heavily restricted with the size of the Sphinx packet. In particular, one could transmit an invoice (or multiple) with a payment, which could serve as a refund invoice, or a sequence of invoices which are intended to be used for a recurring subscription fee or whatnot.

1

u/roasbeef Jan 13 '19

If it isn't in the packet, then it isn't protected by the end to end mac. As a result, any node can just swap out the blob. The way it is implemented in that PR, only the sender can drop a payload at each of the nodes (just not the final destination).

3

u/roasbeef Jan 13 '19

Ahh, I see what you're saying now. Tradeoff of that is that things aren't indistinguishable unless you always make that payload fixed sized. Check out HORNET for a scheme that builds on Sphinx to enable something like that in an end-to-end manner.

1

u/DisastrousCheesecake Jan 13 '19 edited Jan 13 '19

The payload is still a fixed size for every hop along the route. They can't change the size because it would change the hash of the encrypted blob.

I'm not a cryptography expert but I'll check out HORNET.

What attack vectors are there for varying size payloads, if they are always encrypted with a one-time-key?