From fiatjaf at gmail.com  Tue Sep 21 13:05:48 2021
From: fiatjaf at gmail.com (fiatjaf)
Date: Tue, 21 Sep 2021 10:05:48 -0300
Subject: [Lightning-dev] Stateless invoices with proof-of-payment
In-Reply-To: <CAJBJmV9JcVxE9nAir4WwR5A2Csum+PV-o4KqsqK5NLZBMRpZQg@mail.gmail.com>
References: <CAJBJmV_nazFFf1SDhzo2gLRDe+ASChPxWKPM4zG9ObtyaXz6KQ@mail.gmail.com>
 <CAEjd=rqgp3KewOwOHHfhF75tP3KD0bXXijKVGsyY4--mbM0vgQ@mail.gmail.com>
 <CAJBJmV9JcVxE9nAir4WwR5A2Csum+PV-o4KqsqK5NLZBMRpZQg@mail.gmail.com>
Message-ID: <CAEjd=rq2=CgyKi2r257s-qX6VmAuS-yT+gbF-VW2Q7cDas0F6w@mail.gmail.com>

Indeed, sorry, I misunderstood it because I read AMP/keysend and assumed
you were talking about payer-generated preimage.
It doesn't help that "payer" and "payee" are so similar words.

So yes, I agree very much.

I also think the part about including the order details inside the TLV
would be very good to have.

I would say, however, that these are two separate proposals:

  1. implementations should expose a "stateless invoice" API for receiving
using the payment_secret;
  2. when sending, implementations should attach a TLV record with encoded
order details.

Of these, 1 is very simple to do and do not require anyone to cooperate, it
just works.

2 requires full network compatibility, so it's harder. But 2 is also very
much needed otherwise the payee has to keep track of all the invoice ids
related to the orders they refer to, right? But I think just having 1
already improves the situation a lot, and there are application-specific
workarounds that can be applied for 2 (having a fixed, hardcoded set of
possible orders, encoding the order very minimally in the payment secret or
route hint, storing order details on redis for only 3 minutes and using
lnurlpay to reduce the delay between invoice issuance and user confirmation
to zero, and so on).

On Tue, Sep 21, 2021 at 9:41 AM Joost Jager <joost.jager at gmail.com> wrote:

> On Tue, Sep 21, 2021 at 2:05 PM fiatjaf <fiatjaf at gmail.com> wrote:
>
>> What if instead of the payer generating the preimage the payee could
>> generate stateless invoices? Basically just use some secret to compute the
>> preimage upon receiving the HTLC, for example:
>>
>
> Maybe my explanation wasn't clear enough, but this is exactly what I am
> proposing. The payee generates a stateless invoice and gives it to the
> payer.
>
>
>> 1. Payer requests an invoice.
>> 2. Payee computes hash = sha256(hmac(local_secret,
>> arbitrary_invoice_id)), then encodes arbitrary_invoice_id into the invoice
>> somehow.
>> 3. Payer sends payment with arbitrary_invoice_id as tlv_record_a.
>> 4. Upon receiving the HTLC, payee computes preimage = hmac(local_secret,
>> tlv_record_a) and resolves it.
>>
>
> One way to do this that I tried to describe in the initial post is via the
> payment_secret. This is already an arbitrary invoice id that is already
> sent as a tlv record.
>
>
>> I've implemented such a scheme on @lntxbot, but it required low level
>> code in a c-lightning plugin and a hack with route hints: since TLV
>> payloads were not an option (as payers wouldn't know how to send them) I've
>> used a "shadow" route hint to a private channel that didn't exist, so
>> preimage was generated on the payee using preimage = hmac(local_secret,
>> next_channel_scid).
>>
>
> Clever workaround.
>
> Joost
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/5b0b8328/attachment-0001.html>