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

feat(shamir): default to 33-word shares with coin-support descriptions

Public commit record

What the developer wrote

Authored by John Boyd

85/100 · Strong
feat(shamir): default to 33-word shares with coin-support descriptions

Change the default Shamir share word count from 20 to 33 words
(SLIP39_DEFAULT_MNEMONIC_WORDS), since 33-word shares support all
coins including Zcash.

Add descriptions to the word-count picker explaining which coins each
option supports ("Supports most coins" vs "Also supports Zcash"), with
translations for en, de, es, ja, ko, ru, and zh_CN. The translations
were partially machine-assisted and need human review: @daira knows
German and some Spanish but no Russian, Japanese, Chinese, or Korean;
the Japanese, Korean, Russian, and Simplified Chinese translations
were by Claude. All translations were checked for consistency with
existing translations in their use of the technical terms 'wallet',
'coin', 'Shamir share', and 'word'.

Co-authored-by: Daira-Emma Hopwood <daira@jacaranda.org>
Co-authored-by: Claude Opus 4.6/4.7 (1M context) <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes the default Shamir backup share length from 20 words to 33 words and adds on-screen explanations about which cryptocurrencies each option supports. It is a usability and compatibility improvement, not a security fix or vulnerability. The code also tightens a few display routines so the word count is shown correctly regardless of the selected value.

Recommended action

No security action required. Review as a normal feature/localization change. If desired, verify that the new default 33-word shares interoperate correctly with wallets that previously expected 20-word shares.

Security signals we found

01

No memory safety defects observed; snprintf_s is used with a 4-byte buffer and a _Static_assert ensuring the value fits

02

No change to key generation, seed derivation, or Shamir splitting logic

03

No privilege escalation, authentication bypass, or secret exposure introduced

04

UI callback re-registration and hint-box cleanup are defensive, not exploitable

Risk score

Why this scored 20/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 3/15
Confidence 9/10
Evidence quality 4/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.