Published on: 2018-11-29T09:49:04+00:00
The conversation begins with a discussion about a proposed `application_data` type 6 for spontaneous payments. The writer suggests that including this in invoices could create confusion and lead to undesirable actions. Instead, they propose using this type for games of chance, where users can input a random number. The goal is to combine multi-use offers with spontaneous payments. It is mentioned that spontaneous payments would be beneficial when dealing with trust-demanding third parties like Bitcoin banks that hold Bitcoin on behalf of their customers. The suggestion is that the bank would provide a multi-use offer containing the application data, which the customer would use by making a spontaneous payment.Next, the conversation shifts to describing a proposed spontaneous payment type 8. This type would sacrifice proof-of-payment, and the reader would claim the HTLC (Hashed Time-Lock Contract) using the given preimage. The writer agrees that readers should reject spontaneous payments and questions whether it should be advertised on global features.In terms of the Lightning Network specification, a proposal by Rusty Russell suggests implementing a multi-cell structure for onion routing using TLV (Type-Length-Value). The structure includes a realm or per-hop type, expanding on the current four bits for 'per_hop_type' to allocate 1-16 cells. The upper four bits are reserved to drop invalid messages. Additionally, a HMAC is applied to cover the number of per-hops, and padding is expanded to 12 bytes plus 65 bytes per extra cell. The padding will contain TLVs in lexicographical order, with the shortest winning on tiebreaks. The proposal also extends the use of multi-part payments, allowing payments to be split into smaller amounts and sent as separate payments. Type 4 introduces a variable-length 'total_payment' field that specifies the total payment amount in milli-satoshis. This field should only be used for the final hop if flagged as available, and the reader should reject it if it is not the final hop. Rusty also suggests using the existence of this field to signal the use of base AMP (Atomic Multipath Payment) instead of a separate flags byte. From a nomenclature standpoint, Rusty recommends using "multi-part-payment" over "base AMP" to avoid limiting future developments.ZmnSCPxj proposes a concrete proposal for the intersection between the "use TLV" and "multi-cell-onion" ideas. The proposed multi-cell structure includes an expanded realm or per-hop type, where the lower 4 bits indicate the number of extra cells to use (1-17 cells). The upper 4 bits are reserved, and if set, messages should be dropped. HMAC covers the specified number of per-hops, and padding is adjusted to 12 bytes plus 64 times the number of extra cells. The structure of padding changes, with onion padding renamed to 'tlv' and containing TLVs in lexicographical order, following the shortest-wins on tiebreak rule. Backwards compatibility is terminated by eliminating the 0-type. A new onion error value, type PERM|22 (`tlv_element_invalid`), is introduced along with an offset within the tlv field. The initial onion TLVs include type 2: `switch_chain` with a length of 32 and a value representing the chain_id of the new chain used for switching chains during transit or at the final hop. Type 4: `total_payment` is used for specifying the total payment amount in milli-satoshis. This TLV should only be used for the final hop and if bolt11 flags it as available (bolt11-multi_part_available). ZmnSCPxj suggests using the existence of this TLV to signal the use of base AMP instead of a separate flags byte. Additionally, two new payment types are proposed: type 6: `application_data` and type 8: `spontaneous_payment`. Type 6 is used exclusively for the final hop if it is compatible with a specific application. Type 8 is also used only for the final hop, sacrificing proof-of-payment. ZmnSCPxj prefers using 'multi-part-payment' instead of 'base AMP' in the specification to provide clarity and leave room for more atomic AMPs. However, they acknowledge that "base" AMP is atomic enough to warrant the full name of "atomic multipath payment".To handle the proposed multi-cell structure, the writer suggests a new structure that expands on the "use TLV" and "multi-cell-onion" ideas. The structure includes an expanded realm or per-hop type, where the lower 4 bits indicate the number of extra cells to use. The upper 4 bits are reserved for dropping messages. HMAC is used to cover the specified number of per-hops, and padding contains TLVs. The TLVs follow the unknown-odd-is-ok rule and are arranged in lexicographical order. The proposal eliminates the 0-type to terminate backwards compatibility.
Updated on: 2023-07-31T20:59:37.204782+00:00