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.