Matt Corallo [Thu, 23 Mar 2023 19:14:08 +0000 (19:14 +0000)]
Don't panic on tx broadcast failures
In general LDK will often broadcast transactions which aren't
actually able to get into the mempool. That's generally fine,
though could indicate a significant issue. Thus, we previously had
a panic in place for it to ensure developers are notified and we
can investigate.
However, now that people are trying to actually *use* ldk-sample,
we should just remove the panic and print something with more
details.
Prompt user to provide at least 2 arguments rather than 3
env::args returns the name of the binary, which isn't something
the end user would think about. So while we require at least 3
arguments, it makes sense to only ask for 2.
Max Fang [Tue, 18 Oct 2022 01:57:58 +0000 (18:57 -0700)]
Fix channel manager race panic
The race:
- (1) If a channel manager is starting for the first time, it gets its
initial block hash by calling BlockSource::get_blockchain_info() and
constructing a BestBlock out of that.
- (2) During the initial chain sync, if chain_tip.is_none() then the
best chain_tip is retrieved using
lightning_block_sync::init::validate_best_block_header() which
similarly uses BlockSource::get_best_block()
- If blocks were mined between (1) and (2), the channel manager’s block
hash will be at a lower height than that of the block hash contained
inside the chain_tip fed to the SpvClient. Suppose that this results
in the channel manager being at block 1 and the SpvClient being at
block 2. Once block 3 comes in and the SpvClient detects it via
poll_best_tip(), the SpvClient computes the ChainDifference between
its saved chain_tip value and block 3, concluding that it just needs
to connect block 3. However, when Listen::filtered_block_connected is
called using the data in block 3, the channel manager panics with
“Blocks must be connected in chain-order - the connected header must
build on the last connected header” - because block 3’s prev block
hash is block 2’s block hash, rather than block 1’s block hash which
the channel manager expects
This commit fixes it by removing the fresh channel manager's query to
the block source, instead deriving its best block from the validated
block header using a new `.to_best_block()` method.
Elias Rohrer [Mon, 5 Sep 2022 10:18:30 +0000 (12:18 +0200)]
Remove redundant `is_none()` check
We don't need to check the same iterator twice. And, as at this point
pubkey will always be `Some(..)`, we don't need to check it either.
We therefore can just remove the first part of the condition.
Matt Corallo [Sun, 3 Apr 2022 02:26:07 +0000 (02:26 +0000)]
Stop connecting outbound on shutdown in addition to stopping listen
Now that we persist the network graph on shutdown, there is a
nontrivial amount of time spent between when we start shutdown and
when we complete. Thus, and to be somewhat more pedantic as a
sample implementation, we should really stop making new outbound
connections once shutdown starts, and not only focus on new inbound
connections.
Matt Corallo [Sun, 27 Mar 2022 18:19:40 +0000 (18:19 +0000)]
Allow `txn-mempool-conflict` errors when broadcasting transactions
This can be seen, among other times, when a channel is
cooperatively- (or counterparty-)closed and we restart, causing us
to attempt to broadcast our local commitment tx, which conflicts
with the original closing transaction.
Matt Corallo [Fri, 25 Mar 2022 23:16:32 +0000 (23:16 +0000)]
Correct balance printing in cli
The `outbound_capacity_msat + unspendable_punishment_reserve`
calculation is fine, as long as the channel's current balance is
above the reserve value. If it is not, we'll spuriously report a
balance higher than we actually have.
This corrects that be havior by using the new(er) `balance_msat`
field instead.
Matt Corallo [Thu, 24 Mar 2022 00:05:31 +0000 (00:05 +0000)]
Cleanly shut down PeerManager by disconnecting before we quit
This ensures we don't keep processing peer messages long after we
stopped the backgroundprocessor (which results in our
`ChannelManager` on disk being stale compared to monitors).