Description
If you have a 47-character string but were expecting a 48 character string, you can just try inserting a blank in every possible position, running error correction (a variant where you can specify known error locations, which makes it able to succeed with up to 8 missing tiles rather than just 4), and seeing if it succeeds. With overwhelming probability, but not a guarantee, if you actually have a small random set of errors that include insertions/deletions, you'll find the corrected string, and only the corrected string.
So in summary, error correction implementations:
- During initial wallet setup, behave like bech32: you can highlight substitution errors, but don't correct anything.
- During recovery, then do whatever you can, including grinding for insertions/deletions, to find the seed. Then show the user the set of corrections and make them re-enter the corrected string (in the hope that they'll make a new corrected backup) before using it.
Let me bug some people on IRC before making RFC-style SHOULD NOT/SHOULD/MUST/MUST NOT/MAY proclamations. We may want to update the BIP with this sort of text.
Originally posted by @apoelstra in BlockstreamResearch/codex32#54 (comment)
The current implementation that is in this repository does not "make them re-enter the corrected string (in the hope that they'll make a new corrected backup) before using it" It merely shows the user the corrected string and asks them to confirm it matches their backup.
Since the error correction could be wrong, it sounds dangerous to "correct" the backup which make be destructive of less damaged data than the correction was.
Only if we can match the fingerprint and/or an address on the last share should we tell the user to correct that share's errors.