Author: Conner Fromknecht 2019-06-14 06:34:07
Published on: 2019-06-14T06:34:07+00:00
The Lightning Dev mailing list is discussing the possibility of attaching a refund invoice to any LN payment so that the recipient can refund, fully, partially or eventually tip even a higher payment amount back to the sender. While there is no easy way to transmit extra application-level data on each payment, it may be possible to propose the addition of such data in a Lightning payment once TLV (a sort of key-value map) has been finalized. The sender's pubkey and some hop hints if the node is private could be embedded minimally once a spontaneous payments protocol is established. Variable-length onion packet should finalize soon for some definition of "soon". Leaking the sender's pubkey in every payment seems like a pretty big drawback, but the same info could probably be provided externally or out of band if the sender really does want to be refunded and offer better privacy for non-refunded payments. Possible use cases for refund invoice include promoting, refunds, safety deposits, and spontaneous payouts in games. However, hodl invoice can achieve the same goal to refund the customer, but limited as it's an "all or nothing refund" option, and the amount can't be more than the actual payment. Another alternative is "spontaneous LN invoice creation" with the server acting as a lookup proxy that handles the lightning creation on request. Requirements for refund invoice include generating an invoice and providing it encoded in the payment request as payload on the payer side, and being able to settle the actual payment and optionally support the feature after storing the refund invoice on the receiver's side. The sender's wallet must agree on a protocol for embedding the return invoice with the LN payment, which controls everything from a UX perspective.
Updated on: 2023-06-02T18:34:12.222134+00:00