志宇
志宇
> Thanks for tackling this @evanlinjin It was mostly @ValuedMammal! I only reviewed and merged 😅
I think this is a good to have. However, it is not critical for 1.0.0. I'll push it back. However, if someone is super motivated to do this, I won't...
Builder pattern already introduced.
Let's do this after #1203. I'll take responsibility for the convoluted crate docs.
@notmandatory some serialization formats would not work with what's suggested (i.e. bincode) when the entire changeset is persisted. I think we should create a new type (i.e. `VersionedChangeSet`) which is...
To add some context to this conversation, I'll touch on all proposed future changes that will affect `ChangeSet` structures. ### Add another tx timestamp for when wallet created tx *...
Changes which only adds new fields are easily backwards and forwards compatible. Changes which change fields (monotone `LocalChain` changeset and adding metadata to `LocalChain`) are more problematic. For monotone `LocalChain`...
I think we should have the following: 1. Allow breaking backwards-compatibility for `bdk_chain` changesets. Otherwise for all `bdk_chain` changesets, we either need to keep the old fields (which would be...
@notmandatory one more breaking change here: https://github.com/bitcoindevkit/bdk/issues/1333 I would like more feedback on this. I'm also currently working on 1 & 2 (should have a PR ready tomorrow).
My bad, I see the issue seems to suggest reexporting. However, I don't think `Balance` belongs in the `keychain` module at all as it's not `keychain`-specific? cc. @danielabrozzoni