Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BOLT 4: Merge final_expiry_too_soon into incorrect_or_unknown_payment #608

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@joostjager
Copy link

commented May 13, 2019

In commit 914ebab the incorrect_payment_amount error was merged into incorrect_or_unknown_payment_details to prevent a probing attack that allowed intermediate nodes to learn the final destination of a payment.

A similar attack is possible using the htlc expiry value. By trying payments with the correct amount but low expiry values to candidate destinations, an incorrect_or_unknown_payment_details error can be
elicited. This would signal that the probe payment was sent to the final destination.

For the intermediate node to determine the correct amount, an estimate must be calculated. A logical choice would be the outgoing amount of the intermediate node plus some allowance for routing fees that would otherwise be paid to subsequent nodes along the path.

Picking a low enough - but not too low - expiry value is more tricky. A reasonable guess could be made using external knowledge of the final destination's implementation defaults or the type of invoice that
is paid to. Especially in the case of an hodl invoice that typically has a large expiry delta, it is easier to make a correct guess.

This form of attack is arguably harder to realize than the amount probe that was previously possible. The attacker may accidentally pay the invoice if the expiry value guess satisfies the invoice final cltv requirement. In that case, the attacker still has the incoming htlc to pull which limits the loss.

BOLT 4: Merge final_expiry_too_soon into incorrect_or_unknown_payment…
…_details

In commit 914ebab the
incorrect_payment_amount error was merged into
incorrect_or_unknown_payment_details to prevent a probing attack
that allowed intermediate nodes to learn the final destination of
a payment.

A similar attack is possible using the htlc expiry value. By trying
payments with the correct amount but low expiry values to candidate
destinations, an incorrect_or_unknown_payment_details error can be
elicited. This would signal that the probe payment was sent to the
final destination.

For the intermediate node to determine the correct amount, an estimate
must be calculated. A logical choice would be the outgoing amount of the
intermediate node plus some allowance for routing fees that would
otherwise be paid to subsequent nodes along the path.

Picking a low enough - but not too low - expiry value is more tricky.
A reasonable guess could be made using external knowledge of the
final destination's implementation defaults or the type of invoice that
is paid to. Especially in the case of an hodl invoice that typically has
a large expiry delta, it is easier to make a correct guess.

This form of attack is arguably harder to realize than the amount probe
that was previously possible. The attacker may accidentally
pay the invoice if the expiry value guess satisfies the invoice
final cltv requirement. In that case, the attacker still has the
incoming htlc to pull which limits the loss.

@joostjager joostjager changed the title BOLT 4: Merge final_expiry_too_soon into incorrect_or_unknown_payment… BOLT 4: Merge final_expiry_too_soon into incorrect_or_unknown_payment May 13, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.