SomberNight [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-13 📝 Original message: Hi Ben, This is handled ...
📅 Original date posted:2022-12-13
📝 Original message:
Hi Ben,
This is handled earlier than update_fail_htlc: when the recipient sees the update_add_htlc, some sanity checks will fail and it won't commit it to the commitment tx.
See here:
https://github.com/lightning/bolts/blame/a0bbe47b0278b4f152dbaa4f5fab2562413a217c/02-peer-protocol.md#L1036
> 1. type: 128 (`update_add_htlc`)
> [...]
> A receiving node:
> [...]
> - receiving an `amount_msat` that the sending node cannot afford at the current `feerate_per_kw` (while maintaining its channel reserve and any `to_local_anchor` and `to_remote_anchor` costs):
> - SHOULD send a `warning` and close the connection, or send an
`error` and fail the channel.
If the recipient decides to simply close the transport connection, the update_add_htlc message is forgotten (due to the rules of how channel_reestablish works), and the channel is back to a usable state.
ghost43
------- Original Message -------
On Tuesday, December 13th, 2022 at 2:51 PM, Benjamin Weintraub via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
> Hi list,
>
>
>
> I have a question about how update_fail_htlcs are handled. Consider this scenario: a node, potentially adversarial, forwards an HTLC along a channel that does not have the funds to support a payment of that size. How does the recipient of the HTLC respond?
>
>
>
> I see this line in BOLT #2:
>
> “until the corresponding HTLC is irrevocably committed in both sides' commitment transactions: MUST NOT send an `update_fulfill_htlc`, `update_fail_htlc`, or `update_fail_malformed_htlc`"
>
>
>
> But this seems confusing to me in the context of the scenario I suggested. Is it saying that even though the channel cannot support the payment, the nodes still need to commit to it?
>
>
>
> I assume that this interpretation is not correct, but then when is it okay for a node to send an update_fail_htlc? Immediately upon receiving an invalid transaction?
>
>
>
> Any insight you could provide would be great.
>
>
>
> Thanks in advance,
>
> Ben
📝 Original message:
Hi Ben,
This is handled earlier than update_fail_htlc: when the recipient sees the update_add_htlc, some sanity checks will fail and it won't commit it to the commitment tx.
See here:
https://github.com/lightning/bolts/blame/a0bbe47b0278b4f152dbaa4f5fab2562413a217c/02-peer-protocol.md#L1036
> 1. type: 128 (`update_add_htlc`)
> [...]
> A receiving node:
> [...]
> - receiving an `amount_msat` that the sending node cannot afford at the current `feerate_per_kw` (while maintaining its channel reserve and any `to_local_anchor` and `to_remote_anchor` costs):
> - SHOULD send a `warning` and close the connection, or send an
`error` and fail the channel.
If the recipient decides to simply close the transport connection, the update_add_htlc message is forgotten (due to the rules of how channel_reestablish works), and the channel is back to a usable state.
ghost43
------- Original Message -------
On Tuesday, December 13th, 2022 at 2:51 PM, Benjamin Weintraub via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
> Hi list,
>
>
>
> I have a question about how update_fail_htlcs are handled. Consider this scenario: a node, potentially adversarial, forwards an HTLC along a channel that does not have the funds to support a payment of that size. How does the recipient of the HTLC respond?
>
>
>
> I see this line in BOLT #2:
>
> “until the corresponding HTLC is irrevocably committed in both sides' commitment transactions: MUST NOT send an `update_fulfill_htlc`, `update_fail_htlc`, or `update_fail_malformed_htlc`"
>
>
>
> But this seems confusing to me in the context of the scenario I suggested. Is it saying that even though the channel cannot support the payment, the nodes still need to commit to it?
>
>
>
> I assume that this interpretation is not correct, but then when is it okay for a node to send an update_fail_htlc? Immediately upon receiving an invalid transaction?
>
>
>
> Any insight you could provide would be great.
>
>
>
> Thanks in advance,
>
> Ben