feat(config): support custom signet block time

[tee8z]

Change Description

Adds support for configuring the expected block interval for custom signet
networks via bitcoin.signetblocktime.

This allows lnd to validate headers correctly when connected to a custom
signet whose backing bitcoind nodes were started with -signetblocktime.
The configured value is applied to the custom signet chain params and is
validated to be at least one second and no greater than the target timespan.

This simplifies running lnd nodes on custom signet networks such as
Mutinynet.

Steps to Test

1. Run the new unit test:

   go test . -run TestApplySigNetBlockTime -count=1

2. Optionally test manually with a Mutinynet Bitcoin Core backend configured
   with 30-second custom signet blocks and compact filter support:

   chain=signet
   signetblocktime=30
   signetchallenge=512102f7561d208dd9ae99bf497273e16f389bdbd6c4742ddb8e6b216e64fa2928ad8f51ae
   
   blockfilterindex=1
   peerblockfilters=1
   server=1
   txindex=1

3. Start lnd with matching Mutinynet signet settings and neutrino pointed at
   that Bitcoin Core node:

   [Bitcoin]
   bitcoin.node=neutrino
   bitcoin.signet=true
   bitcoin.defaultchanconfs=1
   bitcoin.signetchallenge=512102f7561d208dd9ae99bf497273e16f389bdbd6c4742ddb8e6b216e64fa2928ad8f51ae
   bitcoin.signetblocktime=30s
   
   [neutrino]
   neutrino.connect=127.0.0.1:29333
   neutrino.maxpeers=1
   neutrino.persistfilters=true

   If testing through a local port-forward, forward the Bitcoin Core P2P port
   to 127.0.0.1:29333. If public P2P is reachable, set
   neutrino.connect directly to that host instead.

4. Verify that lnd starts and syncs headers for that custom signet.

5. Verify invalid values fail config validation:

   lnd --bitcoin.signet --bitcoin.signetblocktime=500ms

   This should fail with an invalid signet block time error.

Pull Request Checklist

Testing

• Your PR passes all CI checks.
• Tests covering the positive and negative (error paths) are included.
• Bug fixes contain tests triggering the bug to prevent regressions. N/A,
  this is a new feature.

Code Style and Documentation

• The change is not
  insubstantial.
  Typo fixes are not accepted to fight bot spam.
• The change obeys the
  Code Documentation and Commenting
  guidelines, and lines wrap at 80.
• Commits follow the
  Ideal Git Commit Structure.
• Any new logging statements use an appropriate subsystem and logging
  level. N/A, no logging statements added.
• Any new lncli commands have appropriate tags in the comments for the rpc
  in the proto file. N/A, no lncli commands added.
• There is a change description in the release notes,
  or [skip ci] in the commit message for small changes.

[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 introduces the ability to configure a custom block interval for signet networks in lnd. By adding the bitcoin.signetblocktime parameter, the node can now correctly validate headers when connected to custom signet networks that utilize non-standard block times, such as Mutinynet. This change includes necessary configuration updates, validation logic, and comprehensive unit tests to ensure stability.

Highlights

• Configuration Support: Added a new configuration option bitcoin.signetblocktime to allow users to specify a custom block interval for signet networks.
• Validation Logic: Implemented validation to ensure the custom block time is at least one second and does not exceed the target timespan.
• Testing: Added unit tests to verify correct application of the block time and to ensure invalid configurations are rejected.

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

[gemini-code-assist]

Code Review

This pull request introduces a new configuration option, bitcoin.signetblocktime, allowing users to override the expected block interval for custom signet networks. It includes validation logic, configuration updates, and corresponding unit tests. The reviewer suggested adding a nil check for the params pointer in applySigNetBlockTime to prevent potential nil pointer dereferences.

[github-actions]

PR Severity: MEDIUM

Automated classification | 3 files (excl. tests) | 51 lines changed

Medium files (3):

• config.go - Root-level configuration parsing (other Go files, MEDIUM)
• lncfg/chain.go - Chain configuration struct (lncfg/*, MEDIUM)
• sample-lnd.conf - Sample configuration file (MEDIUM)

Analysis:
This PR adds support for a custom signet block time (bitcoin.signetblocktime) to allow lnd to validate headers correctly against custom signet networks such as Mutinynet. Changes are limited to configuration parsing in lncfg/chain.go, config.go, and sample-lnd.conf.

No bump conditions triggered: 3 non-test files changed (threshold: 20), 51 non-test lines changed (threshold: 500), no critical packages touched.

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

[TechLateef]

LGTM

[starius]

There are other fields of type time.Duration in chaincfg.Params

// TargetTimespan is the desired amount of time that should elapse
// before the block difficulty requirement is examined to determine how
// it should be changed in order to maintain the desired block
// generation rate.
TargetTimespan time.Duration

TargetTimespan should be changed so that difficulty is re-targeted every 2016 blocks.

Also I see MinDiffReductionTime, but it seems to be disabled in signet.

[tee8z]

Agreed, TargetTimespan is another consensus-critical option we could expose. For this PR, I think lnd should mirror the Mutinynet fork directly and only override TargetTimePerBlock:

benthecarman/bitcoin@2fda7bf

Supporting custom TargetTimespan values seems like a separate option that we should add when there is a live custom signet that needs it.

[starius]

1. Verified Mutinynet sync over neutrino.

block_height: 3143143
block_hash: 000000668f7fdb0590cfa342f4c6b8084e748e380993c0bd629c56336ea8e0e3
best_header_timestamp: 1780176606 = 2026-05-30 21:30:06 UTC
synced_to_chain: true
wallet_synced: true

2. I managed to sync Mutinynet's Bitcoind fork and to run LND against it:

bitcoind: height 3143308, hash 00000308dae16781d47c0ab838c6d30b7bafb67488721221a73861d027b27e98, IBD false
lnd: same height/hash, synced_to_chain=true, wallet_synced=true
timestamp 1780182033 = 2026-05-30 23:00:33 UTC

But LND fails in bitcoin.node=bitcoind mode against the Mutinynet's Bitcoind if bitcoin.signetchallenge / bitcoin.signetblocktime are specified:

expected network Unknown BitcoinNet (3408781221), got SigNet

So LND options bitcoin.signetchallenge and bitcoin.signetblocktime must not be set in bitcoin.node=bitcoind mode.

Can you change LND so it fails with more user-friendly message if someone tries to pass bitcoin.signetchallenge and bitcoin.signetblocktime, please?

Also could you adjust the docs to write it down there, please?

3. I think this won't work with btcd backend which currently does not support this option. Should LND print a warning if attempted to use this flag with btcd backend? Also, can we update btcd to support this signetblocktime as well?

[starius]

LGTM pending the comments 🚀

The code is good and it was tested manually to work with both neutrino and MutinyNet's bitcoind.

[tee8z]

sweet, I think I covered those last comments, but please let me know if there is anything else