[Feature] Load BIP-85 Child Seeds

[Chaitanya-Keyal]

Description

Fixes: #354.

This PR introduces support for directly loading BIP-85 generated seeds into the UX.

• Adds SeedBIP85FinalizeView, with this updated flow in mind.
• Adds BIP85ChildSeed and refactors codebase to eliminate the need of passing around bip85_data.
• Discards child seeds if parent is discarded.
• Adds visual indicators on all list views to differentiate child seeds and understand hierarchy.

  Note: I initially wanted to use this icon instead of the plain arrow, but unfortunately it's a pro icon. Perhaps we could make a custom icon for this in the SeedSigner Font?

• Adds child seed info in SeedOptionsView.
• Adds a new setting option for BIP-85.

New Screenshots

Other minor changes:

• Rewords "Wipe" to "Discard" in SeedDiscardView.
• Makes the following SelectSeedViews consistent with other In-Memory Seeds views and use white for the fingerprint icon instead of blue.

TODO

• Settings Menu: Add a third option to enable BIP-85 seed generation and loading.
• Visual Indicators: Add metadata (e.g., parent fingerprint, child index) in SeedOptionsView and differentiate child seeds/show parent relationship in Seeds List Views.
• Tests, Screenshot Generator: Implement appropriate unit and integration tests, add screenshots.

---

This pull request is categorized as a:

• New feature

Checklist

• I’ve run pytest and made sure all unit tests pass before submitting the PR

If you modified or added functionality/workflow, did you add new unit tests?

• Yes

I have tested this PR on the following platforms/os:

• Raspberry Pi OS Manual Build

[kdmukai]

In the current draft, a child seed can generate its own bip85 child seeds. That is absolutely unacceptable to me and will need a check to prevent it.

[kdmukai]

Also definitely need the TODO bullet point you list in the description to differentiate the child seeds in the list of seeds loaded in memory.

[Chaitanya-Keyal]

Thanks for the review, Keith. I’ve completed all my remaining TODO items for this PR and incorporated all the changes you suggested. The PR description has been updated to reflect the new changes, and this is now ready for another review.

A couple of points for discussion:

• What do we think about the “button” I’ve used in the SeedOptionsView to display the child seed’s information?
• Is the current arrow icon (in seed list views) sufficient, or should we switch to the alternative icon I mentioned in the PR description? If we decide to switch, could I get some guidelines on how to add an icon to the SeedSigner font?

[kdmukai]

• What do we think about the “button” I’ve used in the SeedOptionsView to display the child seed’s information?

It being info only and not actually navigating anywhere is definitely a violation of our UX rules.

I think the parentage is well represented Seeds listing. So I think the SeedOptionsView title can just focus on what's unique to the child:

• "Child 14: abcd1234" (child's fingerprint)
• Or maybe just "14: abcdd1234" (child's fingerprint)

Then that info-only button isn't necessary anymore.

[kdmukai]

SeedSelectSeedView appends seeds and children as they're loaded (note: children DO correctly stay with their parent even when multiple seeds are loaded and children of different seeds).

But I wonder if the children should be sorted by their child index instead.

Seed A
 -> #13: abcd1234
 -> #5: abcd1234
 -> #423: abcd1234
Seed B
 -> #11: abcd1234
 -> #2: abcd1234

vs

Seed A
 -> #5: abcd1234
 -> #13: abcd1234
 -> #423: abcd1234
Seed B
 -> #2: abcd1234
 -> #11: abcd1234

[kdmukai]

I don't think altering the fingerprint color for child seeds is the best way to go. If there is any differentiation, maybe it should be via a custom icon designed by @easyuxd (see the "Finalize Child Seed" screenshot in the PR description). At the very least I'd leave it to Easy to weigh in on the color (stick with fingerprint blue or a diff alt color?).

The arrows in "Select Signer" and "Verify Address" should also be reviewed. I think the arrow icon itself is fine, though something more like ↳ shaped might be better. And I don't think it should be shaded blue in "Verify Address". In fact, it's probably an implementation miss that one screen renders the fingerprints in the buttons white while in the other it's blue.

Another thought: maybe the SeedOptionsView for a child (the "c1969012" screenshot) could replace the fingerprint icon with the big "#" icon and then add the child index number as I suggested above to give us: "#14: c1969012"

[Chaitanya-Keyal]

Thanks again, Keith. I’ve made all the suggested changes (also updated screenshots in the PR desc):

• Child seeds are now sorted by index
• The info-only button has been removed, and the SeedOptionsView title now includes the child index with the # icon

On the icons:

• I agree that the alternative arrow icon mentioned in the PR desc would be a better fit, though it would also need to be custom
• A custom icon for child seeds would be the ideal solution (for both SeedFinalizeView and SeedOptionsView). The current # works as a placeholder, but something more tailored would definitely look better

In the meantime, until Easy has time to design the new icons, I’m also open to reverting to the fingerprint icon for the SeedOptionsView and adjusting its color if needed.

[kdmukai]

This will be a bit of annoying fussing about, but I'd prefer that the various screenshots that show the in-memory seeds list (there are about 4-5) stay "clean" with no bip85 children in the list. The rationale is that we'll be constantly leveraging these screenshots for tutorials and other materials so we should always have a beginner-friendly "clean" screenshot. And then add in whatever more advanced feature screenshots / variants we might need (e.g. PSBTOverviewView_op_return).

So I would just create a single alternate version of "In-Memory Seeds" that includes a child. I'd place it just after SeedOptionsView_bip85_child_seed.

I don't think we need a bip85'ed variant for all the other seed list screenshots.

[Chaitanya-Keyal]

Here’s the latest set of changes after addressing the review comments:

• Refactored all seed list views to have a more DRY approach and use the new Seed class attributes for label and icon
• Updated the Screenshot Generator to have only one screenshot with a BIP85 child seed loaded.
• Moved the discard seed logic into SeedStorage
• Added tests for both discard_seed and for verifying the order of seeds set by finalize_pending_seed
• Child Seeds are now also sorted by number of words if their index is the same

Also, I've rebased the branch onto dev and cleaned up the commit history.

[Chaitanya-Keyal]

I realized there's an issue with storing parent_seed_num in BIP85ChildSeed.

Say the following seeds are loaded:

0. Seed A
1. Seed B
2.  -> #0: abcd1234

In this case, the parent_seed_num for abcd1234 is 1.

Now, suppose the user loads a child seed for Seed A:

0. Seed A
1. -> #0: 1234abcd
2. Seed B
3. -> #0: abcd1234

Here, the parent_seed_num for abcd1234 still says 1, even though it has actually changed to 2. An even simpler example is if Seed A were discarded.

The point is that we should not store seed_num as an identifying value for a seed.

I’ve updated the PR to store the parent Seed object itself, so this issue should not occur anymore.

That said, I also think we should avoid passing around seed_num elsewhere as well. Technically, seed_num is only used temporarily across views. Its value is based on the index of the button list from which the seed was selected, and any flow after that cannot modify the seeds list (except for this new BIP85 flow and the simple "add new seed" flow). In the "add new seed" case, the seed is simply appended, so the old seed_num references remain valid; and the flow ends afterward, effectively resetting any temporary seed_num usage.

In my opinion, it would be much more robust to use the actual Seed object as a reference instead of its index in the list. I'll try refactoring the codebase and open a separate PR for this. I've opened PR #810 that refactors the codebase to use this approach.

Looking ahead, if we ever support newer seed types, having direct Seed object references also seems like a win(?). And if for any reason the seeds list ever stops being strictly ordered (say we decide to use a different data structure), using indices would break things.

[SatMeNow]

@Chaitanya-Keyal I just reviewed this and tested it on my device. Looks quite great 👍
I know that there are arguments against BIP-85 because of it's complexity. The view-only child seed is a good compromise in my optinion 👍
Hope to see this in the next release.

One thing on child seeds of child seeds:
I can live without it! I even would not use it. But I prefer not to limit any users here! Users should know what they do. And there will be security setups where users will benefit from unleashed BIP-85.