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.
An upcoming change will stop the BackgroundProcessor's thread upon drop.
Store the processor in a variable and explicitly stop it. Otherwise, the
thread would be stopped immediately after it is started.
Matt Corallo [Mon, 5 Jul 2021 02:34:33 +0000 (02:34 +0000)]
Do not panic if we fail to fund a channel
I saw this where a bitcoind was hung connecting a block, and while
we were waiting the peer refused the channel via an error message.
When bitcoind eventually returned, we paniced as the channel was
now gone.
Matt Corallo [Sat, 26 Jun 2021 17:21:33 +0000 (17:21 +0000)]
Use a reasonable target fee when opening channels
Bitcoin Core defaults to conservative fee estimation, which often
results in significant overtargeting on weekends. We also disable
RBF, here, though, with a comment describing how clients should
handle funding RBF.