To make the linter happy, make a pointer to the inner resolver.
Otherwise the linter would complain with
copylocks: literal copies lock value
since we'll add a mutex to the resolver in following commits.
Since the tests set a quite high fee rate before the node goes to chain,
the HTLCs wouldn't be economical to sweep at this fee rate.
Pre sweeper handling of the second-level transactions this was not a
problem, since the fees were set when the second-levels were created,
before the fee estimate was increased.
We risked deadlocking on shutdown if a client (in our case a contract
resolver) attempted to schedule a sweep of an input after the
ChainNotifier had been shut down. This would cause the `collector`
goroutine to exit, and not handle incoming requests, causing a deadlock
(since the ChainArbitrator is being stopped before the Sweeper in the
server).
To fix this we could change the order these subsystems are stopped, but
this doesn't ensure there aren't other clients that could end up in the
same deadlock scenario. So instead we keep handling the incoming
requests even after the collector has exited (immediatly returning an
error), until the sweeper is signalled to shutdown.
This commit unsets option static remote key required for peers that
we have existing legacy channels with. This ensures that we can still
connect to peers that do not recognize this feature bit that we have
existing channels with.
This add a test for inputs that gets re-ordered because the inputs with
required TxOuts must be added first.
We add a new step to the test that checks that all inputs were signed at
the correct tx input index.
This test would fail without the previous commit.
This commit fixes an issue that would arise if inputs without required
TxOuts would be swept together with inputs with required TxOuts. In this
case we would add the required ones first to the transaction, but did
not change the order we signed the inputs, resulting in signing the
wrong input index.
This adds the scenario to the local force close test cases where a node
force closes one of its channels, then lose state (or do recovery)
before the commmitment is confirmed. Without the previous commit this
would go undetected.
outdated local state
This commit fixes a bug that would cause us to not sweep our local
output in case we force closed, then lost state or attempted recovery.
The reason being that we would use or local commit height when deriving
our scripts, which would be incorrect. Instead we use the extracted
state number to derive the correct scripts, allowing us to sweep the
output.
Allthough being an unlikely scenario, we would leave money on chain in
this case without any warning (since we would just end up with an empty
delay script) and forget about the spend.
Similar to what we did for the local state handling, we extract handling
all known remote states we can act on (breach, current, pending state)
into its own method.
Since we want to handle the case where we lost state (both in case of
local and remote close) last, we don't rely on the remote state number
to check which commit we are looking at, but match on TXIDs directly.
The tests didn't really roll back the channel state, so we would only
rely on the state number to determine whether we had lost state. Now we
properly roll back the channel to a previous state, in preparation for
upcoming changes.
Since it turned out borking channels on every received error could cause
us to bork channels in case of a sync error with C-lightning, we revert
this for now.
Now that inputs might have accompanied outputs to be added to the sweep
tx, we add them to the sweep transaction first, and account for it when
calculating the change amount.
If inputs require outputs to be added at the same time, this will
change the weight and amount calculations, so we must account for that.
We wait to get the weight estimator for the sweep tx until needed,
such that we can easily choose whether to include a change output or not
in the estimate. This is needed for the case where the second level
transactions can pay for their own fee, so no change output is needed.
Similar to the previous commit, we fix a bug resulting in the wrong
commit weight being calculated when an HTLC just above the remote's
duslimit was added from the remote. This was a result of using the
successFee instead of the timeoutFee when checking whether it was dust,
making us consider it dust when it shouldn't have been.
In this commit we fix a bug resulting in the wrong commit weight being
calculated when an HTLC just below the remote's duslimit was added. This
was a result of using the timeoutFee instead of the successFee when
checking whether it was dust, making us consider it non-dust when it
should have been.
We rename the field Capacity on local channels to Balance, define a new
method ChannelInfo on the manager config that let us query the database
for our latest channels state. Using this we will use the current local
balance instead of the channel capacity when doing allocation
calculations.
This commit fixes a go 1.15 vet check.
In doing so it uncovers that the time caveat check is actually reversed.
Since we should check that the caveat is added, we should only fail the
check when the caveat prefix is not equal.
When we cancel a confirmation request, we should remove the request from
the height map regardless of the current height. Otherwise we end up in
the situation when the height is reached, the notification is attempted
sent which results in a crash.
Johan T. Halseth