Bump LND to latest

[darioAnongba]

Bump of LND to latest version requires:

• Upgrading LND to 0.21.0 introduces a race condition in the assets_test. This race is introduced by changes in the chancloser. The channel may not be market as fully closed immediately after the close transaction is confirmed.
• LND 0.21.0 introduces a new limit on the timelock delta of 24. Previous limit was 18 so a change is required to bump this limit in all tests to avoid errors.
• Bump sqldb
• Bump taproot-assets and taprpc

[gemini-code-assist]

Summary of Changes

Hello @darioAnongba, 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 focuses on upgrading the project's core Lightning Network Daemon (LND) dependency to its latest release candidate. This update is crucial for maintaining compatibility and leveraging the newest features and fixes from LND. The changes also include necessary adjustments to integration tests to ensure that existing functionalities remain stable and correctly interact with the updated LND version, particularly concerning channel policy parameters and the handling of channel closure events.

Highlights

• Dependency Updates: The primary LND dependency has been updated to v0.20.1-beta.rc1, along with related btcec/v2 and lnd/sqldb modules, ensuring alignment with the latest Lightning Network Daemon release.
• Integration Test Adjustments: Several integration tests have been modified to accommodate changes introduced by the LND update, specifically adjusting TimeLockDelta values in channel policy updates and improving robustness for asynchronous channel closure events.
• Asynchronous Channel Closure Handling: The itest/assets_test.go file now includes a polling mechanism to reliably detect closed channels, addressing the asynchronous nature of the channel arbitrator's processing of close events.

🧠 New Feature in Public Preview: You can now enable Memory 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.

Changelog

• go.mod
  • Updated github.com/btcsuite/btcd/btcec/v2 from v2.3.4 to v2.3.6.
  • Updated github.com/lightningnetwork/lnd from v0.20.0-beta to v0.20.1-beta.rc1.
  • Updated github.com/lightningnetwork/lnd/sqldb from v1.0.11 to v1.0.13-0.20260113150738-e26a114cdcf0.
• go.sum
  • Updated cryptographic checksums for the bumped btcec/v2, lnd, and lnd/sqldb dependencies to reflect their new versions.
• itest/assets_test.go
  • Refactored assertClosedChannelAssetData to poll for closed channels using wait.Predicate, ensuring the channel is registered in the database before proceeding with assertions, which accounts for asynchronous processing by the channel arbitrator.
• itest/litd_custom_channels_test.go
  • Adjusted TimeLockDelta values in UpdateChannelPolicy calls from 19 to 25 and 18 to 24.
• itest/litd_firewall_test.go
  • Modified multiple instances of TimeLockDelta in UpdateChannelPolicy calls from 20 to 24 and one instance from 10 to 24.

Activity

• No human activity (comments, reviews) has been recorded on this pull request yet.

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 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 counter productive. 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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

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. ↩

[gemini-code-assist]

Code Review

This pull request bumps the LND dependency to its latest version and adjusts several integration tests to align with the changes. The modifications primarily involve updating TimeLockDelta values in tests and refining how closed channels are asserted to handle asynchronous processing. While most changes appear correct and necessary for compatibility, I've identified a potential issue in one of the firewall tests where the test logic seems to be broken by an updated value. My review provides a suggestion to fix this.

[ziggie1984]

why only 20.1 tho, I would prefer referencing the current master commit ?

[darioAnongba]

me as well but that is forbidden by LiT policy apparently. It makes sense as referencing random commits that are not stable releases (or at least RCs) is not a great idea, but if tests pass then it should be okay.

cc: @ViktorT-11

On a side note, LiT doesn't yet support 0.20.1, that is not even released yet I guess the first step is to align LiT to 0.20.1 and then to 0.21.0 ? or is 0.20.1 just a patch?

[ziggie1984]

20.1 is just a patch so we go first 20.1 and then master commit LND, but then you also need to update your comments you made during this PR, because you were referencing 21

[ViktorT-11]

Yes, we should preferebly not bump to an untagged version, so I'm in favour of using v0.20.1-beta.rc1 here.
The reason being is that if we need make hotfix release, which for example #1215 could motivate (as that solves issues for the AutoFees algo), we wouldn't be blocked by having an unreleased version of lnd merged to master.

By referencing v0.20.1-beta.rc1, we could instead make a litd RC release which ships with lnd v0.20.1-beta.rc1.

[darioAnongba]

this PR does target 0.21, I can have an other one for 0.20.1 but this one can stay open in draft until it becomes relevant (when we have our first 0.21 RC tag?). It is used for testing before LND officially releases.

See this PR as example: lightninglabs/taproot-assets#1958

[ZZiigguurraatt]

On a side note, LiT doesn't yet support 0.20.1

litd master now compiles with lightningnetwork/lnd#10556 if I manually replace it

[darioAnongba]

Sorry I meant doesn't support as it's not the targeted version in go.mod on master. As per @ziggie1984 comment, because it's only a patch, we can skip that version and go straight to 0.21 with this PR ( that will stay open waiting on the RC1 tag).

[darioAnongba]

ok the PR is now green targeting latest LND and TAPD. No need to approve but would be nice to get your thoughts on it. We can reference this branch anywhere we need latest LND (in taproot-assets or in tests, etc).