Author: Rusty Russell 2019-11-08 03:09:15
Published on: 2019-11-08T03:09:15+00:00
In a discussion on Github about an Offer Protocol for Lightning Payments, Rusty suggested using Universal Business Language (UBL) to define "business" fields like `address1` and `currency`. However, Yaacov responded that it was not necessary to define these fields as they already exist in software like crm, erp, etc. and are well defined by standard body. Instead, Yaacov suggested having a generic field containing well-defined structured and standardized data, mentioning EDIFACT and UBL. Rusty then explained his attraction towards UBL as a fan of standards but also the need for simplicity. He proposed having an explicit mapping between invoices/offers and UBL, so that we can distinguish which fields should have their own existence in the invoice/offer and what should be in a general UBL field.Rusty had posted a draft "BOLT 12" protocol that supports two simple flows: requesting an invoice over the lightning network after receiving an offer (`lno...`) or sending an invoice request (`lni...`). The human-readable part of a Lightning offer is `lno`, consisting of three parts: 0 or more TLV encoded fields, a 32-byte nodeid, and a 64-byte signature of SHA256(hrp-as-utf8 | tlv | nodeid). The TLV fields define how to get the invoice and what it's for, including recurring payments and base currency. Additionally, there is a bitfield known as `additional_data`, indicating what information the invoice requester should (odd) or must (even) supply. Rusty explains that there are definite handwavings in his proposition and further thought will be required.The Lightning Network protocol has a number of requirements for both senders and receivers of payments. Recurring payments are supported, with a range of different options available such as payments due on a specific date, at a specific time, or with a specific number of payments specified. The `additional_data` field is used to specify various details related to the payment, such as delivery information and voucher codes. The `expiry` field can be used to indicate when an offer is no longer valid. In order to request an actual invoice using the `invoice_req` message, the node must have an offer and include certain information in the request including the `offer_identifier`, `key`, and `recurrence` number if it is part of a recurring series. There are many requirements that both senders and receivers of payments must follow, including the use of ISO 3166 alpha-2 codes for `delivery_country`, setting the `offer_identifier` to match the offer, and checking the `delivery_` fields, `recurrence`, and `amount`. A detailed list of these requirements is provided in the context.When sending an `invoice_or_error_tlv`, the sender must copy the `tag` from the sender, omit any fields they do not use, and place the number of omitted fields in the `omitted_fields` field. If they include an `invoice`, they must not include a `message` or `replacement`, and must merkle the fields that were used and place that in the `s` field of the invoice. If they include a `replacement`, they may include a `message`. Otherwise, they must include a `message` describing the error. The receiver must check that the `tag` matches the request, and if there is a `replacement`, they must fail if the `signature` does not sign the `offer` with the same key as the original. They are also required to check that no vital fields are in `omitted` and that the description and amount of the invoice have not significantly changed. Finally, within the invoice, they must ensure that `s` matches the merkle of fields minus `omitted`, check that no vital fields are in `omitted`, and validate the signature.The Lightning invrequest is a form of invoice used to request payment for a transaction. The invrequest consists of the human-readable part `lni`, followed by three parts: 0 or more TLV-encoded fields, a 32-byte nodeid, and a 64-byte signature of SHA256(hrp-as-utf8 | tlv | nodeid). The optional `amount` field describes the amount an invoice will be accepted for. Upon parsing and accepting an invreq, the node sends an invoice_or_error_tlv within an onion, and the reply is empty. The fields `paths`, `description`, and `expiry` fields are the same as those for offers.To ensure secure communication, the invrequest uses the SHA256 hash function to combine adjacent leaves using SHA256(leaf1 | leaf2) until none remain.
Updated on: 2023-06-02T21:31:41.390908+00:00