>
> > The conventional approach is to create a lightning invoice on a node and
> > store the invoice together with order details in a database. If the order
> > then goes unfulfilled, cleaning processes remove the data from the node
> > and database again.
>
> > The problem with this setup is that
Hi Joost,
> The conventional approach is to create a lightning invoice on a node and
> store the invoice together with order details in a database. If the order
> then goes unfulfilled, cleaning processes remove the data from the node
> and database again.
> The problem with this setup is that
On Tue, Sep 21, 2021 at 5:47 PM Bastien TEINTURIER wrote:
> Hi Joost,
>
> Concept ACK, I had toyed with something similar a while ago, but I hadn't
> realized
> that invoice storage was such a DoS vector for merchants/hubs and wasn't
> sure it
> would be useful.
>
Yes, I definitely think it is.
Hi Joost,
Concept ACK, I had toyed with something similar a while ago, but I hadn't
realized
that invoice storage was such a DoS vector for merchants/hubs and wasn't
sure it
would be useful.
Do you have an example of what information you would usually put in your
`encoded_order_details`?
I'd
On Tue, Sep 21, 2021 at 3:06 PM fiatjaf wrote:
> 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
>
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
On Tue, Sep 21, 2021 at 2:05 PM fiatjaf 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
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:
1. Payer requests an invoice.
2. Payee computes hash = sha256(hmac(local_secret, arbitrary_invoice_id)),
Good morning Joost,
> > > preimage = H(node_secret | payment_secret | payment_amount |
> > > encoded_order_details)
> > > invoice_hash = H(preimage)
> > >
> > > The sender sends an htlc locked to invoice_hash for payment_amount and
> > > passes along payment_secret and encoded_order_details in
Good morning again Joost,
> However, we can do "pay for signature" protocols using PTLCs, and rather than
> requesting for a scalar behind a point as the proof-of-payment, we can
> instead ask for a signature of a message that attests "this recipient got
> paid `payment_amount` with
Good morning Joost,
> It could be something like this:
>
> payment_secret = random
> preimage = H(node_secret | payment_secret | payment_amount |
> encoded_order_details)
> invoice_hash = H(preimage)
>
> The sender sends an htlc locked to invoice_hash for payment_amount and passes
> along
Problem
One of the qualities of lightning is that it can provide light-weight,
no-login payments with minimal friction. Games, paywalls, podcasts, etc can
immediately present a QR code that is ready for scan and pay.
Optimistically presenting payment requests does lead to many of those
payment
12 matches
Mail list logo
