build+lncfg: support pruned bitcoind backends

[wpaulino]

To minimally support lnd deployments connected to pruned nodes, we've extended our bitcoind RPC client with the ability to request blocks that the server has already pruned. This is done by connecting to the server's full node peers and querying them directly. The number of peers we connect to can be set through the new pruned-node-max-peers config option; it is configured with a default of 4 at the moment. Ideally, this is a capability supported by the server, though this is not yet possible with bitcoind.

Block caching is not done yet, but will be expected to roll out along with this feature as a separate PR to minimize bandwidth consumption.

Note that a lot of the diff is unrelated due to a name change within the updated btcd dependency that caused changes across several files in the codebase.

Depends on btcsuite/btcwallet#737.
Fixes #2997.

[Roasbeef]

@wpaulino why do you see this only partially addresses #2997?

[wpaulino]

#2997 suggests an alternative path where we control the pruning window instead, and I wasn't sure if we'd still want that. In any case, this branch should fully support pruned nodes by just fetching pruned blocks from peers.

[Roasbeef]

Ah gotcha, yeah I think this approach is superior as it doesn't require lnd to be in lock-step with the full node. The pruned window route would only work if the node wasn't yet fully synced/pruned when lnd started up. In addition that design wouldn't actually support multiple lnd nodes connecting to a single pruned node, as their prune windows could get out of sync.

[Roasbeef]

Needs a rebase!

[wpaulino]

@Roasbeef rebased, the branch now depends on #5047 in order to build.

[Roasbeef]

LGTM 🐊

[Roasbeef]

Weird how it isn't showing conflicts for the commits duplicated here vs the pubkey import stuff just merged in?

[Roasbeef]

LGTM 👑

[mandelmonkey]

Does this mean that LND will be able to validate channels that were created before the pruned data?

[wpaulino]

Yes @mandelmonkey, it'll request pruned data from the bitcoind peers.

[vegardengen]

What if the bitcoind peers are also pruned? All of them?

(Maybe I am overly paranoid)

[wpaulino]

Good question, lnd will currently block on waiting for a full node connection if that's the case. Glancing at bitcoind's source, I didn't find any requirements for having at least N full node connections, so we wouldn't be able to enforce it at that level. It looks like we could use bitcoind's getnodeaddresses RPC to receive additional addresses the node isn't connected to, but this has yet to be implemented.

[mmilata]

Thanks for this useful feature! Is the section https://github.com/lightningnetwork/lnd/blob/master/docs/safety.md#pruned-bitcoind-node still true?

[wpaulino]

@mmilata no that needs an update. It's now safe to run a pruned node regardless of how many blocks have been pruned.

[kroese]

@wpaulino Now that Bitcoin RPC supports getblockfrompeer would it be an option to use that instead of this custom logic?