[Lightning-dev] ECDH for spontaneous payments and offline vending machines

[ZmnSCPxj]

Good morning Stepan,



> Hi ZmnSCPxj,
>
> > The online node in your proposal is unable to extract `K`, a the next-node-ID is never transmitted.
>
> Then currently for the vending machines we can use a pre-shared common secret set up at installation time (may be unique for every machine) and use it for preimage generation:
>
> preimage = hmac(common_secret, amount | nonce)
>
> We can pass this nonce as a channel id. This is exactly what we did for the hackathon project. Such invoice has to be paid with exact amount, there is no way to include a tip - otherwise preimage generation will fail.

I observe that any tip worth its name would be a positive delta over the invoice face value.

Thus, if you want to accept tips up to (say) 25% above the invoice face value, you can just iterate from `amount_to_forward` down to `0.8 * amount_to_forward` and see if it yields a preimage that matches the payment hash.

This may require some grinding; but remember that you have several blocks in which you can compute this.

This is particularly relevant for older versions of C-lightning which implemented value randomization (i.e. adding a small random tip in an attempt to fool analysts from determining the actual value being paid --- BOLT spec specifically allows this behavior).
(This was inadvertently removed/not implemented in newer versions after the pay algorithm was moved to a plugin; since nobody but me was interested in value randomization anyway, I decided not to reimplement it until somebody else asks for it)


> Online node can try to generate the preimage for every htlc offer with all known common secrets and the channel ID, and if it fails - try to route the payment as usual.

It is probably faster on most implementations to look up the channel ID in some hash table first, i.e. try to route first before generating preimages.
Of course, 64-bit `short_channel_id` as nonce is likely to hit a "real" channel ID, but you can avoid this by restricting the range to far-future blockheights and/or before the `when_lightning_became_cool` blockheight.


Regards,
ZmnSCPxj