Entropy shouldn't be fudged before splitting; shares have redundant words / long mnemonics

[edward-t-m]

The entropy, along with checksum, is padded prior to splitting resulting in longer-than-necessary mnemonics.

For example, for 12 word (128-bit) mnemonic with checksum results in 132 bits, which is then further padded on a 4-bit boundary before splitting. This results in 14 words in addition the version and parameter words. More words means a higher risk of transcription errors.

This can be seen in all shares of 6 or more words beginning with 'abandon', irrespective of the input mnemonic.

I suggest splitting only the entropy, not the checksum. This results in shares only as long as the input mnemonic (other than the version and parameter words)

Presumably related but I'm still confused by this:

truncate from the left to the required multiple for the specific shamir implementation (in the case of the prototype it's 4 bits)

[iancoleman]

Agreed there are some inefficiencies and implementation-specific cruft that could be improved, but I'm on the cusp of decommissioning this tool in favour of SLIP-0039

https://github.com/satoshilabs/slips/blob/master/slip-0039.md

[edward-t-m]

Eek, I had started doing a C implementation of your spec (not yet finished), hence discovering this issue.

https://github.com/edward-t-m/shamir39

A spec that will presumably be broadly adopted is good, although I dont like their 17 words from a 12-word seed. I've made expensive transcription errors before which is why I think minimising words is important.

I'm now wondering if I should continue this anyway. Your spec might also be preferred over the SLIP by people for whom #1 is important.

[iancoleman]

Yes I think the feature set is still open for discussion but it feels that no matter which way the various feature combinations go some people will be left unsatisfied (eg use of version word or not).

I don't currently have a preference toward any particular features. I'd prefer to hear from 'the market' but so far there's no clear indication for which direction to take. There is of course the option to use 'configuration flags' to satisfy everyone but is it worth the complexity in the spec to manage the variations? I would have to say 'no'.

[ghost]

Agreed there are some inefficiencies and implementation-specific cruft that could be improved, but I'm on the cusp of decommissioning this tool in favour of SLIP-0039

https://github.com/satoshilabs/slips/blob/master/slip-0039.

Still thinking of discontinuing this project? Very interested in using this tool myself.

[iancoleman]

Not discontinuing, but probably won't develop it any further.

Should always be available at https://web.archive.org/web/*/iancoleman.io/shamir39 but I intend continuing to host it anyhow. Local copy is of course a natural inclusion if this tool ends up being used (which I don't recommend, instead wait for slip0039 to be available).

[lastmjs]

What's the update on slip0039? Is anyone using it?