Author: Jorge Timón 2019-11-14 02:43:03
Published on: 2019-11-14T02:43:03+00:00
The context discusses the guidelines for replacing offers in a payment protocol. It specifies that if the signature of an offer does not sign the replacement with the same key as the original, the replacement must fail. Additionally, it should only fetch once and avoid double-redirects. If the description or amount of an offer significantly changes, the user should be re-asked. The discussion also raises concerns about SLIP-0173 becoming used in practice as IDs since they rely on a centralized manual registry vulnerable to name squatting. However, software can configure them locally. To avoid reusing hrp for different chains within the same software, creators can add a chain_id field to the offer. There is no way for people to potentially add their custom fields which could result in people abusing the description field by adding JSON, protobuf, or even XML in them. The author suggests including a bolt11 field in invoice requests for their use case. The request contains an invoice that Bob is supposed to pay after Alice pays it to him. In this case, the invoice in the request may be for a different chain, and during the "action," Bob would need to try to pay that invoice using another node connected to the lightning network of that other chain. The author assumes that Bob (the offer creator) will be able to use plugins to do extra or custom validations on the invoice requests. Moreover, Alice could use plugins too to better handle custom errors from particular types of bobs.
Updated on: 2023-06-02T21:28:54.280089+00:00