Suggest adding optional extra parameters to LUD-06 callback endpoint: cltv_expiry and expiry.
With the rise of serverless Nostr apps, we may want hodl invoice functionality to allow trustless escrows to operate over lightning.
E.g. I launch a NIP-15 marketplace, and would like a 3rd party escrow to manage payments from buyers.
I don't want the escrow to custody the funds, so I need to generate an invoice myself and give the escrow just the hash.
When the buyer sends me a checkout message over nostr, the seller can trigger the escrow service, which looks up the seller's nostr profile, finds the lightning address, pings the lnurl address with some extra parameters to return an invoice that has a long enough timeout for the transaction.
E.g. 1 week until product is definitely shipped.
The escrow could also include json of the nostr event in question so that the lightning node can't be spammed by long-timeout-invoice creation requests that don't correspond to a real order.
Suggest adding optional extra parameters to LUD-06 callback endpoint: cltv_expiry and expiry.
With the rise of serverless Nostr apps, we may want hodl invoice functionality to allow trustless escrows to operate over lightning.
E.g. I launch a NIP-15 marketplace, and would like a 3rd party escrow to manage payments from buyers.
I don't want the escrow to custody the funds, so I need to generate an invoice myself and give the escrow just the hash.
When the buyer sends me a checkout message over nostr, the seller can trigger the escrow service, which looks up the seller's nostr profile, finds the lightning address, pings the lnurl address with some extra parameters to return an invoice that has a long enough timeout for the transaction.
E.g. 1 week until product is definitely shipped.
The escrow could also include json of the nostr event in question so that the lightning node can't be spammed by long-timeout-invoice creation requests that don't correspond to a real order.