To remove one more direct dependency to a variable in our main function,
we pass in the required parameter to the autopilot only instead of the
whole chain configuration.
As a preparation for separating the pure config related chain control
setup from the wallet related chain control, we store more information
in the chain control instance that is required for the wallet
initialization.
We'll refactor the wallet creation and unlock process in a following
commit and want to make it possible to not need a direct reference to
the macaroon service in our main function. Since we store it in the
interceptor chain anyway (if we're using macaroons in the first place),
we might as well use the instance there directly.
The block cache size in the chainreg.Config previously wasn't used but
instead the block cache was passed in as a separate parameter. We
replace the cache size with the actual cache in the config to streamline
things somewhat.
To simplify the message signing API even further, we refactor the
lnwallet.MessageSigner interface to use a key locator instead of the
public key to identify which key should be signed with.
To simplify the API surface of a remote signer even more, we refactor
the SignMessage and SignMessageCompact calls to only accept a key
locator as we always know what key we're using for signing anyway.
To make it possible to use a remote lnrpc server as a signer for our
wallet, we need to change our main interface to sign the message instead
of the message's digest. Otherwise we'd need to alter the
lnrpc.SignMessage RPC to accept a digest instead of only the message
which has security implications.
To make it possible to use a remote signrpc server as a signer for our
wallet, we need to change our main interface to sign the message instead
of the message's digest. Otherwise we'd need to alter the
signrpc.SignMessage RPC to accept a digest instead of only the message
which has security implications.
Fixes#5830.
When a channel for a node is announced before the node itself is
announced on the network, it's possible that we have channels for a node
but no features defined yet. This was previously logged as a warning
which spammed the log unnecessarily.
Recent gomobile versions are now building for the `xcframework`
packaging format instead of `framework`. This commit addresses
this by outputting to a `.xcframework` folder.
We now redirect the mineBlocks function to the mineBlocksSlow function
which waits after each mined block. To reduce the overall time impact of
using that function everywhere, we only wait 20 milliseconds instead of 50ms
after each mined block to give all nodes
some time to process the block. This will still slow down everything by a bit
but reduce flakes that are caused by different sub systems not being
up-to-date.
The latest version of btcd allows its stall handler to be disabled. We
use that new config option to make sure the mining btcd node and the lnd
chain backend btcd node aren't disconnected if some test takes too long
and no new p2p messages are exchanged.
This commit adds a fetchMinMempoolFee function to the BitcoindEstimator
that fetches the current min mempool fee from the bitcoind backend. The
commit then also updates the BitcoindEstimator to use a minFeeManager
for it's minFeeManager member and uses the fetchMinMempoolFee function
to initialise this.
With this commit we update the release template to download Roasbeef's
key from the git repository via GitHub.
We also update the key mentioned in the template to the new signing key.
[skip ci]
The validateFeeRate function uses the availableBalance function to get
the current spendable balance of a channel, adds the old fee and then
ensures that the new fee is not larger than the amount we have available
to spend. This commit also removes the local reserve check in the
validateFeeRate function since the balance returned from
availableBalance already takes the local reserve into acccount.
In this commit we ensure that the max fee calculated in the MaxFeeRate
function takes the local reserve amount into account along with any
pending HTLCs. This is done by calling the avaialbeBalance function.
In this commit, a subscription is made to topology updates. For any
NodeAnnouncements received for our peristent peers, we store their newly
advertised addresses. If at the time of receiving these new addresses
there are any existing connection requests, these are updated to reflect
the newly advertised addresses.
In this commit we demonstrate a bug to show that if an inbound peer
changes their listening address to one not advertised in their original
NodeAnnouncement then we will not be able to reconnect to them. This bug
will be fixed in a follow-up commit.
This commit just ensures that we fetch the lastest advertised addresses
for a peer from the db for both inbound and outbound peers. The reason
for seperating this into its own commit is to make future commits in
this PR easier to review.
The point of this commit is to make future commits in the same PR easier
to review. All that this commit does is exit early if the peer we are
considering is not persistent instead of having a bunch of logic
indented in an if-clause.
This commit adds an itest to demonstrate that if a peer advertises
multiplie external IP addresses, then they will not all be used to
reconnect to the peer during reconnection. This will be fixed in a
follow-up commit.
The assertNumConnection function currently takes in an 'expected' number
of connections argument and asserts that both alice and bob only each
only have that number of connections. So this fails to be useful if say
alice is also connected to charlie cause then if we call
assertNumConnections between alice and bob it will fail saying there are
2 connections between them since all it does is count alice's total
number of connections. This commit replaces this function with 2 new
functions: assertConnected which asserts that at least one connection
exists between two peers and assertNotConnected which asserts that no
connections exists between the two peers.
