As requested by users of node bundle software. They want to use the
wallet-unlock-password-file configuration option in their
default/template config file. This makes the first-time lnd setup a bit
more tricky since lnd will fail with an error if no wallet exists yet
while that config option is used.
The new wallet-unlock-allow-create option instructs lnd to not fail if
no wallet exists yet but instead spin up its unlocker RPC as it would
without the wallet-unlock-password-file being present.
This is not recommended for auto-provisioned or high-security systems
because the wallet creation RPC is unauthenticated and an attacker could
inject a seed while lnd is in that state.
To make it possible to use the wordlist used for aezeed outside of the
aezeed package we export certain properties of the word list and the
word list itself.
This commit adds two tests to check that a) the correct deadline is used
given different HTLC sets and b) when sweeping anchors the correct
deadlines are used.
This commit adds a deadline field to mockSweeper that can be used to
track the customized conf target (deadline) used for sweeping anchors.
The relevant test, TestChannelArbitratorAnchors is updated to reflect
that the deadlines are indeed taking effect.
In this commit, we made the change so that when sweeping anchors for the
commitment transactions, we will be aware of the deadline which is
derived from its HTLC set. It's very likely we will use a much larger
conf target from now on, and save us some sats.
This commit adds a new struct AnchorResolutions which wraps the anchor
resolutions for local/remote/pending remote commitment transactions. It
is then returned from NewAnchorResolutions. Thus the caller knows how to
retrieve a certain anchor resolution.
In this commit, we add a check inside EstimateFeePerKW for bitcoind so
that when the conf target exceeds the maxBlockTarget, we will use
maxBlockTarget instead.
A followup commit for PR#5332. In this commit we add more docs, rename
function updatePaymentState to fetchePaymentState, and add back the
check for channeldb.ErrPaymentTerminal after we launch shard.
In #5364 we added a new error path in the `StopDaemon` method to return
an error if shutdown was attempted while a rescan/recover instance was
in progress. Since the wallet actually won't fully stop (atm)
mid-recovery, the call effectively didn't do anything in that scenario,
so we started to return an error to properly reflect that. However this
causes certain itests to fail, as during recovery, the stop attempt will
fail leading to the test itself failing.
In this commit, we wrap the calls to stop a running daemon within a
`wait.NoError` call so we'll continually try to shut down the daemon
rather than quit on the first try.
Fixes#5423.
This commit aims to address a flaw in our anchor reserve enforcement
logic in which an inbound "legacy" channel (i.e. a channel with a
commitment type that precedes anchors) would be rejected by the
recipient if they have at least one opened channel using the anchors
commitment type and do not have enough on-chain funds to meet the
anchors reserve.
We do this to trigger a bug that will be resolved in a follow-up commit.
This bug prevents inbound legacy channels from being rejected by the
recipient if they have at least one anchor channel already opened
without an on-chain balance.
This commit refactors the resumePayment to extract some logics back to
paymentState so that the code is more testable. It also adds unit tests
for paymentState, and breaks the original MPPayment tests into independent tests
so that it's easier to maintain and debug. All the new tests are built
using mock so that the control flow is eaiser to setup and change.
This commit renames the mock structs by appending Old in their names. In
doing so the old tests stay unchanged and new mock structs can be added
in the following commit.
This commit adds payment session to shardHandler to enable private edge
policies being updated in shardHandler. The relevant interface and mock
are updated. From now on, upon seeing a ChannelUpdate message,
shardHandler will first try to find the target policy in additionalEdges
and update it. If nothing found, it will then check the database for
edge policy to update.
