Daniela Brozzoni

Hey, we are in the process of releasing BDK 1.0, which will under the hood work quite differently from the current BDK. For this reason, I'm closing all the PRs...

I agree with José here, although `allowed_empty_history_count` would let us avoid the problem with `stop_gap` = 0, I don't think it's worth it to re-invent the wheel and introduce a...

> I'll argue that allowed_empty_count is not a difficult concept to understand You're right that it's not difficult to understand, but it's yet another thing to find out and learn...

> I would agree if we didn't already return a result, but since we do, it's probably not so bad to add a new error variant. Gosh, I just realized...

Hey @evanlinjin and @LLFourn, thanks a lot for your reviews. I've given some thoughts about them: 1. I agree that having a BTreeMap with everything inside is not optimal, and...

@LLFourn @evanlinjin do you think it's ok if `KeychainTxOutIndex::keychains` returns a `BTreeMap` instead of `&BTreeMap`? The thing is, after refactoring the `KeychainTxOutIndex`, I don't have a `keychain -> desc` map...

@evanlinjin I see how Iter is better than BTreeMap since you don't need to collect, but why returning `K` instead of `&K`?

Pushed an update. It still needs a rebase, but while I work on it, can you let me know what you think?

In my last push: - Rebase on master - Fix (almost all the) review comments - I'm still missing a couple, will take a look soon - `revealed_keychain_spks`, `unused_keychain_spks` `keychain_outpoints_in_range`...

@ValuedMammal I agree, but it seems to me that there aren't many methods in bdk_chain that return `Result`, and this seems a deliberate design choice? Also, "having an error-free API"...