Author: Corné Plooy 2018-03-19 12:06:03
Published on: 2018-03-19T12:06:03+00:00
The context discusses the possibility of enforcing a maximum payment amount that can be refunded to make it not a requirement, which still leaves the payment amount open to the payer but adds a constraint. The writer suggests that there is no use case for leaving out the amount in invoices and that any transaction where the payer decides the amount can be specified in the invoice request. The conversation then shifts to refunds, and the writer explores how they are used as solutions for when transactions get messy. They suggest that BOLT 12 transactions that allow refunds and other updates are similar to microtransaction channels, and they should contain a description field, a field that invalidates the previous state, a field that specifies how the state can be invalidated, and optionally a payment hash. The writer proposes that returning to null state by signing off that all obligations have been fulfilled may not be required on the BOLT12 protocol level and is better solved at a higher-level protocol. They also explore the format of the description field, suggesting that it should remain human-readable. The conversation then shifts to partial onions as a generic solution to capacity issues, and they explain that if capacity is the greatest concern as payee, a zero-hop partial onion can be supplied with minimum privacy but maximum ability of the payer to construct a route over channels with sufficient capacity. Finally, the context discusses the URL with an optional invoice ID that a payee can provide to a single payer to request payment for a specific transaction or hand over without invoice ID to be used and re-used by one or more payers. When asked how the payer derives the payment hash, the writer suggests that the payer must contact the payee again to get a fresh payment hash specifically for the payer.
Updated on: 2023-05-24T21:40:09.272229+00:00