fiatjaf [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-21 📝 Original message: Indeed, sorry, I ...
📅 Original date posted:2021-09-21
📝 Original message:
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>;
📝 Original message:
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>;