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