ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-14 📝 Original message: Good morning list, In ...
📅 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
📝 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