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).
Matt Corallo [Sun, 17 Oct 2021 00:50:34 +0000 (00:50 +0000)]
Swap time for chrono and log subsecond precision for times
The `time` crate appears to be basically undocumented (or, at
least, I couldn't find any documentation). `chrono` isn't super
well-documented, but at least its passable.
Matt Corallo [Mon, 27 Sep 2021 20:03:12 +0000 (20:03 +0000)]
Use an explicit handle when spawning RPC calls
This resolves a panic like the following, which is caused when a
non-Tokio thread tries to broadcast a transaction, for example
when a transaction is broadcasted indirectly by the background
processor.
```
thread '<unnamed>' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime', src/bitcoind_client.rs:253:9
```
Makes send_raw_transaction return Txid instead of RawTx
'bitcoind_client::send_raw_transaction' was returning 'RawTx' which, while syntactically correct (it's a wrapper around String), made no sense conceptually.
Since rust-bitcoin/rust-lightning@f65d05c, `Txid` can be used instead.
'rust-lightning' needs to be bumped to v0.0.100 rev d523b6e so 'TryInto::<Txid>' can be found in 'lightning-block-sync'. Bumping it any further will change 'PeerManager's API due to https://github.com/rust-bitcoin/rust-lightning/commit/45853b3a956f83569dff1010a43a33c57487698a
Matt Corallo [Tue, 17 Aug 2021 01:33:01 +0000 (01:33 +0000)]
Allow "rejecting replacement" tx broadcast error
We occasionally will attempt to broadcast transactions which conflicting
with mempool transactions which are marked RBF. If we don't have a
higher fee, we'll get a "rejecting replacement" error, which should not
cause a panic.