improvemImplementation break (#48) directly compromises the live 1 BTC Shamir challenge (bc1qyjwa0tf0en4x09magpuwmt2smpsrlaxwn85lh6) As reported in #48 and fixed in the approved (but not yet merged) PR #50, providing an invalid threshold

[yatescleta-afk]

My address for the 0.05+ BTC tier (already listed in PR #50) and the additional 1 BTC disclosure bounty:
bc1q9ezttyulgmm7lh8a086tsug990h4j3tflk3yc7
Once paid and PR #50 is merged, happy to provide full repro steps and deeper analysis on how this weakens the challenge shares.

Implementation break (#48) directly compromises the live 1 BTC Shamir challenge (bc1qyjwa0tf0en4x09magpuwmt2smpsrlaxwn85lh6)
As reported in #48 and fixed in the approved (but not yet merged) PR #50, providing an invalid threshold (e.g. anything resulting in NaN like “$ of 5”) causes the library to enter a degenerate fallback mode:
• All shares end up with identical entropy bytes
• Only the checksum (last word) changes due to the index-hiding mechanism
• This leaks the custom 4-bit index hiding described in BIP/mnemonic-improvement.md
This is the exact same software (shamir_secret_sharing.js) and mnemonic tool used to create the 1 BTC challenge:
• Wallet: bc1qyjwa0tf0en4x09magpuwmt2smpsrlaxwn85lh6 (~1.00016775 BTC still sitting there)
• Path: m/84’/0’/0’/0/0 (and the second xpub path that also derives the same address)
• Zpub: zpub6qdEDkv51FpxX6g1rpFGckmiL46vV8ccmtEgPAkj3qj8N4ZZHyXDRA9RwpTiFK2Kb8vRaDmSmwgX6rfB4t2K8Ktdq8ExQ6fumKpn2ndJCqL
• Published shares (2 of 3, threshold=3):
• session cigar grape merry useful churn fatal thought very any arm unaware (hidden x=5)
• clock fresh security field caution effort gorilla speed plastic common tomato echo (hidden x=1)

[ericjoye]

The implementation break in the live 1 BTC Shamir challenge you’ve documented in #48 reveals a critical edge case where an invalid threshold like “$ of 5” triggers a degenerate fallback state. My approach focuses on hardening the library against malformed inputs by enforcing strict validation of the threshold parameter before processing, ensuring edge cases like NaN results are caught and handled gracefully.

I recently implemented similar parameter validation in a cryptographic key derivation project where I fixed a similar issue that could leak partial secrets under invalid input conditions. This fix prevented similar degenerate states by introducing early input sanitization.

Let’s discuss applying this same fix to your codebase. I’ll focus on the threshold validation logic first and can expand to the full repro steps afterward.

Eric

[yatescleta-afk]

Hey Eric, Thanks for reaching out. The threshold issue and degenerate fallback were actually the core of my report in #48 — the fix is already in the approved PR #50 that Zhaog100 put up. Appreciate the input though. I’ve got this one covered. Best,Cleta On Apr 14, 2026, at 7:51 PM

[ericjoye]

Hi Cleta,

I appreciate your response and the work that's been done on PR #50. Since the issue is already being addressed, I'll consider my claim for the bounty closed. If there's anything else I can assist with, please let me know.

Best,
Eric