Social Recover more options

[trymeouteh]

Please allow for the creation for more secret shares and the number of shared required for recovery. The Trezor wallet allow for up to 16 recover shares.

[AndreasGassmann]

Trezor uses SLIP39, which I strongly dislike due to the lack of BIP39 compatibility. In the long run, we will most likely go with SSKR by Blockchain Commons, as soon as there is a javascript implementation available. It is based on SLIP39, but adds BIP39 compatibility. We will most likely support all features it provides because it's a standard.

Reference: https://github.com/BlockchainCommons/bc-sskr

[AndreasGassmann]

For reference: BlockchainCommons/bc-sskr#3

[Ahmed-Ali]

@AndreasGassmann one other data point to add to this: how can I migrate my Trezor wallet to Airgap if I already use SLIP39 based SSS?
While I can see the rational of not supporting SLIP39, it can have the benefit if Airgap support importing SLIP39 based secretes (without the need to supporting creating it). Thus allowing users to migrating without having to transfer their assets over different addresses (and pay transaction cost, re-do all their delegates, stacking, etc)

[AndreasGassmann]

We can consider supporting the import of SLIP39. I'll have to do some research on the available libraries.

We'll probably also support the import of SeedXOR in the future, so we can add both of those features in one update.

[AndreasGassmann]

@Ahmed-Ali I just took a closer look at SLIP39 and sadly, it is not possible to add support for it in AirGap Vault without some considerable changes to our core architecture.

The reason for this is that AirGap Vault is built around BIP39 mnemonics. Every "Secret" is a BIP39 mnemonic.

SLIP39 is not compatible with BIP39 because the data that it splits can not be converted back to a BIP39 mnemonic. So in order for us to support importing of SLIP39, we would have to create another secret type for SLIP39 where the handling would be slightly different because we don't have access to any BIP39 mnemonic.

You can read more about this in the official SLIP39 specs, specifically number 9 in the design rationale section: https://github.com/satoshilabs/slips/blob/master/slip-0039.md#design-rationale

I will close this ticket because our long term goal will be to add support for SSKR, which is an extension / modification of SLIP39 that adds BIP39 support.

#51

[dzid26]

SLIP39 is not compatible with BIP39 because the data that it splits can not be converted back to a BIP39 mnemonic. So in order for us to support importing of SLIP39, we would have to create another secret type for SLIP39 where the handling would be slightly different because we don't have access to any BIP39 mnemonic.

The great advantage of BIP39 was its wide compatibility across wallets. With many Shamir standards, this seems to be lost.

The question is: will you (or any other wallet) at least be able to determine whether the shards were created using a supported standard or will it accept even if it is not supported?

[AndreasGassmann]

The answer depends on the implementation in each wallet.

In our implementation, we have a checksum in the shares and they are concatenated in a specific way, so I think it would be very unlikely that any incompatible share would be considered valid.

The SSKR standard is using a different wordlist compared to BIP39 and SLIP39, as well as a prefix, so it will be possible to check if it's a valid share.