Skip to content

BOLT 4: further restrictions on overpayment #1337

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.

Sign up for GitHub

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

Open
rustyrussell wants to merge 2 commits into
base: master
Choose a base branch
from
Open

BOLT 4: further restrictions on overpayment #1337

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c5d89d7
BOLT 4: don't allow gratuitous overpayment.
rustyrussell May 27, 2026
ed5b1c1
BOLT 4: don't allow double payment, allow "reasonable excess fees".
rustyrussell May 27, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 10 additions & 2 deletions 04-onion-routing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -395,7 +395,8 @@ The final node:
all HTLCs in the set.
- if the total `amt_to_forward` of this HTLC set is equal to or greater
than `total_msat`:
- SHOULD fulfill all HTLCs in the HTLC set
- SHOULD fulfill the minimal subset of those HTLCs in the HTLC set which are required for payment
- SHOULD reject other "unnecessary" HTLCs in the HTLC set.
- otherwise, if the total `amt_to_forward` of this HTLC set is less than
`total_msat`:
- MUST NOT fulfill any HTLCs in the HTLC set
Expand Down Expand Up @@ -436,6 +437,13 @@ otherwise meets the amount criterion (eg. some other failure, or
invoice timeout), however if it were to fulfill only some of them,
intermediary nodes could simply claim the remaining ones.

There are cases where the sender attempts payments for the same invoice from multiple wallets
(usually because one part of the first payment is stuck). For example, a wallet could send
50% of the payment in one part which arrives at the destination, and another 50% which does
not. The sender tries another wallet, which pays 100% of the payment. In this case, the 50%
HTLC should be rejected, as the 100% is sufficient. This can be determined by ordering the
HTLCs in the set in descending amount order, and iterating until the amount requirement is fulfilled.

## Route Blinding

1. subtype: `blinded_path`
Expand Down Expand Up @@ -1518,7 +1526,7 @@ An _intermediate hop_ MUST NOT, but the _final node_:
- if the payment hash is unknown:
- MUST fail the HTLC.
- MUST return an `incorrect_or_unknown_payment_details` error.
- if the amount paid is more than twice the amount expected:
- if the amount paid exceeds the expected about by more than 5000msat or 1% (whatever is greater):
- SHOULD fail the HTLC.
- SHOULD return an `incorrect_or_unknown_payment_details` error.
- Note: this allows the origin node to reduce information leakage by
Expand Down