Good morning Paberlance, You may be interested in the current work with "TLV" that is on-going at the spec level now.
This will allow a sort of key-value map to be sent on every payment. It would be possible, *once TLV has been finalized*, to propose the addition of such data in a Lightning payment. As of now, there is no easy way to transmit extra application-level data on each payment. The dependencies, as I understand them, are: refund invoice on payment -> application-specific data TLV -> TLV spec -> variable-length onion packet Variable-length onion packet should finalize "soon" for some definition of "soon", if my understanding is correct. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, June 14, 2019 1:53 PM, Paberlance via Lightning-dev <lightning-dev@lists.linuxfoundation.org> wrote: > Hello Lightning Devs, > > i was wondering about the following idea: What if you attach a refund invoice > to any LN payment. With this the recipient then has the possibility to > refund, fully, partially or eventually tipping even a higher payment amount > back to the sender. > > From the user side, the userwallet pays just as normal Lightning Invoice, but > attached along with the payment of 0 sat invoice back to the seller. From a > UX perspective, this all happens is controlled by the wallet, which must > agree on a protocol for embedding the return invoice with the LN payment. > > On the recipee side, a normal LN invoice is recieved and optionally store > that invoice to be able to perform a spontaneous refund later in time if he > wants.As the invoice amount is not predefined, the seller is free to refund > any payment, just bounded to the invoice timeout. Probably the payer will be > motivated to issue invoices with a high expiry time-out. > > Possible Usecases: > > *Promotions, like: Every 100x Purchaser wins a prize, gets the order for free. > > *Refunds: I order something, cancel the transaction, seller refunds the > transaction partially, charging a service fee that he does not return. > > *Safety deposits: You rent a car, the company keeps the payment as safety > deposit, that gets reverted as soon as the car is returned. > > *Spontanous payouts in games > > Alternatives: > > *Hodl invoice, can achieve the same goal to refund the customer, but limited > as it's an "all or nothing refund" option. Amount can't be more than the > actual payment. > https://github.com/lightningnetwork/lnd/pull/2022 > > *"Spontaneous LN invoice creation " with server that acts as a lookup proxy > that handles the lightning creation on request. Inspiration: @georgevaccaro > > Requirements: > > Payer has to generate a invoice and provide it encoded in the payment request > as payload. > Reciver: must be able to settle the actual payment. And optionaly he may > support the feature After storing the refund invoice, he then has the ability > to decice if or how he will use it to refunde the client in the future. > > Does this exist yet? What people can help me with this idea? > > Any ressources or hints to digg deeper, built on top of that idea? > > Paberlance _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
