Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-13 📝 Original message: ZmnSCPxj via ...

📅 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.