Matt Corallo [Mon, 14 Oct 2024 02:03:54 +0000 (02:03 +0000)]
Use `Balance`s to calculate balances instead of `ChannelDetails`
LDK has deprecated the `ChannelDetails` balance retrieval because
its generally not what users want. Instead, we use the
`ChainMonitor` `Balance` list.
Elias Rohrer [Fri, 8 Mar 2024 13:32:39 +0000 (14:32 +0100)]
Generate random `PaymentId` for outbound offers
Previously, we'd deterministically derive the `offer_hash` as a
`PaymentId` for outbound BOLT 12 payments. However, as offers may be
paid multiple times, this could result in collisions in our
`outbound_payments` store.
Here, we therefore use random `PaymentId`s to avoid collisions, even if
offers are paid multiple times.
Matt Corallo [Tue, 22 Aug 2023 20:59:23 +0000 (20:59 +0000)]
Dont block tokio reactor waiting on user input
When we moved the CLI input reading into a `tokio::select`, we
ended up blocking the tokio reactor by reading from stdin in a
standard tokio future. Instead, we need to let tokio know that
we're running a largely-blocking task.
Matt Corallo [Sun, 13 Aug 2023 22:40:25 +0000 (22:40 +0000)]
Attempt a last-ditch ChannelManager persistence if the BP exits
If the BP exits because it failed to write our ChannelManager to
disk, we'll probably lose some channels on startup. However,
there's still some chance for us to write the `ChannelManager` in a
retry, which we should do before we exit.
Matt Corallo [Sun, 7 May 2023 18:12:20 +0000 (18:12 +0000)]
Try to sweep `SpendableOutputs` regularly, and in bulk
Rather than trying to sweep `SpendableOutputs` every time we see
one, try to sweep them in bulk once an hour. Then, try to sweep
them repeatedly every hour forever, even after they're claimed.
Matt Corallo [Mon, 24 Apr 2023 03:21:42 +0000 (03:21 +0000)]
Switch to using the async background processor
This drops a full thread from the sample node and better integrates
LDK into the tokio runtime. While we're at it we also push the
`Event` being processed by move into the event handler, which
doesn't matter much here but makes further modification in the
event handling somewhat simpler.
Matt Corallo [Sun, 23 Apr 2023 17:03:57 +0000 (17:03 +0000)]
Drop `futures` dependency with `tokio::select`
Manually poll'ing a future every 10ms rather than selecting across
it and a timer is less effecient, and certainly not worth taking a
dependency to do.
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.
projects / ldk-sample / log