@roconnor-blockstream This is ready for review.

I don't know if I'm quite ready to completely abandon 160-bit and 192-bit seeds just yet. Maybe I could be convinced.

I don't know if I'm quite ready to completely abandon 160-bit and 192-bit seeds just yet. Maybe I could be convinced.

We should discourage lengths too close they prevent insert/delete-correcting ECWs from assuming the correct valid length.

Lets start with the BIP39 lengths:

A 128-bit seed with 6-8 erroneous insertions can be corrected easily by a desktop, IF the insert-correcting ECW can assume 128-bit length. (removing 8 insertions has 1.6% chance of two solutions, 64% for 9.)

160-bit seeds MUST be discouraged as they can be mistaken for a 128-bit seed with a correctable amount of insertions.

A seed with 3 deletions can be corrected using your haskell impl to check every combo of 3 positions as erasures. (3 deletions has <6% chance of two solutions, ~100% for 4+.)

Now say we have an invalid but correctable length string, for software to know whether to try insertions or deletions, the next recommended length after 128-bits can be 128 + 8 * 5 + 3 * 5 = 183 < bitlength < 201 = 256 - 8 * 5 - 3 * 5.

So 128, 192, 256 and 512 bitlengths are safe to recommended.
160, 224 and others must be discouraged since they complicate insert/delete ECWs assumptions about length.

As suggested in bitcoin/bips#2040 (comment):

Lets define deterministic encoding defaults (identifier, padding, output share indices order) here and/or here first.

I think encoders/wallets SHOULD:

1. select padding using a CRC-w where: w = pad_bits_needed, poly = 1 << w | 3, init = 1, const = 1 << w - 1, refIn = false, and refOut = false.
2. use the first 4 characters of the bech32-encoded bip32 masterkey fingerprint as the secret seed identifier if unspecified.
3. deterministically shuffle the n share indices output.
   • Previously the bip85 app shuffled share indices but reviewers wanted it to output single strings so it was removed.

@roconnor-blockstream, as for 160-bit seeds:

I do not think "ms" secret seeds MUST NOT use them, I am saying "ms" secret seeds SHOULD use bitlengths divisible by 64 bits to simplify "insert/delete"-correcting ECWs (IDC-ECW) assumptions about valid lengths."

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

The implications of using 160-bits would not be the wallet rejects your valid secret seed. But rather that invalid 160-bit entries might receive 128-bit master seed correction suggestions from an IDC-ECW.

As I think "MS" IDC-ECWs MAY not check this length as their correction performance is maximized by a wider spacing.

This means 160-bit seeds are not interoperable with all IDC-ECW.

This RECOMMENDATION impacts the lengths our generators SHOULD generate. As we don't want to produce seed lengths that harm ECW performance if they choose to support them.

Again valid reasons exist to deviate, both on generation and IDC-ECW assumptions about lengths but improving error correction seems more important than not discouraging 160-bit, when 192-bit can be used instead.