Thomas Eizinger

The commit log is a bit of a mess because of the squash merging that I did but the final diff is correct :D

> This is a pure refactor, right? Yes this is a pure refactor. The primary change is that we have only one `ReceiveFuture` now which is part of the public...

There is https://github.com/cloudhead/nakamoto which should help implementing this.

This doesn't quite work unfortunately. The point of `[patch]` is to replace dependencies across the entire dependency graph **without** changing the `[dependencies]` table. In my case, `bdk` is also a...

> I would have expected `0.14.1-dev` to be compatible with `0.14` in the dependency's `Cargo.toml`. Then cargo should use it after `cargo update`. From the [spec](https://semver.org/#spec-item-11): > A pre-release version...

Yes, I've longed for a more "brutal" `[patch]` behaviour myself several times but it is unfortunately fairly restrictive :/

I just ran into this while using `bdk::Wallet` within an actor framework. I have one actor had controls access to the wallet and thus, the wallet itself does not need...

> I think a better solution is to just remove interior mutability from Wallet (i.e. remove RefCell) and make &self mutable in methods like `sync`. I would also advocate for...

Is making the DB thread-safe going to make the entire wallet thread-safe? Because if not, then why bother with internal mutability when users need to wrap it in a Mutex...

An alternative design could be to decouple the wallet and the database from each other. A call to `sync` could: - Require a `SyncStatus` struct as a parameter that can...