Invalid threshold input (“$ of X”) triggers fallback mode that duplicates entropy and leaks checksum-index hiding mechanism (significant implementation bug)

[yatescleta-afk]

Accidentally closed my first report
Hi Bitaps team,
I’m a self-taught BTC learner who has been testing your Mnemonic Secret Sharing tool at bitaps.com (the one linked from the 1 BTC Shamir challenge page). While playing with the “Mnemonic secret sharing schema threshold” form I discovered unexpected behavior that appears to be a significant implementation bug.
Steps to reproduce:

1. Go to the Mnemonic secret sharing tool.
2. In the input box, any 12-word mnemonic
3. Set the threshold to $ of 5 or $ of 8 (or any non-numeric value in the first box).Expected behavior:
   The tool should either reject the invalid threshold with a clear error (“threshold must be a number between 1 and 255”) or refuse to generate shares, since proper Shamir requires a valid integer threshold.
   Actual behavior (what I observed every time):
   • The tool silently generates the exact number of “shares” I typed in the “of X” box (5, 8, etc.).
   • Every share is identical in the first 11 words (the entropy part is simply duplicated).
   • Only the 12th word (checksum) changes.
   • Repeatedly hitting Calculate makes the 12th word cycle alphabetically through valid BIP39 words (example cycle I captured on multiple runs):
funny → fury → furnace → future → gadget → gain → galaxy → gap → garlic → garment → game → garden → garage → garbage → etc.
   • Changing the last word of my input phrase (e.g. to something starting with “d”) shifts the entire cycle to words starting with that letter.
   • The cycle length seems capped around 16 possibilities, which matches the 4 checksum bits described in your BIP/mnemonic-improvement.md.
   This happens with any input, including the two public challenge shares you published.
   Why this is a bug (and why it matters for the challenge): Your own documentation explains that share indices are hidden in the 4 checksum bits of the last word so every share still looks like a normal BIP39 mnemonic. In normal operation (valid 3-of-5 threshold) the tool should run real GF(256) Shamir polynomials and produce completely different entropy in each share.
   When the threshold is invalid, it falls back to this trivial “duplicate + cycle checksum for index” mode. This exposes the index-hiding trick in plain view and shows that input validation is missing (NaN checks are not handled, so the code skips the real sharing logic).
   This matches the “significant implementation bug” category in your bug bounty (0.05 BTC+ tier) and could potentially weaken share indistinguishability or allow reconstruction tricks from fewer than the required shares.
   Impact:
   • Makes the tool behave unpredictably on bad input.
   • Reveals internal mechanics that should stay hidden.
   • Possibly related to why no one has claimed the main 1 BTC challenge yet (the fallback could be exploitable).
   Suggested fix:
   • Add proper type-checking and early return for non-numeric threshold/total.
   • Show a clear error message instead of silently falling back.
   • (Optional) Force real Shamir even on edge cases or disable the form until valid numbers are entered.
   I have screenshots of every step (the cycling last words, the $ input box, etc.) and can provide them immediately.
   Thank you for the amazing tool and the open bounty — hope this helps make it stronger!
   Best,
   Cleta
   BTC bc1q9ezttyulgmm7lh8a086tsug990h4j3tflk3yc7