Subhra Mazumdar [ARCHIVE] on Nostr: 📅 Original date posted:2020-03-24 📝 Original message: Hi ZmnSCPxj, Thank you ...
📅 Original date posted:2020-03-24
📝 Original message:
Hi ZmnSCPxj,
Thank you for the explanation. So I went through BOLT 04
specification and quoting a few error possibilities:
An *intermediate hop* MUST NOT, but the *final node*:
- if the payment_secret doesn't match the expected value for that
payment_hash, or the payment_secret is required and is not present:
- MUST fail the HTLC.
- MUST return an incorrect_or_unknown_payment_details error.
- if the payment hash is unknown:
- MUST fail the HTLC.
- MUST return an incorrect_or_unknown_payment_details error.
So it is the final node which is expected to fail the htlc in these 2
cases. But then what if final node denies revealing the secret? Say in the
scenario A->B->C->D, D doesn't reveal the secret. So in such a case, what
is C supposed to do? Shall it resort to condition no. 1( secret doesn't
match), generate an error message and unlock funds of A->B and B->C as soon
as possible?
On Tue, Mar 24, 2020 at 4:57 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Subhra,
>
> > Another question related to the paper https://arxiv.org/abs/2003.00003.
> Over here, it is stated in page 13, "Surge of unresolved HTLCs while
> probing: Recalling steps 5-7 in Figure 4, each probe sets up a chain of
> irredeemable HTLCs (since a matching preimage would have to be
> brute-forced). Eventually, running multiple probes over the same channels
> will escrow its funds in these HTLCs, effectively DOSing the probe route
> and forcing the nodes to wait until the HTLCs time out before being able to
> forward other payments. This is an issue we encountered over and over
> during 4.2 and 4.3, often giving us one shot at probing before having to
> wait multiple hours for the HTLCs to expire. This is also why we chose the
> channels leading up to our final target to have a much higher balance, so
> that we would have enough.." So there was no matching preimage with
> receiver as per Fig 4. So that means in the route say A->B->C->D, if D
> doesn't have a matching preimage and suppose C->D uses lock time of 144
> blocks, B->C 288 blocks and A->B uses a locktime of 432 blocks, so won't be
> the case funds in A->B and B->C still remains locked for the mentioned
> locktime?
>
> It is helpful to remember that inside a channel, every contract has an
> implicit branch "if both of us in this channel agree, we can spend this
> contract funds any way we want".
>
> This is because every contract is dependent on a transaction spending from
> a 2-of-2, and both parties can always sign a new 2-of-2 transaction without
> that contract --- it is just that both have to agree to do this.
>
> In case of a reported failure, the receiving node in the channel basically
> says "just between the two of us, I will not be able to claim this HTLC
> using the hashlock branch anyway because <BOLT 4 failure code reason>, so
> this will inevitably be claimable to you in the timelock anyway, so we
> might as well just agree to re-assign the HTLC funds back to you right now".
>
> The sending node is then willing to sign off on this
> outside-of-the-contract agreement, since it lets it get the funds back
> before the timelock expires, and to reuse those funds otherwise.
>
> Thus, even if D griefs up to 143 blocks it wants, at the 144th block C can
> report immediately back to B and then A with the above failure mechanism.
>
> B and C are incentivized to do this quickly since it would allow the funds
> to be reused again in a different, probably-will-not-be-griefed near-future
> payment, which might earn them fees in the future.
>
> Thus if B and C are not controlled by the A+D conglomerate then they have
> no incentive to extend the griefing attack further.
>
> Of course, if either B or C is offline at the time, then the new state
> where the HTLC is removed out-of-contract is not possible to sign with both
> parties.
>
> > I know this is not the definition of griefing attack but then can this
> possibly mimic the situation where receiver denies having the correct
> preimage?
>
> No, since B and C are incentivized to report this immediately in order to
> free up the funds in order for them to forward "soon".
>
> Regards,
> ZmnSCPxj
>
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200324/35fd7ef7/attachment.html>;
📝 Original message:
Hi ZmnSCPxj,
Thank you for the explanation. So I went through BOLT 04
specification and quoting a few error possibilities:
An *intermediate hop* MUST NOT, but the *final node*:
- if the payment_secret doesn't match the expected value for that
payment_hash, or the payment_secret is required and is not present:
- MUST fail the HTLC.
- MUST return an incorrect_or_unknown_payment_details error.
- if the payment hash is unknown:
- MUST fail the HTLC.
- MUST return an incorrect_or_unknown_payment_details error.
So it is the final node which is expected to fail the htlc in these 2
cases. But then what if final node denies revealing the secret? Say in the
scenario A->B->C->D, D doesn't reveal the secret. So in such a case, what
is C supposed to do? Shall it resort to condition no. 1( secret doesn't
match), generate an error message and unlock funds of A->B and B->C as soon
as possible?
On Tue, Mar 24, 2020 at 4:57 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Subhra,
>
> > Another question related to the paper https://arxiv.org/abs/2003.00003.
> Over here, it is stated in page 13, "Surge of unresolved HTLCs while
> probing: Recalling steps 5-7 in Figure 4, each probe sets up a chain of
> irredeemable HTLCs (since a matching preimage would have to be
> brute-forced). Eventually, running multiple probes over the same channels
> will escrow its funds in these HTLCs, effectively DOSing the probe route
> and forcing the nodes to wait until the HTLCs time out before being able to
> forward other payments. This is an issue we encountered over and over
> during 4.2 and 4.3, often giving us one shot at probing before having to
> wait multiple hours for the HTLCs to expire. This is also why we chose the
> channels leading up to our final target to have a much higher balance, so
> that we would have enough.." So there was no matching preimage with
> receiver as per Fig 4. So that means in the route say A->B->C->D, if D
> doesn't have a matching preimage and suppose C->D uses lock time of 144
> blocks, B->C 288 blocks and A->B uses a locktime of 432 blocks, so won't be
> the case funds in A->B and B->C still remains locked for the mentioned
> locktime?
>
> It is helpful to remember that inside a channel, every contract has an
> implicit branch "if both of us in this channel agree, we can spend this
> contract funds any way we want".
>
> This is because every contract is dependent on a transaction spending from
> a 2-of-2, and both parties can always sign a new 2-of-2 transaction without
> that contract --- it is just that both have to agree to do this.
>
> In case of a reported failure, the receiving node in the channel basically
> says "just between the two of us, I will not be able to claim this HTLC
> using the hashlock branch anyway because <BOLT 4 failure code reason>, so
> this will inevitably be claimable to you in the timelock anyway, so we
> might as well just agree to re-assign the HTLC funds back to you right now".
>
> The sending node is then willing to sign off on this
> outside-of-the-contract agreement, since it lets it get the funds back
> before the timelock expires, and to reuse those funds otherwise.
>
> Thus, even if D griefs up to 143 blocks it wants, at the 144th block C can
> report immediately back to B and then A with the above failure mechanism.
>
> B and C are incentivized to do this quickly since it would allow the funds
> to be reused again in a different, probably-will-not-be-griefed near-future
> payment, which might earn them fees in the future.
>
> Thus if B and C are not controlled by the A+D conglomerate then they have
> no incentive to extend the griefing attack further.
>
> Of course, if either B or C is offline at the time, then the new state
> where the HTLC is removed out-of-contract is not possible to sign with both
> parties.
>
> > I know this is not the definition of griefing attack but then can this
> possibly mimic the situation where receiver denies having the correct
> preimage?
>
> No, since B and C are incentivized to report this immediately in order to
> free up the funds in order for them to forward "soon".
>
> Regards,
> ZmnSCPxj
>
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200324/35fd7ef7/attachment.html>;