From rusty at rustcorp.com.au  Wed Nov 14 00:13:30 2018
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Wed, 14 Nov 2018 10:43:30 +1030
Subject: [Lightning-dev] Base AMP
In-Reply-To: <RIltvk7eDURKE0wl7VdQs7Y1Rx_DoccGaxe1q5NgwWouzqzbwkX2jXx3rVDSgtSL33ZF2VFmO_bntGSrHUOtFSl7ta3-PTDAHgHQeyeSVEw=@protonmail.com>
References: <RIltvk7eDURKE0wl7VdQs7Y1Rx_DoccGaxe1q5NgwWouzqzbwkX2jXx3rVDSgtSL33ZF2VFmO_bntGSrHUOtFSl7ta3-PTDAHgHQeyeSVEw=@protonmail.com>
Message-ID: <87k1lgh5xx.fsf@rustcorp.com.au>

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.