Published on: 2019-11-14T09:32:47+00:00
In a recent conversation on the Lightning network mailing list, Yaacov Akiba Slama proposed integrating Universal Business Language (UBL) into the Lightning Network (LN). Rusty Russell, developer for Blockstream, responded that UBL could already be used with LN simply by setting the `d` field to "UBL:". However, Slama highlighted that an additional BOLT could be created to reference UBL as a way to exchange business information.Slama described a workflow where UBL documents would be cryptographically tied to the LN payments, but would not alter the property of UBL of not being machine handlable. He also suggested simplified workflows using UBL, such as recurring payments and payment acknowledgments between payers and payees. Russell noted that these workflows did not provide a "static invoice" flow or a donation flow, nor did they support HTTP(s) requests over LN. However, he agreed that once LN supports messaging, such flows would become possible.The conversation ended with links to two messaging proposals for LN.Another aspect of the discussion focused on replacing offers in a payment protocol. The guidelines stated that if the signature of an offer does not sign the replacement with the same key as the original, the replacement must fail. Additionally, the description or amount of an offer should only change significantly if the user is re-asked. Concerns were raised 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, and creators can add a chain_id field to the offer to avoid reusing hrp for different chains within the same software.The author of the thread also proposed including a bolt11 field in invoice requests for their use case. This request contains an invoice that Bob is supposed to pay after Alice pays it to him. 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.Yaacov Akiba Slama suggests that integration between different protocols is possible without affecting their individual semantics. He proposes defining interaction points to achieve this. He gives an example of how the seller can add a prepayment invoice to an LN invoice and tie UBL documents to the LN payment cryptographically. This way, the UBL's machine handlability remains unaltered while tying it to the workflow.Rusty Russell, a developer in the Lightning Network (LN), has expressed his opinion on integrating LN with Universal Business Language (UBL). He compared UBL treating LN as a dumb payment layer to faxing email and not something he would promote. However, he acknowledged that we can integrate between them without intermixing the semantics of the protocols, but only defining the interaction points between them. For instance, the seller can use H(Quotation (UBL)||Order(UBL)||Prepayment Invoice(UBL)) in the LN invoice and use H(Receipt(UBL)) as preimage to tie the workflow. Despite the property of UBL being non-machine handlable, the cryptographic properties of LN are still used to tie the workflow. Russell noted that the full UBL specification is machine-parsable but not designed to be machine-handlable. However, for the simpler case of an offer->purchase flow, we can define a subset of UBL for which this can be done and a further-limited subset, which must be examined by the user. In addition, the atomic nature of LN needs to be baked into the protocol. We need to define UBL extensions for the LN fields to tie them all together (e.g. payment_hash, node_id) and define a transport mechanism for these over the Lightning Network. Russell believes that this is quite possible, but it will take time and a significant amount of work. Thus, he needs to be sure that others feel the same way before embarking on this project.The writer proposes a workflow for the use of UBL treating Lightning as a payment layer. However, this could lead to issues with interpreting general contract terms and would require the definition of UBL extensions for LN fields and a transport mechanism over the Lightning Network. The full UBL specification is machine parsable but not designed to be machine handlable. Rusty suggests defining a subset of UBL for simple cases like an offer-purchase flow. It's also worth noting that none of the UBL examples provided fits into the 1023 byte limit of the existing invoice format. The writer suggests defining an explicit mapping between invoices/offers and UBL and indicates the need to go through the UBL spec and indicate exactly what fields are permitted and required. This will require intimate knowledge of the UBL spec.Rusty Russell is discussing the technical aspects of implementing an invoice and payment system for Lightning Network (LN).
Updated on: 2023-07-31T22:20:37.866190+00:00