Feat: v0.7.0 rc.0 #84
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Other messages like on-chain wallet sync or fee rate cache update logged with info level
.. which we forgot when we made the change.
Update `main` post-0.6.1 release
…o-rgs Log background sync of RGS message with info level
The `log!()` macro defaults to using the module path as the log target when no target is specified. Explicitly setting the log target to the module path enables better integration with other logging crates, such as `env_logger`, allowing them to filter logs by target (e.g., via `env_logger::Builder::parse_filters()`).
…-target Set log target to module path
Previously, chain synchronization failures would retry immediately without any delay, which could lead to tight retry loops and high CPU usage during failures. This change introduces exponential backoff for transient errors, starting at 2 seconds and doubling each time up to a maximum of 300 seconds. Persistent errors also now delay retries by the maximum backoff duration to prevent rapid loops while maintaining eventual recovery. Fixes lightningdevkit#587
Implement Exponential Backoff for Transient Sync Errors
Fix CLN crash by waiting for block height sync before channel open
Since we unify RPC and REST sync clients in the following commit, we rename bitcoind_rpc to bitcoind as this appropriately captures the unified client.
In the next commit, we'll introduce a unified bitcoind client with two variant - RPC and REST. In preparation to support chain syncing via the REST interface, we refactor some methods into helper functions specific to the interface client.
This commit: - Adds support for syncing data via Bitcoin Core's REST interface. - Unifies the REST and RPC Bitcoin Core API clients
…est-sync-v2 feat: chain source rest sync
We bump our `uniffi` dependency to v0.28.3 to unlock some of the nicer features `uniffi` added since the previously-used v0.27.3. However, we can't bump it further to v0.29.3, as we have users requiring compatibility with `uniffi-bindgen-go`, which only supports v0.28.3 at the time of writing.
…ffi-0.28 Bump `uniffi` dependency to v0.28.3
Previously, we had to configure enormous syncing timeouts as the BDK wallet syncing would hold a central mutex that could lead to large parts of event handling and syncing locking up. Here, we drop the configured timeouts considerably across the board, since such huge values are hopefully not required anymore.
Previously, we used to a channel to indicate that the background processor task has been stopped. Here, we rather just await the task's `JoinHandle` which is more robust in that it avoids a race condition.
.. we provide finer-grained logging after each step of `stop`.
…wn-more-robust Make shutdown procedure more robust
update to Gradle 9.0 and auto-extract version number.
…tegration-ci ci(vss): auto-extract Gradle version number ffg upgrade
This is useful if the esplora server has a form of authentication in front of it
Add option to include headers in Esplora config
We introduce a new `ChainSourceKind` that is held as a field by `ChainSource`, which better encapsulates the chain syncing logic, and in future commits allows us to move some common fields to `ChainSource`.
.. in the hopes of making the git diff more readable going forward, we break up the `ChainSource` impl block.
We refactor our `ChainSource` logic and move out the Esplora code into a new object.
Previously, we couldn't poll the chain tip in `Builder::build` as we wouldn't have a runtime available. Since we now do, we can at least attempt to poll for the chain tip before initializing objects, avoiding that fresh nodes need to re-validate everything from genesis.
…-init `bitcoind` chain source: Poll tip before intialization
Support generating BIP39 mnemonics with configurable word counts (12, 15, 18, 21, 24). Defaults to 24 words (256-bit entropy) for backward compatibility. - Add WordCount enum (12–24 variants) - Update generate_entropy_mnemonic to accept optional word_count - Remove need for entropy_bytes in generate_entropy_mnemonic by passing WordCount enum directly to generate() instead - Add rand feature to bip39 dependency - Extend tests for all word count options and defaults - Expose enum and updated function in UDL bindings
…urable-mnemonic-word-count Add support for configurable BIP39 mnemonic word counts
When a channel is spliced, the existing funding transaction's output is spent and a new funding transaction output is formed. Once the splice is considered locked by both parties, LDK will emit a ChannelReady event which will include the new funding_txo. Additionally, the initial ChannelReady event now includes the original funding_txo. Include this data in LDK Node's ChannelReady event.
LDK introduced similar events with splicing. SplicePending is largely informational like ChannelPending. SpliceFailed indicates the used UTXOs can be reclaimed. This requires UTXO locking, which is not yet implemented.
When the interactive-tx construction protocol completes in LDK during splicing (and in the future dual-funding), LDK Node must provide signatures for any non-shared inputs belonging to its on-chain wallet. This commit implements this when handling the corresponding FundingTransactionReadyForSigning event.
Extract the funds availability checking logic from open_channel_inner into a separate method so that it can be reused for channel splicing.
Instead of closing and re-opening a channel when outbound liquidity is exhausted, splicing allows to adding more funds (splice-in) while keeping the channel operational. This commit implements splice-in using funds from the BDK on-chain wallet.
Instead of closing and re-opening a channel when on-chain funds are needed, splicing allows removing funds (splice-out) while keeping the channel operational. This commit implements splice-out sending funds to a user-provided on-chain address.
Since LDK Node does not support downgrades, there's no need to have a Config parameter for accepting inbound splices. Instead, enable it by default.
Previously the docs have been a bit sparse. Now that we actually implement the client-trusts-LSP flow, we should expand a bit on what the bool actually does.
Channel splicing support
…nt-trust-lsp-docs Expand docs on `LSPS2ServiceConfig::client_trusts_lsp` field
Add draft changelog for LDK Node v0.7.0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TODOs:
panicif unexpected namespace is listed)