rich1.0Rusty Russell [ARCHIVE] (npub1zw…hkhpx)https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://yabu.me📅 Original date posted:2018-11-13 📝 Original message: ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes: > Good morning list, > > I propose the below to support Base AMP. I think the complexity outweighs the benefits for the moment. The sender would have to make the onions identical past the merge point (so any one of them could be used), the merge point has to now create a many:1 map for HTLC redemption. For the moment, I think we should stick with: BOLT #4: 1. type: `per_hop` 2. data: * [`8`:`short_channel_id`] * [`8`:`amt_to_forward`] * [`4`:`outgoing_cltv_value`] - * [`12`:`padding`] + * [`1`:`flags`] + * [`11`:`padding`] And define bit 0 of `flags` as `incomplete_payment`. For the moment, it is only allowed for final nodes, and only if they put it in their BOLT11 field. BOLT #11: * `9` (5): `data_length` variable. Features supported for receiving this payment. Currently only `wait_on_incomplete` (bit 1) is defined. ... -A writer SHOULD use the minimum `data_length` possible for `x` and `c` fields. +A writer SHOULD use the minimum `data_length` possible for `x`, `c` and `9` fields, omitting the field entirely if possible. ... A payer MUST ignore unknown odd bits are set in the `9` field, and NOT try to make a payment if unknown even bits are set in the `9` field. Cheers, Rusty.