contractcourt: fix HTLC success resolver phantom-input bug (#10840)

[yyforyongyu]

Fixes #10840.

This fixes the HTLC success resolver path that could treat any spend of the original HTLC output as our own second-level HTLC success transaction. If a remote timeout spend is observed instead, the resolver now validates the spender output against the stored sweep descriptor and fails the final HTLC outcome instead of handing a phantom output to the sweeper.

The incoming contest resolver also avoids launching the success resolver after CLTV expiry and passes the current height into the immediate invoice-registry lookup.

Companion sweeper blast-radius fix: #10842.

Testing:

• GOWORK=off go test ./contractcourt
• git diff --check master..HEAD
• make fmt in a clean temporary worktree
• make lint in a clean temporary worktree
• GOWORK=off go test ./contractcourt -run '^$' at each commit

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a bug in the HTLC success resolver where foreign spends of commitment HTLC outputs were incorrectly treated as valid success transactions. By implementing stricter validation of the spending transaction's output and ensuring that expired HTLCs do not trigger the success resolution path, the changes improve the robustness of the contract resolution process and prevent unnecessary sweeper activity.

Highlights

• HTLC Success Resolver Validation: Added validation to the HTLC success resolver to ensure that the spending transaction of an HTLC output matches the expected second-level success output, preventing phantom inputs from being passed to the sweeper.
• Expiry Handling: Updated the incoming contest resolver to skip launching the success path for HTLCs that have already reached their CLTV expiry.
• Test Coverage: Introduced new unit tests to verify that the resolver correctly rejects foreign spends and handles expired HTLCs appropriately.

New Features

🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

🔴 PR Severity: CRITICAL

Automated classification | 3 files | 139 lines changed

🔴 Critical (2 files)

• contractcourt/htlc_incoming_contest_resolver.go - on-chain HTLC incoming contest resolution logic
• contractcourt/htlc_success_resolver.go - on-chain HTLC success resolver logic

🟢 Low (1 file)

• docs/release-notes/release-notes-0.22.0.md - release notes documentation

Analysis

This PR modifies two files in the contractcourt package — htlc_incoming_contest_resolver.go and htlc_success_resolver.go — which implement on-chain dispute resolution for HTLCs. These resolvers manage critical state machine transitions for fund recovery during channel force-closes, making them among the highest-risk code paths in the daemon. Changes here require expert review to ensure correct handling of on-chain settlement and to avoid any potential loss of funds.

Severity bump check: 3 non-test/non-generated files (threshold: >20), 139 lines changed (threshold: >500), single distinct critical package — no bump triggered.

Three test/mock files (*_test.go, mock_*.go) were excluded from file and line counts per classification rules.

---

_{To override, add a severity-override-{critical,high,medium,low} label.}
<!-- pr-severity-bot -->

[gemini-code-assist]

Code Review

This pull request addresses an issue where an incoming HTLC resolver could incorrectly treat a foreign spend of a commitment HTLC output as its own success transaction. It introduces validation of the spending transaction's expected output before sweeping, and checkpoints the resolver as failed (timeout) if a foreign spend is detected. Additionally, the resolver now avoids launching the success path for incoming HTLCs that are already expired by checking the best block height at launch. Comprehensive unit tests have been added to verify these behaviors. No review comments were provided, so there is no additional feedback.

[yyforyongyu]

LGTM 🎯 (claude-opus-4-8[1m])

[yyforyongyu]

LGTM 🚀 (claude-opus-4-8[1m])

[yyforyongyu]

LGTM 🦊 openai/gpt-5.5