---
# System prepended metadata

title: Meeting Minutes 2
tags: [Meeting, BDK Core]

---

Meeting Minutes 2
===

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

:::info
- **Location:** Online
- **Date:** Oct 7, 2022 09:00 AM (UTC)
- **Agenda**
    - Plan for the miniscript planning module.
    - Standup.
    - Did Alekos have time to look into `BnbIter` improvements.
- **Participants:**
    - Evan (@evanlinjin)
    - Alekos (@afilini)
    - Daniela (@danielabrozzoni)
    - Llyod (@LLFourn)
- **Reference:** 
    - [Last meeting (Wednesday)](https://hackmd.io/@evanlinjin/bdk_minutes_20221005)

:::

:timer_clock: Minutes
--

**Planning Module**
- How do you satisfy a descriptor?
- A plan means one specific way to satisfy.
- With a plan, you can figure out weight of satisfaction.
- With a plan, you can figure out the "best way" to complete a psbt.
- Use it as a satisfier? (like a signer?).

**How to get a plan?**
- (descriptor + assets) -> plan
- Otherwise, we can choose a specific branch.
- Assets: keys, values and constraints.
- Constraint ideas:
    - "at most": I am willing to wait up to 100 blocks
    - "at least": I should wait at least 100 blocks
- Alekos suggests two APIs:
    - One for `(descriptor + assets) -> plan`
    - One for `(descriptor + branch + assets) -> plan`
- Lloyd suggests:
    - At each disjunction, give the user two plans (sub plans), what could be used. Witness template items. What things on lefthand side, what things on righthand side. Make a decision here. There will be no traversial for the user.
    - So each disjunction, we call a callback for the above.
- Alekos' counter argument:
    - Not always a binary choice. We could still do something similar, but would this make it too low level?
    - Leave the "at least" and "at most" in would be simpler?
- Use it as a satisfier?
    - I have these sigs so far, and the plan will say, this is what is missing.
    - Generic marker to say whether plan is complete or non-complete.
    - ~~The current satisfier fn... You can implement the same logic with a plan? We can actually legasize "satisfier", or use "plan" as a low level module for "satisfier".~~ (This seems wacky, this is awkward actually).
    - We can think about this later.
- What is the actual API of "assets"?
    - No trait for Assets structure (container for keys, preimages).
    - Trait to fill up the assets? Like `extend` method, turn anything into an iterator?
    - PSBT -> Assets, merge with other assets.
    - Lloyd has `keys -> can derive?`. This cannot be a boolean. "This asset could derive this thing". This should return a derivation path like a hint. "How do you get the actual key from the asset key".
    - Having individual keys is a mistake because if we have a hint, we can do it.
    - Looking through descriptor branch, compare it with an asset, output a derivation path of how to actually derive from the asset.
    - Alekos moved away from this. It is nice to return a vector of what is missing?
    - Incomplete -> The hashes that do not have preimages yet. The keys that are not signed for. Plan will remember the "hint/advice" for each asset key.
- Could we make a plan from a string descriptor?
    - Partial API? Can look at weights of things.

**BnbIter:**
- Alekos abandoned it?
- So you can have "default strategy" and "default scorer".
- Lloyd will handle it.
- Score can decide branching?

:closed_book: Tasks
--
- Alekos and Daniela will continue with miniscript plan.
- Evan will work with Lloyd early on in the week together to "kick start" Evan on sparse chain. Then Lloyd will look into how to refine coin selector and bnb.