Meeting Minutes 4
===

###### tags: `BDK Core` `Meeting`

:::info
- **Location:** Online
- **Date:** Oct 21, 2022 09:00 AM (UTC)
- **Agenda**
- Weekly standup
- Change to floating points for feerate calculations?
- Integrating `bdk_core` into `bdk`
- Testing
- **Participants:**
- Evan (@evanlinjin)
- Daniela (@danielabrozzoni)
- Lloyd (@LLFourn)
- Raj (@rajarshimaitra)
- Vlad (@vlad_kwasi)
- **Reference:**
- [Project board](https://github.com/users/LLFourn/projects/2/views/1)
- [Last meeting](https://hackmd.io/@evanlinjin/bdk_core_20221014)
:::

:timer_clock: Minutes
--
- Evan
- Sparsechain
- Just refinement and testing.
- LL
- Coin selection
- Cool results
- Need to try in BDK
- Alekos & Daniela
- Planning module
- A: Add API for deciding which branch you want to tak
- Daniela is testing the planning module
- Ready to open PR soon
- No floating points for feerate?
- Lloyd is okay with fp (defer this decision).
- Alekos is okay to defer too
- Convo with Matt, Alekos reckons fp has better approximation. Fp is not "deterministic" between arch (security problem?) - Is fp deterministic in rust?.
- L: We can reduce fp operations to avoid drift.
- A: bitcoin core: uses sat/kvb
- L: Avoid APIs that make users work with fp + feerate calc (as it's easy to scew up).
- Integrating `bdk_core` into `bdk`
- L: No such thing as `bdk_core`. Just interfaces we need to build flexible wallet?
- 3 creates, minimal, low dependency, and re-approaching bdk with these tools.
- Key components/modules (to be completely separate from each other):
- syncing with sparsechain
- miniscript planning modules
- coin selection
- A: The more we split up, the better. Lots of projects want to use BDK, but can't because old BDK was too coupled. :clap:
- R: Requirements for different projects are different. Low dependencies is great.
- L: `bdk_core` is now a thought experiment only. Make `bdk` into separate, decoupled modules. Some modules will have more dependencies than others.
- Testing
- R: Basic structure is done, can do testing.
- R: 3 ways of syncing RPC, different examples.
- R: Persistance.
- A: Does it make sense to set threshold for coverage? E.g. esplora/rpc will be tricky (relax requirements). For cs/planning -> set a threshold (otherwise we may forget later on).
- A: Talk to LDK guys -> switch to our logic since we have all these testing modules.
- R: Can enforce coverage for unit tests. Functional tests are harder?
- L/A: Testing crates individually first. Different threshold has it's own threshold.
- A: Rust ecosystem, coin coverage are very precise, not only line-based but also checks statements and branches.
- D: Start with what we have in BDK (since it works pretty good already).
- L: Prop testing/fuzz testing (does wonders for finding bugs). Select rand inputs and find one that fails, find minimal inputs that fails (can debug from there or write unit tests).
- A: Fuzzers are weird to run. Prop test seems better and self-contained.
- L: Before testing, we should write examples. This way we can get the APIs right.
- Each examples should be self-contained.
- Each example should be it's own binary.
- But we can share utility stuff between examples.
- License of `bdk`
- Vendoring: "copy-paste-able".
- CC0 license.
- Since `bdk` in the future will be very modular, it makes sense to change license to CC0 to make it more copy-pasteable. Also miniscript and rust-bitcoin ecosystem uses CC0.
- A: Will not be against it.
- Planning module.
- L: Planning module should contain satisfaction logic. This way it is simpler and harder to get wrong.
- A: It is working out pretty well because they have a trait... Instead of taking in a satisfier, they take in `AssetProvider`. They changed satisfier module.
- Don't use pk-hash, lol.

:closed_book: Tasks
--
- [ ] Daniela: Set up code coverage for `bdk_core` (use what we use in `bdk` for now).
- [ ] Find/suggest code coverage tool, that is precise, and works.
- [ ] Set coverage threshold, can be different for each crate.
- [ ] Raj: Design/build scaffolding for examples.