There's a kinda-neat intersection between the "use TLV" proposal and the "multi-cell-onion" idea, so I want to make a concrete proposal (wording needs formalization):
Multi-cell structure: 1. `realm` (or `per_hop_type` if you prefer) meaning expanded. 2. Lower 4 bits is `num_extra_cells` to use (ie. total 1-17 cells). 3. Upper 4 bits reserved: if set, drop. 4. HMAC on end covers that many per-hops. 5. Padding is thus 12 bytes + 64 * `num_extra_cells`. Structure of padding changes: 1. We make the onion `padding` contain TLV, rename to `tlv`. 2. TLVs (as always!) are in lexicographical order (with shortest-wins on tiebreak). 3. TLVs follow unknown-odd-is-ok rule. 4. No 0-type; that terminates (backwards compat with 0-filled padding). New onion error value: 1. type: PERM|22 (`tlv_element_invalid`) 2. `2`:`offset` The writer MUST set `offset` to a byte offset within the `tlv` field of the tlv element it rejected. It SHOULD use the offset of the `type` byte of the TLV element if it didn't understand it, the offset the `len` byte of the TLV element if it was an incorrect length, or otherwise within the `value` if the value was somehow invalid. TLVs defined for initial onion: * type 2: `switch_chain` length: 32 value: chain_id of new chain. Used to switch chains during transit or at final hop. --- Use with multi-part payment ("base AMP"): * type 4: `total_payment` length: variable, <= 8 value: amount of total payment, in msat (big-endian of course). Writer must only use for final hop, and only if bolt11 flagged it as available (bolt11-multi_part_available). May use even if this payment meets the total_payment requirement. Reader MUST reject if not final hop, MAY reject if invoice was not `bolt11-multi_part_available`. Reader SHOULD wait until total parts meet or exceed `total_payment` (exceed may be due to fuzzing) [rest as per previous posts]. Thoughts? Rusty. PS. I prefer 'multi-part-payment' to 'base AMP' in the spec. It's more explicit, and leaves the namespace clear for more atomicy AMPs. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev