Published on: 2019-06-14T06:34:07+00:00
The Lightning Dev mailing list is currently discussing the possibility of adding a refund invoice to Lightning Network (LN) payments. The idea behind this proposal is to give recipients the option to fully or partially refund a payment, or even tip a higher amount back to the sender. Currently, there is no straightforward way to transmit extra application-level data with each payment, but it may become possible once the TLV (Type-Length-Value) specification is finalized.The proposed refund invoice would be attached to any LN payment, allowing the recipient to decide whether they want to refund or tip the sender. This feature could have various use cases, including promotions, refunds, safety deposits, and spontaneous payouts in games. However, the implementation of this idea depends on the finalization of the TLV specification. Additionally, the variable-length onion packet, which is essential for this functionality, is expected to be finalized soon.While attaching a refund invoice to each payment has its advantages, such as offering better privacy for non-refunded payments, there is a drawback in leaking the sender's pubkey in every transaction. However, this information could potentially be provided externally or out of band if the sender is concerned about privacy. It is important to note that an alternative called the "hodl invoice" exists, but it is limited to an "all or nothing" refund option and cannot exceed the original payment amount.To implement the refund invoice feature, several requirements need to be met. On the payer side, a protocol needs to be agreed upon to embed the return invoice with the LN payment, ensuring a smooth user experience. On the recipient's side, they would receive a normal LN invoice and store it for a later spontaneous refund, as the invoice amount is not predefined.In summary, the proposal to attach a refund invoice to LN payments aims to provide recipients with more flexibility in refunding or tipping the sender. While there are alternative options available, the proposed feature offers more versatility. However, the implementation is contingent on the finalization of the TLV specification and the variable-length onion packet. The proposal seeks further resources and hints for development and implementation.
Updated on: 2023-07-31T21:39:13.528817+00:00