rich1.0ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://yabu.me📅 Original date posted:2018-11-14 📝 Original message: 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 at 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 at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev