Repository navigation
repro + fix: rgb forward checks - #42
Open
orbitalturtle wants to merge 4 commits into
Open
orbitalturtle wants to merge 4 commits into
orbitalturtle wants to merge 4 commits into
Conversation
orbitalturtle
force-pushed
the
fix/rgb-forward-check
branch
from
October 9, 2026 19:52
3cd71a2 to
5bd445e
Compare
orbitalturtle
force-pushed
the
fix/rgb-forward-check
branch
4 times, most recently
from
October 13, 2026 20:30
bb8e3bd to
f68028e
Compare
orbitalturtle
changed the title
Test-only hooks that let RLN integration tests simulate attacks which allow a sender to drain a router node's RGB channel balance. FORCE_FIRST_HOP_RGB_PAYMENT_ON_NODE puts an arbitrary RGB payment, or none, into the first hop's update_add_htlc while leaving the onion payloads untouched. FORCE_UPDATE_ADD_HTLC_RGB_CONTRACT_TO_PEER rewrites the contract of the RGB payment in the update_add_htlc sent to a peer. FORCE_SECOND_HOP_RGB_PAYMENT_ON_NODE sets the RGB payment the first hop is asked to forward, without changing what it receives.
Add RgbForwardNotCoveredByIncoming, reported as invalid_onion_payload, for a forwarding node whose onion asks for more RGB than the HTLC it received carries, and RgbAssetNotCarriedByChannel, reported as temporary_channel_failure, for a channel that isn't colored with the HTLC's asset. Co-Authored-By: Claude
For a forwarded HTLC the incoming RGB amount and contract travel in update_add_htlc while the outgoing ones sit in the sender-controlled onion payload, and nothing compared the two. A sender could ask a router node to forward more of one asset (or a different asset) than the router node received, effectively stealing the routing node's funds. Add check_forwarded_rgb in create_fwd_pending_htlc_info requiring both sides to either carry no RGB at all or carry the same contract with outgoing <= incoming.
Commitment coloring uses the channel's own asset, so an HTLC naming another contract was accepted and forwarded as if it carried that one. Reject mismatches on update_add_htlc and send_htlc. Co-Authored-By: Claude
orbitalturtle
force-pushed
the
fix/rgb-forward-check
branch
from
October 13, 2026 20:57
f68028e to
c3b2c2d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stops a sender from draining a router's RGB channel balance by making the router forward RGB it never received. The test hooks let RLN reproduce each attack (RGB-Tools/rgb-lightning-node#181).
Variants:
is_swap).Fixes:
out <= in, or there must be no RGB on either side. Swaps are exempt and rely on the node's intercept handler.update_add_htlcandsend_htlcreject a contract that doesn't match the channel's asset.invalid_onion_payload(forward check) ortemporary_channel_failure(send_htlc), instead of the final-node codefinal_incorrect_htlc_amount.🚨 CI depends on #41, so please merge that first.