build(deps): bump github.com/lightningnetwork/lnd from 0.20.1-beta to 0.21.0-beta

[dependabot]

Bumps github.com/lightningnetwork/lnd from 0.20.1-beta to 0.21.0-beta.rc3.

Release notes

Sourced from github.com/lightningnetwork/lnd's releases.

lnd v0.21.0-beta.rc3

Database Migrations

lightningnetwork/lnd#9861: This migrates the payment store from the KV format to native SQL. This migration will only run if the --db.use-native-sql flag is set along with the --db.backend option set to sqlite or postgres. Users may opt out of this migration by setting the --db.skip-native-sql-migration flag.

Verifying the Release

In order to verify the release, you'll need to have gpg or gpg2 installed on your system. Once you've obtained a copy (and hopefully verified that as well), you'll first need to import the keys that have signed this release if you haven't done so already:

curl https://raw.githubusercontent.com/lightningnetwork/lnd/master/scripts/keys/roasbeef.asc | gpg --import

Once you have the required PGP keys, you can verify the release (assuming manifest-roasbeef-v0.21.0-beta.rc3.sig and manifest-v0.21.0-beta.rc3.txt are in the current directory) with:

gpg --verify manifest-roasbeef-v0.21.0-beta.rc3.sig manifest-v0.21.0-beta.rc3.txt

You should see the following if the verification was successful:

gpg: Signature made Wed Sep 30 17:35:20 2020 PDT
gpg:                using RSA key 60A1FA7DA5BFF08BDCBBE7903BBD59E99B280306
gpg: Good signature from "Olaoluwa Osuntokun <laolu32@gmail.com>" [ultimate]

That will verify the signature of the manifest file, which ensures integrity and authenticity of the archive you've downloaded locally containing the binaries. Next, depending on your operating system, you should then re-compute the sha256 hash of the archive with shasum -a 256 <filename>, compare it with the corresponding one in the manifest file, and ensure they match exactly.

Verifying the Release Timestamp

From this new version onwards, in addition time-stamping the git tag with OpenTimestamps, we'll also now timestamp the manifest file along with its signature. Two new files are now included along with the rest of our release artifacts: manifest-roasbeef-v0.21.0-beta.rc3.txt.asc.ots.

Assuming you have the opentimestamps client installed locally, the timestamps can be verified with the following commands:

ots verify manifest-roasbeef-v0.21.0-beta.rc3.sig.ots -f manifest-roasbeef-v0.21.0-beta.rc3.sig

Alternatively, the OpenTimestamps website can be used to verify timestamps if one doesn't have a bitcoind instance accessible locally.

These timestamps should give users confidence in the integrity of this release even after the key that signed the release expires.

Verifying the Release Binaries

Our release binaries are fully reproducible. Third parties are able to verify that the release binaries were produced properly without having to trust the release manager(s). See our reproducible builds guide for how this can be achieved. The release binaries are compiled with go1.26.3, which is required by verifiers to arrive at the same ones. They include the following build tags: autopilotrpc, signrpc, walletrpc, chainrpc, invoicesrpc, neutrinorpc, routerrpc, watchtowerrpc, monitoring, peersrpc, kvdb_postrgres, kvdb_etcd and kvdb_sqlite. Note that these are already included in the release script, so they do not need to be provided.

The make release command can be used to ensure one rebuilds with all the same flags used for the release. If one wishes to build for only a single platform, then make release sys=<OS-ARCH> tag=<tag> can be used.

... (truncated)

Changelog

Sourced from github.com/lightningnetwork/lnd's changelog.

Release Branch Management

Overview

This document describes the branch management workflow for lnd releases. The master branch remains open for merges at all times. Release stabilization happens on dedicated release branches, with CI automation handling backports of milestone-tagged changes. This approach maintains continuous development velocity while ensuring stable releases.

Branch Model Principles

The release process operates on four core principles:

Master is always open. Developers merge approved pull requests at any time without coordination around release windows. No merge freezes occur.

Each major release gets a dedicated branch. When cutting a new major version, create a release branch from master. This branch handles all release candidates and subsequent patch releases for that version series.

CI automation handles backports. Pull requests merged to master and tagged with a release milestone are automatically backported to the corresponding release branch. The automation creates backport PRs when conflicts occur.

Changes flow one direction only. Changes move from master to release branches, never in reverse. Master always represents the latest development state.

Master Branch

The master branch contains ongoing development work for future releases. It never freezes for releases.

Master Version Convention

Master uses a .99 patch version to indicate unreleased development work. After creating the v0.21.x-branch branch, update master's version in build/version.go to 0.21.99-beta. This clearly signals post-0.21 but pre-0.22 code.

When creating the next release branch (v0.22.x-branch), update master to 0.22.99-beta. This pattern sorts correctly and is immediately recognizable as a development build.

Merging to Master

Developers merge to master following normal review processes. If a change should be included in an active or upcoming release, tag the pull request with the appropriate milestone (v0.21.0, v0.21.1, etc.). The CI automation handles

... (truncated)

Commits

• 37fe1ea Merge pull request #10847 from ziggie1984/bump-version-v0.21.0-rc3
• 02dc7f8 build: bump btcwallet to v0.16.18
• 79e0d6b mod: bump sqldb to v1.0.13
• 657cbd4 mod: drop queue replace, require queue/v1.2.0
• b0c2c44 build: bump version to v0.21.0-beta.rc3
• 09bd523 Merge pull request #10860 from ziggie1984/backport-10841-to-v0.21.x-branch
• 711b685 build: bump otel sdk past vulnerable version
• abf3b76 kvdb: bump grpc module floor
• 4b4e402 build: bump grpc to v1.79.3
• 78cec3d Merge pull request #10859 from lightningnetwork/backport-10851-to-v0.21.x-branch
• Additional commits viewable in compare view

[im-adithya]

Changed to v0.21.0.rc3 from beta since there are no changes: comparison

[im-adithya]

tACK, tested every method from lnclient/lnd/wrapper/lnd.go

(build is failing for a different reason: go version mismatch)

[rolznz]

I think we should avoid the rc versions if possible

[rolznz]

@im-adithya so your change needs to be undone here, right?