Good morning list, In case it was not noticed, I made a pull request for Base AMP: https://github.com/lightningnetwork/lightning-rfc/pull/511
This is primarily based on what Rusty suggested on-list, with sufficient MUST and SHOULD. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, November 14, 2018 9:59 AM, ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Rusty, > > Someone pointed out to me that `intended_payment_amount` is unnecessary. > On reflection, this is correct. > Both intermediate nodes and the payee node need not have > `intended_payment_amount`. > > Therefore.... > > > > 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. > > > > We can do something even simpler. > > If `amt_to_forward` plus the fees charged by this node is greater than the > actual incoming HTLC, this is an AMP attempt. > No additional flag needs to be added. > For final payment nodes, if the `amt_to_forward` is greater than the incoming > HTLC value, this is an AMP attempt. > > The previous node could try to probe this by offering a smaller amount than > it was instructed to give, but cannot differentiate between a stall because > the payee is waiting for an AMP, or a stall due to some other unrelated error. > > -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Of course, an explicit flag is more sensible as it is more explicit. > > For myself, I would rather a new `per_hop_type`, but whether to use a > separate `per_hop_type` vs a byte in padding is largely a bikeshed issue and > either is fine with me. > A concern is that nothing in our current spec requires that `padding` be all > 0, such that reinterpreting byte 0 to be flags could cause interoperability > problems. > So perhaps a new `per_hop_type` which has a 2-byte `flags` (for more future > expansion) and a `padding` of 10 bytes which MUST be explicitly specced as > "MUST be all 0". > > An explicit flags field would also allow delivery of higher-layer application > data in each payment, for whatever purpose a higher-layer application may > want. E.g. bit 1 could mean "the next hop 65 bytes is actually a 32-byte > application ID and a 33-byte payload; this flag is valid only if this is the > last hop." > Another bit can also be used to provide spontaneous payment, so e.g. bit 2 > could mean "this hop is the final hop (even if HMAC is nonzero); the HMAC of > this hop is really the preimage to claim this payment." > > Regards, > ZmnSCPxj > > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
