Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chore: update to v0.3.0 #36

Merged
merged 67 commits into from
Jun 24, 2024
Merged

Chore: update to v0.3.0 #36

merged 67 commits into from
Jun 24, 2024

Conversation

rolznz
Copy link

@rolznz rolznz commented Jun 23, 2024

No description provided.

tnull added 30 commits May 20, 2024 13:40
…elease-notes

Update CHANGELOG for v0.2.2
We spawn a background task that will try to connect to any of the
provided socket addresses and return as soon as it suceeds.
.. depending on the payment purpose, we derive the inbound payment ID
and update the status in `PaymentClaimable`/`PaymentClaimed`
Pin `url` to v2.5.0 in CI to fix MSRV breakage
.. allowing to configure the per-channel emergency reserve as well as
some trusted peers for which we won't maintain any reserve.
When Anchor outputs need to be spent LDK will generate
`BumpTransactionEvent`s. Here, we add the corresponding event-handling
and PSBT-signing support.
.. because they will be the new default.

Note the upcoming CLN 24.02 release will make Anchors default, too, but
for now we have to set the `experimental-anchors` config option.
.. which we somehow so far ommitted exposing in the API.

We now introduce a `force_close` method and broadcast if the
counterparty is not trusted.
.. i.e., without bumping.
.. as we're about to expose a new `NetworkGraph` wrapper type.
Previously, we omitted exposing details for the sake of simplicity.
However, querying the network graph has a lot of utility, and is also
very useful for debugging purposes.

Here, we therefore give users access to the network graph, and expose
slightly simplified versions of `ChannelInfo`/`NodeInfo` in bindings.
Previously, LDK was very conservative and kept channel monitors around
~forever or until the user manually decided to prune them. Recently it
introduced the `ChainMonitor::archive_fully_resolved_monitors` method,
which we now call periodically: every time a wallet sync succeeds, we
check whether the latest archival height is 6 blocks in the past and
call `archive_fully_resolved_monitors`.

As this is not permanently persisted, we will always try to archive any
pruned monitors when the first background sync after fresh
initialization succeeds, ensuring we call it regularly also on
short-lived sessions, e.g, on mobile.
tnull and others added 26 commits June 18, 2024 09:37
…-on-startup

Log node ID in `start`/`stop`
... requiring users to manucally claim them.
.. we previously got reports from users trying to pay their own JIT
invoice, which we currently don't support (and possibly never will).

In order to avoid entering any weird states, we just reject our own
circular payment.
.. which allows to filter and sort payment based on how recent they are.
Unfortunately BDK's current wallet design requires us to have it live in `Mutex`
that is locked for long periods of time during syncing. This is
especially painful for short-lived operations that just operate locally,
such as retrieving the current balance, which we now do in several
places to be able to check Anchor channels limitations, e.g., in event
handling.

In order to avoid blocking during balance retrieval, we introduce a
`balance` cache that will be refreshed whenever we're done with syncing
*or* when we can successfully get the wallet lock. Otherwise, we'll just
return the cached value, allowing us to make progress even though a
background sync of the wallet might be in-progress.
Using a `Condvar` could be potentially dangerous in async contexts as
`wait`ing on it might block the current thread potentially hosting more
than one task. Here, we drop the `Condvar` and adopt a pub/sub scheme
instead, similar to the one we already implemented in
`ConnectionManager`.
It's not super clear that it achieves much in the face of a rate-limited
Esplora server, and having a custom sleep there is just awkward. So we
drop it and hope we still get a chance to sync our on-chain wallet now
and then.
.. as we're not sure it actually increases reliability.

We now only log failures, ignoring HTTP 400 as this is bitcoind's error
code for "transaction already in mempool".
.. to make progress and unblock the `Mutex` even if BDK's wallet `sync` would never return.
.. even though we don't expect this to block, we're better safe than
sorry and start to introduce timeouts for any calls we make to remote
servers.
.. even though we don't expect this to block, we're better safe than
sorry and start to introduce timeouts for any calls we make to remote
servers.
.. even though we don't expect this to block, we're better safe than
sorry and start to introduce timeouts for any calls we make to remote
servers.
.. before initiating the Runtime shutdown.
.. as we use `Clone` for `tokio::sync::watch::Sender`, which was only
introduced with 1.37.
…wallet-friction

Improve on (potentially) blocking wallet behaviors
@rolznz rolznz mentioned this pull request Jun 23, 2024
25 tasks
@rolznz
Copy link
Author

rolznz commented Jun 24, 2024

Tested here: getAlby/hub#47

@rolznz rolznz merged commit 6797574 into main Jun 24, 2024
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants