Aside from the leading 'version' word in shamir mnemonics, it may be useful for them to be bip39 compatible. Currently they don't have a checksum so are reported as invalid by most bip39 software*

Inspired by https://www.reddit.com/r/btc/comments/6y5q11/shamir39_mashup_of_bip39_mnemonics_and_shamirs/dmkzzzs/

I like the idea.
You could store some bitcoins on each of the Shamir39 shares to mislead a thief and as a honeypot to see if one of the parts has been compromised.

* See bip39 spec > Although using a mnemonic not generated by the algorithm described in "Generating the mnemonic" section is possible, this is not advised and software must compute a checksum for the mnemonic sentence using a wordlist and issue a warning if it is invalid.

Hi Ian, how is this similar or different from SSKR? https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-011-sskr.md

Please, help - cant seem to firgure out what I am doing wrong:
using this seed phrase:
ceiling luxury void exotic thunder stable very type tree fruit custom material social muffin pumpkin clog actress wolf bamboo ecology replace runway curtain hollow

keep getting Invalid Mnemonic

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)

See iancoleman/bip39#257 (comment)

many popular wallets want you to back up your recovery seed using BIP39 mnemonics. If you can convert that string back into a 32 byte hex value, then you can run your seed through ssss-split -x -s 256 and get 32-byte hex shares. Each of those shares can itself be encoded using BIP39, which is much more user-friendly than writing down 64-128 hex digits.

Now that we have SLIP39 live including a JavaScript library, do you have any plans to switch this project to it?

Changing the number of bits (see #2) breaks previous implementations. But there is nowhere in the specification that indicates what this value should be set to.

So it's not a very robust specification. It should specify this value so any future changes to the value must be reflected in the specification.

Dear Ian, i am new on Git Hub and i dont know how to contact you, so i will write here my question :)

I try to understand your example (see below) but i did not understand well about the third component....can you please complete the example also about the third component
??

that will help me to understand in full yr example.

Thank you so much in advance,

Marco from Phuket :)

Example encoding parameters across multiple words
Consider
M = 35 = 100011
O = 10 = 1010

Left pad both to multiple of 5 bits

M = 0000100011
O = 0000001010

Split into groups of 5 bits

M = 00001 00011
O = 00000 01010

Convert this into mnemonic words:

The first word is not the final word so it:

• starts with 1
• then has the first five bits of M
• then has the first five bits of O

1 00001 00000 = 10000100000 = 1056 = "lottery"

The second word is the final word so it:

• starts with 0
• then has the second five bits of M
• then has the second five bits of O

0 00011 01010 = 00001101010 = 106 = "ask"

So the parameters M = 35 and O = 10 are encoded as "lottery ask"
Third Component is The Shamir Share
The third component is the data for the shamir share and is a binary blob which must be encoded to mnemonic words.

The binary shamir share is encoded to mnemonic words by:

left pad the binary share to multiple of 11 bits
convert each group of 11 bits to the corresponding word in the wordlist
The mnemonic words are decoded to the binary shamir share by:

convert each word to the 11 bit binary representation and concatenate together
truncate from the left to the required multiple for the specific shamir implementation (in the case of the prototype it's 4 bits)

I went through this scheme and following crossed my mind:
Whereas for encoding BIP39 enthropy, which is multiple of 4 bytes, this technique works well and unambiguously, the left-zero-padding inside 11 bits words is problematic if we want to encode arbitrary message (we wouldn't know where starts message and where starts padding).
This problem could be solved if the 11-bit word was left-padded by all zeros but last bit which would be '1', i. e. 5bit message (xxxxx) would be padded like this 000001xxxxx. We knew we only need to discard everything up to first '1'. In case the message fitted whole 11 bit word, dummy word 00000000001 were inserted.
What do you think about this?

The number of bits used for ssss shares determines the maximum number of shares.

The ssss library defaults to 8 bits (max 255 shares)

The shamir39 implementation hardcodes it to 12 bits (max 4095 shares)

This should ideally be encoded into the mnemonic so there is no upper limit on the number of shares. See shamir39.js L744

In the draft, you wrote

'amused' is index 65 in the English wordlist.

However, "amused" has an index number 66 in the below list:

https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt

Maybe not that important but can be fixed.

if you try to put a 1-of-2 it says "Required must be at least 1" (should say "at least 2")

Hi, would it be possible to split/recombine into 20 word shares:
Trezor T and Keystome offer Shamir backup options, where they split into n/m shares of 20 words. And they are compatible. Still, my concerb is if both trzor and Keystone stop working, I would not be able to recover from my Shamir 20 word share they generate. I am wondering if you could adjust the number of words per share into 20 and that way I would be able to software recombine them if needed. Thank you in advance

It looks like it's possible to combine shares from different mnemonics:

M0 = generate mnemonic
M1 = generate mnemonic
A0, B0, C0 = shares(M0, 2, 3)
A1, B1, C1 = shares(M1, 2, 3)
M2 = combine(A0, B1)
M2 != M0 != M1

This would definitely be user error, but it would be nice if users were protected from this.

Can you possibly upload this to Arweave.org and share the url here so it will exist forever?

I was experimenting with inputing the Shamir shares (20 word list) produced by Trezor into your tool however there is a word not used ("academic") in your tool that they use. Would it be possible to add an option/switch to use their wordlist to reconstruct shares in the combine list? Their list is located at
https://github.com/satoshilabs/slips/blob/master/slip-0039/wordlist.txt

This would be helpful as an escape hatch to restore a wallet in case Trezor/satoshilabs ever disappears.