<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
This PR restructures the bdk-cli codebase to move away from a monolithic handling model towards a modular architecture. The primary goal is to improve code readability, simplify the addition of new features, and decouple core logic into smaller modules.
Fixes #273
<!-- Describe the purpose of this PR, what's being adding and/or fixed -->
### Notes to the reviewers
While trying to achieve the above-stated goal, I took maximum care to avoid introducing new bugs. As a result, the existing execution logic was preserved as much as possible.
<!-- In this section you can include notes directed to the reviewers, like explaining why some parts
of the PR were done in a specific way -->
This PR introduces two new subdirectories under `src`:
- handlers: This contains all the subcommands' execution logic grouped logically according to the top-level commands. Modules include the `config`, `descriptor`, `key`, `offline`, `online` and `repl` modules. They each contain structures for the subcommand, execution logic, and implementation of the top-level enum.
- utils: This subdirectory contains helper functions used across the app. They are also grouped logically according to related functionality. So far, we have the descriptor-related module, the output that formats responses, and the `types` module that defines response structures.
**Other notable changes**
- main module is retained with added functionality of routing requests to the right module for execution.
- All client-related functionalities have been moved from various modules into the `client` module, and it defines the enum that holds all the available clients, as well as implements the functionalities such as broadcasting transactions and syncing operations.
- The `AppCommand` trait that defines how each subcommand should be structured and the `execute` method they should implement.
- The `AppContext` struct that holds the universal parameters that subcommands may need. Each subcommand's `execute` method accepts this struct and uses the params for its execution.
- The output module in the util subdirectory attempts to present a uniform presentation layer by having an output trait, the `FormatOutput` trait, which is implemented by all `types` presenting data response to the user.
- Collapsed the `wallet` subdirectory into the `persister` module that defines all structures and functionalities related to persistence.
- Introduced a type state pattern for the AppContext: To minimise runtime errors, the `Init`, `OfflineOperations` and `OnlineOperations` state structs were introduced, and AppContext is generic over these states. This moved the validation from runtime to compile time.
- Introduced `FormatOutput::write_out` and made it generic over the Write trait to allow for flexibility in testing
- Extracted all initialisation logic (database, config loading and persistence initialisation) into `runtime` module. Also, added the `RuntimeWallet` enum to return options of a persisted wallet and a standard non-persisted wallet. The WalletRuntime struct is a wrapper that determines the type of wallet needed and initialises it and handles loading of a wallet from config.
**Request-Response Cycle**
The following outlines how requests are handled and responses are generated after introducing changes to the structure:
1. When a user enters a set of commands, those commands are received and parsed by the Clap library into Rust structures, such as `CliOpts`, `WalletOpts`, and subcommands. This process takes place in the `commands` module.
2. The parsed request is then passed to the `main` module. The main module uses the `runtime` module to interpret the request and initialize any necessary resources (such as wallets, databases, and clients) needed to fulfill the request. It then routes the request to the appropriate handler for execution.
3. Once a particular handler receives the request along with all the required resources, it processes the specific command using the `AppContext` and prepares a response.
4. After processing is complete, the handler calls the `output` module to format the result, serialize it into JSON, and return it to the terminal.
## Changelog notice
- In the `key derive` subcommand, when printing help message, the clap arg for env=“PATH” often pull all system and displays all system paths. This has been changed to derivation_path I.e. env=“DERIVATION_PATH” to prevent clap from picking the system paths and rendering it
- Moved the wallet subdirectory that served as persister into the persister module
- Moved DatabaseType enum from commands module into persister module
- Removed the —pretty flag
<!-- Notice the release manager should include in the release tag message changelog -->
<!-- See https://keepachangelog.com/en/1.0.0/ for examples -->
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
This PR adds support for BIP353 payment instructions.
The following notable changes are done:
- Adding of an option `resolve_dns_recipient` which receives a Human Readable Name (HRN) and returns the associated address
- Modify the `create_tx` for it to support user specifying recipients as `HRN`.
### Notes to the reviewers
<!-- In this section you can include notes directed to the reviewers, like explaining why some parts
of the PR were done in a specific way -->
Here is a list of HRN that could be used to test the implementation:
- pay@dunxen.dev: Supports BOLT 12 Payment method only (CAUTION: mainnet)
- send.some@satsto.me: Supports BOLT 12 payment and On Chain (CAUTION: mainnet)
- Testing resolving: `bdk-cli -n testnet resolve_dns_recipient testnet@bitdevsyde.org`
- Testing create tx: `bdk-cli -n testnet wallet -w regtest_default_wallet create_tx --to "bcrt1qe497k549sgw9trzym50tdlegq3xx4apjqynjqm:1000" --to_dns "testnet@bitdevsyde.org:5000"`
## Changelog notice
<!-- Notice the release manager should include in the release tag message changelog -->
<!-- See https://keepachangelog.com/en/1.0.0/ for examples -->
- Add top level command `resolve_dns_recipient` to resolve the DNS payment instructions
- Add option `--to_dns` to `create_tx` command to allow sending to a Human Readable Name (HRN)
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
#### New Features:
* [ ] I've added tests for the new feature
* [ ] I've added docs for the new feature
* [ ] I've updated `CHANGELOG.md`
### Description
https://github.com/bitcoindevkit/bdk-cli/pull/230 needed to be merged for this to go through
Address https://github.com/bitcoindevkit/bdk-cli/issues/149 also follow up to #200
This PR adds persistance to existing async payjoin integration
This introduces neccessary database model and tables also add commad for resume to allow interrupted sessions to be continued also a particular session either send or receive.
A history commad to view payjoin history and status has been added
### Notes to the reviewers
Step to review this include making a payjoin transaction
Run a receiver to get a BIP21 URI then pass it to the sender as seen in docs https://github.com/bitcoindevkit/bdk-cli/blob/b9cf2acc5f10db46fa30777ff0910b8610a5fc33/README.md?plain=1#L121-L141
To test resumption, interrupt either side with Ctrl+C mid-session then run resume on that side to continue. A few scenarios worth covering: receiver resuming after interrupt and sender resuming after interrupt. Use history after each scenario to confirm the session state was persisted correctly.
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
#### New Features:
* [x] I've added docs for the new feature
Mshehu5 [Sun, 28 Jun 2026 16:01:25 +0000 (17:01 +0100)]
Retry Payjoin requests with other relays
Payjoin currently keeps using the relay selected during OHTTP key
bootstrapping. If that relay goes offline, the session fails even when
other relay URLs were supplied.
Select from the available relays for each OHTTP request and remember
failures for the rest of the command. Build a fresh request for every
attempt so failover does not reuse linkable OHTTP ciphertext.
chore(deps): Bump payjoin and enable reqwest rustls
Move to payjoin 0.25.0 to stay closer to the latest release.
Enable rustls for the direct reqwest client because Payjoin
polling uses bdk-cli's own HTTPS client and without a TLS
backend the first relay poll fails.
Refine the skipped monitoring status message for the receiver
flow.
Mshehu5 [Mon, 16 Feb 2026 13:51:18 +0000 (14:51 +0100)]
Document payjoin recovery commands and SQLite setup
Update the README to cover the new `resume` and `history` commands
so users can recover interrupted payjoin sessions and inspect saved
session state. Also add the SQLite dependency needed for the
payjoin persistence workflow.
This keeps the user-facing setup and command documentation aligned
with the new persistence and recovery behavior.
Mshehu5 [Mon, 16 Feb 2026 13:50:06 +0000 (14:50 +0100)]
Add commands to resume and view payjoin history
Expose persisted payjoin session state through CLI commands so users
can recover interrupted sessions and review prior session progress.
Add `resume` to continue pending sender and receiver sessions,
`history` to list saved sessions, status text helpers for clearer
output, and session ID filtering to target a specific session.
This improves recovery and troubleshooting for long-running async
payjoin flows by making persisted session state available from the
CLI.
Mshehu5 [Mon, 16 Feb 2026 13:48:33 +0000 (14:48 +0100)]
Integrate payjoin session persistence into workflow
Wire the payjoin persistence layer into the existing send and receive
flows so session state is saved during normal operation and can be
replayed later. Initialize the database from the handlers, replace
the noop persisters with SQLite-backed persisters, resume existing
sessions, and record seen inputs in the receiver flow for replay
protection.
This moves persistence from a standalone storage layer into the
runtime payjoin workflow so interrupted sessions can continue from
saved state instead of starting over. It also simplifies error
handling by relying on `?` once the storage errors map cleanly into
the CLI error type.
Mshehu5 [Mon, 16 Feb 2026 13:31:08 +0000 (14:31 +0100)]
Add SQLite backing store for payjoin sessions
Persist payjoin sender and receiver state in SQLite so interrupted
payjoin sessions can be resumed after the CLI exits. Add dedicated
tables for send and receive sessions, append-only event logs for
state replay, receiver pubkey lookup for sender sessions, and
seen-input tracking for replay protection.
This follows the intended async payjoin design by persisting session
state across interruptions. SQLite keeps the initial persistence
backend simple and builds on existing rusqlite support, at the cost
of a small payjoin-specific schema and serialization layer.
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
This PR updates the Wallet API to v2.4.0 and other dependencies. It also adds WalletEvent to both sync and full_scan for all backends.
Fixes #243
<!-- Describe the purpose of this PR, what's being adding and/or fixed -->
## Changelog notice
- Update bdk_wallet to v2.4.0
- Add WalletEvents to all backends Esplora, Electrum, Rpc and CBF.
- Add `print_wallet_events` function to print wallet events to the terminal during sync
- Update bdk_bitcoind_rpc to v0.22.0
- Update bdk_electrum to v0.24.0
- Update bdk_kyoto to v0.15.4
- Update bdk_esplora to v0.22.2
<!-- Notice the release manager should include in the release tag message changelog -->
<!-- See https://keepachangelog.com/en/1.0.0/ for examples -->
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
Previously, passing multiple `--to` arguments with `--send_all` would silently drain the wallet to only the first recipient, ignoring the rest. This was inconsistent with the silent-payments `create_tx`, which already validates the recipient count.
Now returns an error unless exactly one recipient is provided.
### Notes to the reviewers
- The fix mirrors the validation logic already present in the silent-payments `create_tx` branch of the same file, so behavior is now consistent between the two code paths.
## Changelog notice
- Fixed create_tx --send_all to reject multiple recipients instead of silently using only the first one
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
* [x] I've updated `CHANGELOG.md`
#### Bugfixes:
* [ ] This pull request breaks the existing API
* [ ] I've added tests to reproduce the issue which are now passing
* [x] I'm linking the issue being fixed by this PR
Implements randomization of the unspendable internal key for taproot descriptors. This is the first part of #218, which consists of two parts:
1. **This PR**: Randomize unspendable internal key for taproot descriptor
2. **Follow-up**: Add verification command to ensure internal key is derived from NUMS key
Split into separate PRs for easier review and iteration, and to allow independent discussion of the verification command implementation, as one of the possible approaches could introduce breaking changes.
### Notes to the reviewers
The `compile` command now returns an additional `r` field for taproot descriptors (`-t tr`), containing the randomly generated internal key. Each compilation will produce a different internal key instead of using a fixed NUMS key.
Other descriptor types remain unchanged:
```
-> % bdk-cli compile "pk(A)" -t sh
{
"descriptor": "sh(pk(A))#k80zhe7s"
}
```
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
#### New Features:
* [x] I've added tests for the new feature
* [ ] I've added docs for the new feature
* [ ] I've updated `CHANGELOG.md`
Artemiy [Sun, 21 Jun 2026 07:11:17 +0000 (10:11 +0300)]
fix(create_tx): enforce single recipient for send_all
Previously, passing multiple --to arguments with --send_all would
silently drain the wallet to only the first recipient, ignoring the
rest. This was inconsistent with the silent-payments create_tx, which
already validates the recipient count.
Now returns an error unless exactly one recipient is provided
Vihiga Tyonum [Mon, 22 Jun 2026 15:07:28 +0000 (16:07 +0100)]
refactor(runtime): Add address and createtx to db
- Add new address, unused address and createtx
commands to list of commands that require
loading existing db
- adding persisting changes in offline and online
commands
Vihiga Tyonum [Fri, 29 May 2026 03:17:56 +0000 (04:17 +0100)]
Refactor(handlers): Define app context states
- Define Init state for when an execution does
not need either the wallet or client for execution
- Define the Offline wallet operations state
for app context when an execution envt needs
a wallet
- Define the online wallet operations state for
appcontext when an execution needs both the
wallet and client
- make app context generic over the state
- make the app command and async app command
generic over the execution context
- deleted shorten fn as it was applicable to the
pretty flag
- removed tests for pretty flag
Vadim Anufriev [Tue, 24 Mar 2026 20:12:30 +0000 (00:12 +0400)]
refactor(compile): lazy compilation and use pipe for readability
Move miniscript compilation inside match arms to avoid compiling
for all script contexts when only one is needed. Use `tap::Pipe`
for concise method chaining in sh/wsh/sh-wsh branches.
Vadim Anufriev [Tue, 24 Mar 2026 17:59:39 +0000 (21:59 +0400)]
feat(compile): randomize unspendable internal key for taproot descriptor
Instead of using a fixed NUMS key as the internal key for taproot
descriptors, generate a randomized unspendable key (H + rG) for each
compilation. This improves privacy by preventing observers from
determining whether key path spending is disabled.
The randomness factor `r` is included in the output so the user can
verify that the internal key is derived from the NUMS point.
Also applies `shorten()` globally in pretty mode and uses `?` operator
via dedicated error variants instead of `map_err`.
Tests verify descriptor structure and `r` field uniqueness across
randomized compilations.
Vadim Anufriev [Tue, 24 Mar 2026 17:43:08 +0000 (21:43 +0400)]
chore(deps): make shlex a non-optional dependency
Although not directly related to this PR's changes, during review
we agreed to make shlex non-optional since it's used by the default
`repl` feature and the package is under 20 KiB.
This PR adds experimental support for creating silent payment transactions through a new `CreateSpTx` command. The implementation integrates the `bdk_sp` crate to enable sending Bitcoin to silent payment addresses.
Key changes:
- Adds `bdk_sp` dependency as an optional feature
- Implements `CreateSpTx` command with support for silent payment recipients
- Includes parser for silent payment `address:amount` pairs
- Returns signed transactions ready for broadcast (not PSBTs due to silent payment derivation constraints)
**Notes to the reviewers**
- This feature is marked as **EXPERIMENTAL** and includes warnings against mainnet use
- The command returns signed transactions directly rather than PSBTs because silent payment script pubkey derivation cannot be performed securely in a trustless manner with standard PSBT workflows
- RBF is disabled for silent payment transactions (sequence set to MAX)
- The implementation handles both single key and extended key signers
- Error handling uses temporary `.expect()` calls that should be addressed in future iterations
* [x] I've signed all my commits
* [x] I followed the [conventional commit guidelines](https://www.conventionalcommits.org/en/v1.0.0/)
* [x] I ran cargo fmt, clippy and test before committing
**New Features**
~~* [ ] I've added tests for the new feature~~
* [x] I've added docs for the new feature
nymius [Wed, 20 Aug 2025 16:42:12 +0000 (13:42 -0300)]
feat(silentpayments): add experimental silent-payments sending support
- Adds CreateSpTx command to create transactions with silent payment
outputs: this command creates signed transactions directly rather than
PSBTs due to current limitations in secure shared derivation.
It supports mixed recipients: regular addresses + silent payments.
It DOES NOT support RBF for the created transactions.
It generates signed transactions ready for broadcasting.
- Adds SilentPaymentCode command to create silent payment codes from
public keys and network: the silent payment code generated is
independent from any of the other stateful features of bdk-cli.
This command is mainly intended for experimental use, do not lock any
funds to the generated code if you don't know what you are doing and
don't have the keys matching the public keys used.
- Adds bdk_sp dependency with "silent-payments" feature flag.
- Adds silent payment recipient parsing utility.
- Add README section for new silent payment commands.
Note: This is experimental functionality for testing only, not
recommended for mainnet use.
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
This PR added [BIP322](https://bips.xyz/322) feature into BDK CLI.
It also has a usage file for testing purposes
### Notes to the reviewers
<!-- In this section you can include notes directed to the reviewers, like explaining why some parts
of the PR were done in a specific way -->
## Changelog notice
<!-- Notice the release manager should include in the release tag message changelog -->
<!-- See https://keepachangelog.com/en/1.0.0/ for examples -->
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
#### New Features:
* [x] I've added docs for the new feature
* [x] I've updated `CHANGELOG.md`
Update transitive dependency `rand` from 0.9.2 to 0.9.3 via `cargo update -p rand@0.9.2` to resolve RUSTSEC-2026-0097.
Note: #268 (`rand 0.8.5` via `secp256k1` and others) remains unaffected by this change and needs to be fixed upstream.
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
This PR bumps the crate version to 3.0.0
Closes #257
<!-- Describe the purpose of this PR, what's being adding and/or fixed -->
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
This PR updates transitive dependencies `quinn-proto` and `aws-lc-sys` to fix identified vulnerabilities.
Other `aws-lc-sys` linked vulnerabilities fixed by this update include:
- AWS-LC has Timing Side-Channel in AES-CCM Tag Verification
- AWS-LC has PKCS7_verify Signature Validation Bypass
- CRLs not considered authorative by Distribution Point due to faulty matching logic in `rustls-webpki` v0.103.8
This PR also update:
- clap to v4.6
- clap_complete to v4.6
- env_logger to v0.11.10
- thiserror to v2.0.18
- tracing to v0.1.44
- toml to v1.1.0
- bdk_electrum to v0.23.2
- bdk_kyoto to v0.15.4
- bdk_redb to v0.1.1
- reqwest to v0.13.2
- url to v2.5.8
Fixes #249, #250, #258, #259, #260, #261, #262 and #264
<!-- Describe the purpose of this PR, what's being adding and/or fixed -->
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
Vihiga Tyonum [Wed, 25 Mar 2026 05:34:44 +0000 (06:34 +0100)]
chore: update project deps
This PR also update:
- clap to v4.6
- clap_complete to v4.6
- env_logger to v0.11.10
- thiserror to v2.0.18
- tracing to v0.1.44
- toml to v1.1.0
- bdk_electrum to v0.23.2
- bdk_kyoto to v0.15.4
- bdk_redb to v0.1.1
- reqwest to v0.13.2
- url to v2.5.8
See how to install completions for your shell:
```bash
bdk-cli completions --help
```
For example, to install completions for zsh:
```bash
bdk-cli completions zsh > ~/.zfunc/_bdk-cli
```
After restarting the shell, completions should work with Tab.
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
#### New Features:
* [ ] I've added tests for the new feature
* [x] I've added docs for the new feature
* [x] I've updated `CHANGELOG.md`
As pointed out in issue #255, whenever Esplora was configured out, the config test will fail because Esplora was used as the client.
This fix addresses the above issue by adding other client types in the test.
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
Fixes #255
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
#### Bugfixes:
* [ ] This pull request breaks the existing API
* [x] I've added tests to reproduce the issue which are now passing
* [x] I'm linking the issue being fixed by this PR
I noticed that we still have mentions of MSRV, despite the fact that MSRV was removed in #211.
In this PR I'm removing the found mentions.
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
Cargo's version resolution always updates to the latest patch version. If that patch introduces breaking changes, it breaks your application.
This happened after Payjoin released version 1.0.0-rc.2. Because the version specified for bdk-cli was 1.0.0-rc.1, a fresh install automatically updated to the newer patch.
To resolve this without migrating to the latest Payjoin API, and to prevent future breakages from subsequent 1.0.0-rc.x releases, this commit pins the Payjoin version strictly to =1.0.0-rc.1.
This happened before in another project: rust-bitcoin/rust-bitcoin#5358
**Changelog notice**
```text
fix: enforce `1.0.0-rc.1` payjoin version and avoid automatic patch updates
```
A missing slash was preventing the `receive_payjoin` command from displaying its documentation string:
```bash
Wallet operations.
...
sync Syncs with the chosen blockchain server
broadcast Broadcasts a transaction to the network. Takes either a raw transaction or a PSBT to extract
receive_payjoin
send_payjoin Sends an original PSBT to a BIP 21 URI and broadcasts the returned Payjoin PSBT
new_address Get a new external address
...
```
This change adds the additional slash to make a proper doc string, so clap displays it.
nymius [Tue, 17 Mar 2026 14:15:48 +0000 (11:15 -0300)]
fix(dependencies): change payjoin version specifier `1.0.0-rc.1` to `=1.0.0-rc.1`
Cargo's version resolution always updates to the latest patch version.
If that patch introduces breaking changes, it breaks your application.
This happened after Payjoin released version 1.0.0-rc.2. Because the
version specified for bdk-cli was 1.0.0-rc.1, a fresh install
automatically updated to the newer patch.
To resolve this without migrating to the latest Payjoin API, and to
prevent future breakages from subsequent 1.0.0-rc.x releases, this
commit pins the Payjoin version strictly to =1.0.0-rc.1.
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
This PR updates the code_coverage workflow by replacing the Coveralls code coverage reports with codecov. It also updates the checkout, rust-lang toolchain setup actions.
Fixes #245
<!-- Describe the purpose of this PR, what's being adding and/or fixed -->
### Notes to the reviewers
<!-- In this section you can include notes directed to the reviewers, like explaining why some parts
of the PR were done in a specific way -->
## Changelog notice
<!-- Notice the release manager should include in the release tag message changelog -->
<!-- See https://keepachangelog.com/en/1.0.0/ for examples -->
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### Description
This is a continuation of #221
<!-- Describe the purpose of this PR, what's being adding and/or fixed -->
### Notes to the reviewers
<!-- In this section you can include notes directed to the reviewers, like explaining why some parts
of the PR were done in a specific way -->
- Update the stated `bdk_wallet` to 2.x.x
- Addressed review comments on #221
## Changelog notice
<!-- Notice the release manager should include in the release tag message changelog -->
<!-- See https://keepachangelog.com/en/1.0.0/ for examples -->
### Checklists
#### All Submissions:
* [x] I've signed all my commits
* [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk-cli/blob/master/CONTRIBUTING.md)
* [x] I ran `cargo fmt` and `cargo clippy` before committing
projects / bdk-cli / log