LiT: Custom channels feature bits

[GeorgeTsagk]

Description

Bumps (lots of) dependencies to use the latest tapd feature bits, which allow us to switch on/off cutting edge features while maintaining backwards compatibility with older nodes.

The first feature we use are the noop-htlcs, a special type of HTLC that will reflect the asset balance change over the channel but not shift the satoshi balances at all. This is an example of a backwards incompatible change, as if only one party uses it, the channel will soon be force-closed as there will be a disagreement on the next channel state.

Will close #1080 in favor of this PR -- now we can enable noop-htlcs on all nodes that understand it, regardless of if there's an older version in the topology. This is exactly why we added the feature bits, in order for nodes to discover other peers' supported features. So for itests that do use backwards-compatibility LiT nodes, there should be no error, as the new node knows to not use noop-htlcs, because the noop-htlc feature bit was not communicated.

Go 1.24.6

By bumping everything to the latest version (master) we also indirectly needed to bump 1.24.6 for LiT itself, the first commits bumps the version of LiT accordingly. Can break this out into its own PR if needed.

Dependencies

lightninglabs/lndclient#239
lightninglabs/taproot-assets#1748
lightningnetwork/lnd#10182

[gemini-code-assist]

Summary of Changes

Hello @GeorgeTsagk, 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 introduces custom channel feature bits into Lightning Terminal (LiT), enabling the selective activation of cutting-edge features while maintaining backward compatibility with older nodes. The primary driver for this change is the integration of noop-htlcs, a specialized type of HTLC that reflects asset balance changes without affecting satoshi balances. To support these new capabilities, the project's Go version has been upgraded to 1.24.6, and a wide array of Go module dependencies have been updated. The changes ensure that LiT can interact with the latest tapd features, allowing for a phased rollout of new functionalities within the Lightning Network ecosystem.

Highlights

• Go Version Upgrade: The Go version used across the project's Dockerfiles and go.mod files has been uniformly updated from 1.23.12 to 1.24.6. This ensures the project leverages the latest language features and performance improvements.
• Comprehensive Dependency Bumps: Numerous Go module dependencies have been updated to their latest versions. This includes critical components like taproot-assets and lnd, which are essential for integrating new features such as custom channel feature bits and noop-htlcs.
• Integration of Custom Channel Feature Bits and Noop-HTLCs: The pull request integrates the concept of custom channel feature bits, specifically enabling noop-htlcs. This allows for asset balance changes to be reflected in channels without altering satoshi balances, which is crucial for advanced asset management on the Lightning Network. The implementation includes logic to ensure backward compatibility with older nodes that do not support this feature.
• Payment Error Handling Refinement: Refactoring in the accounts service has replaced the use of channeldb for payment database errors with paymentsdb, streamlining error handling and aligning with updated LND payment management structures.
• Test Adjustments for Noop-HTLCs: Integration tests for custom channels have been adjusted to account for the behavior of noop-htlcs, specifically by adding sendKeySendPayment calls to ensure sufficient satoshi balances for test scenarios where noop-htlcs do not directly affect satoshi balances.
• Temporary Go Module Replacements: Temporary replace directives have been added to go.mod for lnd, lndclient, and loop, pointing to the author's forks. This is a common practice for development and testing of features that are still under review or not yet merged upstream.

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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

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 issue 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 primarily focuses on bumping the Go version and several dependencies to support new custom channel feature bits, specifically noop-htlcs. The changes, including test adjustments to accommodate this new feature, are generally sound. However, there are a couple of areas that need attention. A critical issue is the presence of replace directives in go.mod pointing to a personal fork, which must be removed before merging. Additionally, several govet lint warnings have been suppressed using //nolint comments instead of addressing the underlying issue of using error strings as format strings. I've provided suggestions to fix these issues for better code quality and safety.