lnd 0.15.1 - Release Candidate 1

[Olaoluwa Osuntokun]

Hi y'all,

We've just cut the first release candidate for the much anticipated lnd
v0.15.1 release!

The first release candidate itself can be found here:
https://github.com/lightningnetwork/lnd/releases/tag/v0.15.1-beta.rc1

With the full release notes living here:
https://github.com/lightningnetwork/lnd/blob/v0.15.1-beta.rc1/docs/release-notes/release-notes-0.15.1.md

As our usual minor releases go, this release contains a ton of important bug
fixes, so we recommend that all users update when they're readily able to.

This release also contains a few items that didn't quite make it over to the
prior 0.15 mailing list that are worth mentioning:

  * A new _optional_ migration to reclaim all the disk space allocated to
    the _legacy_ revocation log. For large nodes this has the potential to
    reclaim _tens of GBs_. One user reported their DB size shrunk from 30 GB
    all the way down to _129 MB_.

      * The migration can be activated by setting a new CLI flag:
        db.prune-revocation=false. Once the migration is running, the node
        can be restarted, with the migration picking up back where it left
        off.

      * This migration might take some time for very large/old nodes. A user
        reported that migrating their 3.7 million entries (16 GB db size)
        took around 249 seconds on local hardware.

  * Zero conf channels, and scid aliases have been fully implemented!

      * Activating these new protocol features required the addition of two
        distinct CLI config options: `protocol.option-scid-alias` and
        `protocol.zero-conf`. It's possible to activate the scid-alias
        option independently (invoices now no longer leak the true scid of a
        channel, matters more for unannounced channels). However in order to
        use zero conf, _both_ options must be active.

      * We've attempted to integrate the new protocol-level zero conf feature
        in the safest way possible. See this set of standalone documentation
        for more details:
        https://github.com/lightningnetwork/lnd/blob/v0.15.1-beta.rc1/docs/zero_conf_channels.md.

      * The TL;DR of the above is that you can request a zero conf channel
        with a new field in the `OpenChannel` message
        (https://api.lightning.community/#openchannel): `zero_conf`. There's
        also one for the `scid_alias` feature. On the accepting side, all
        zero conf channels are _explicitly rejected_ unless a
        ChannelAcceptor instance is active. If active, then the acceptor
        must also _explicitly_ allow zero conf by setting the `zero_conf`
        field to true in the channel acceptor response
        (https://api.lightning.community/#lnrpc-channelacceptresponse). The
        `min_accept_depth` field should also be set to zero to ensure
        widespread cross implementation compatibility.

      * For _existing_ channels, if the `option-scid-alias` flag is set,
        then we'll attempt to retroactively "upgrade" the channel to also
        support scid aliases. What this means practically is that LSP-like
        nodes that have many private channels to mobile users will
        negotiate a new scid alias, with users using that alias as soon as
        they're upgraded. privacy++

  * We now try to use P2TR errwhere possible:

      * This means we'll use P2TR addresses for: all funding change
        addresses, chain sweeps, and normal change addresses (routine
        sends).

      * To err on the safe side, we'll now perform a check at start up to
        see if the full node backend supports Taproot or not. Concretely, we
        now only support Bitcoind versions: 21, 22, and 23 (earliest release
        Jan 2021). For btcd users, you need to be running btcd v0.23.0
        (release June of this year), though the master branch has had
        support since March of this year.

          * If this new requirement is a major issue for your
            product/company/service/wallet/app please don't hesitate to
            contact us. We're open to rolling this back, though the
            alternative was a much more granular API-call level gating that
            also wouldn't be 100% full proof (users uses a P2TR address for
            a PSBT call, backend rejects it, etc).
 

We've also fixed a number of bug fixes that lead to some force closes on
mainnet. See the release notes for full details!

If you need help testing the release candidate or have some questions on the
included changes, feel free to reach out to me directly with any
questions/concerns.

-- Laolu