Lloyd Fournier

I've changed my thinking on this topic. After working with various database APIs they are not at all consistent about why they need to be `&mut` or not. For example,...

> 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...

@thomaseizinger thanks for thinking more deeply about this problem. Here's the issue with your suggestion: > However, the benefits would be that the wallet does not care whether or not...

Ok so I will paint my grand vision of how this should go: 1. We separate the `Blockchain` traits into separate synchronous and asynchronous versions e.g. under `bdk::async`. The `async`...

Just wanted to second what @thomaseizinger said. One of the main goals of this refactoring is to remove all this `maybe_async` stuff and `await_or_block` etc so the features are additive....

> The same is true for secp256kfun but I don't know how independent that implementation is. (cc @LLFourn) The best rust impl to try this approach for would be [k256](https://docs.rs/k256)...

> > The best rust impl to try this approach for would be [k256](https://docs.rs/k256) since it is a completely independent code base and even uses different algorithms for ECC (it...

> This is only correct if we are considering a transaction as a whole (as per [BIP-0141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#transaction-size-calculations)) > > However, many times we are converting from wu to vb for...

> The TL;DR is that attackers have a very good multiplier for locking up liquidity on target nodes (with N sats, the attacker is able to lock M sats of...

> Payment routing is a very thin margin business. If it ever becomes profitable, I don't think it will yield big returns. So denying activity to one of your competitors...