AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 15 Bitcoin

ui: don't show waiting screen during password stretch

Public commit record

What the developer wrote

Authored by Marko Bencun

73/100 · Adequate
ui: don't show waiting screen during password stretch

Before the securechip operations became async, the UI did not process
during keystore unlock and froze at the last screen of the password
confirmation, and UI continued with the BIP39 unlock animation.

Now that they are async, the password screen is popped and the waiting
screen would be shown for roughly 1s before the unlock animation
started. To improve UI there, we start showing first screen of the
unlock animation (the locked lock) as the filler screen.

Instead of the default waiting screen being shown, during these
operations the first animation frame component is shown and held, with
animation starting only in bip39_unlock.

The downside is that when entering the wrong password, it is also
briefly shown before the wrong-password error message, but it's
acceptable.

There are other workflows where the waiting screen is also shown
during the stretch, not addresed by this commit: show mnemonic, create
backup, and change password (any call to
`workflows::unlock::unlock_keystore()` to check the password).

Co-Authored-By: Niklas Dusenlund <niklas.dusenlund@bitbox.swiss>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a user-interface polish change for the BitBox02 hardware wallet. It replaces a generic 'waiting' spinner with the first frame of the unlock animation while the device is busy stretching the user's password. There is no security vulnerability or fix here—only a visual improvement to make the device look smoother during unlock.

Recommended action

No security action required. Treat as a normal UI/UX improvement during code review and regression testing.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 15/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 0/15
Confidence 10/10
Evidence quality 5/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.