The bitcoind .cookie contains an autogenerated user (__cookie__) and
password (random string), which can be used instead of the rpc user name
and password. This commit allows for running against bitcoind without
having to access bitcoin.conf like in the case for pure
user/password/zmq configuration.
In this commit, we add a check during normal node construction to see if
the backend node supports Taproot. If it doesn't, then we want to
shutdown and force the user to take note.
To check if the node supports Taproot, we'll first try the normal
getblockchaininfo call. If this works, cool, then we can rely on the
value. If it doesn't, then we'll fall back to the getdeploymentinfo call
which was added in a recent version of bitcoind [1]. Newer versions of
bitcoind might also have this call, and the getblockchaininfo call, but
not actually populate the softforks field [2]. In this case, we'll fall
back, and we also account for the case when the getblockchaininfo RPC is
removed all together.
[1]: https://github.com/bitcoin/bitcoin/pull/23508
[2]: https://github.com/bitcoin/bitcoin/pull/25114Fixes#6773
In this commit, we change the flow of the rpc middleware registration
a bit. In order to allow a client to add rpc middleware interceptors in
a deterministic order, we now make the server send a "registration
complete" message to the client after compeleting the registration
process so that the client knows when it can go ahead and register the
next client.
In this commit, we fix a detected flake: we go to make a payment, and
then want to assert that 2 attempts we required. The existing logic
assumes that the success and the payment will still be on disk. With a
recent PR, we now delete failed payments by default, but after the fact,
in a non-atomic fashion.
We fix this issue simply by having all the nodes keep around failed
payments for the sake of all the old itests that assumed this
information would always be on disk.
Introduced in: https://github.com/lightningnetwork/lnd/pull/6438.
Fixes https://github.com/lightningnetwork/lnd/issues/6711.
In this commit, we let the registered middleware interceptors be stored
in a slice rather than a map so that the order in which the interceptors
are executed is guarenteed to be the same as the order in which they
were registered.
In this commit, we modify the `macaroons.NewService` consturctor to
accept the main interface rather than the raw DB. This allows us to use
other backends other than bolt or the kvdb interface to store the
macaroon root keys.
We also create a new ExtendedRootKeyStore interface that implements some
of the more advanced features we use such as macaroon encryption and
password rotation.
