One of the primary goals of this project is to make it easy for non-technical users to store their keys safely. That means a user interface is mandatory. A CLI is not sufficient. To me, that means we need an implementation in JavaScript.
See, for example AirGap Vault. Its social recovery feature creates mnemonic shares using Shamir’s scheme, but it doesn’t follow a standard. Their code is currently written in TypeScript. It would be great if they adopt a standard like the one proposed here.
Similarly, I’m working on a UI that will make it easy for non-technical users to split their mnemonics in order to keep them safer. My project is also written in TypeScript.
And, if it becomes a standard, maybe others will adopt it for similar workflows in their own apps as well.
The point here is that it needs to be easy to implement correctly, even in a language like JavaScript. The max number in JavaScript is 2^53 - 1. So, to use a field larger than the max number would really complicate the implementation. GF(256) on the other hand is very easy to implement in JavaScript.
One additional complication of a field like GF(2^128) is that we’d need a different field for each supported strength of mnemonic. BIP-39 supports 128, 160, 192, 224, and 256. While not a big deal, supporting five different fields does add complexity to the implementation.
For a more articulate rationale for GF(256), written by folks with a lot more experience than me, see slips/slip-0039.md at master · satoshilabs/slips · GitHub. The use case is very similar to this one. Key differences are: this one focuses on interoperability with BIP-39. SLIP-39 adds a variety of additional features to facilitate sharing.
Regarding:
Verifiable secret sharing is needed where share holders want to verify that they got good consistent shares.
Another place where having valid secret shares (GF(2^128) and GF(2^256)) is nice is with threshold signatures. Share holders can sign together a transaction.
Both of these features sound very interesting. I had not considered them in the initial feature set for this, but am interested in learning more. Can you point me to any resources on this? What would it take to support these features in this spec?
I feel like additional implementation complexity could be justified if it supports additional, useful features.
Thanks again for digging into this spec with me! I really appreciate the feedback you’ve given and have learned a lot from it.