Share backup format

[LLFourn]

Should we specify a share backup format as part of this BIP?

The most minimal share backup would be just to include the compressed Shamir secret share. This would be 32 bytes + a few bits for the index on the polynomial. BIP93 has some inspiration here. It also encodes a threshold (3 bits) and a 4 character identifier.

I think encoding the threshold makes sense in our case too for UX reasons. It's nice when recovering to know what your goal is and that you are making progress towards it with each successive share.

The advantage of keeping it to a minimum (and having a poorer recovery UX) is that it will be possible to record it on any 24-word seed backup metal plates (note BIP93 doesn't mention that it is not compatible with all (most?) 24-word backup plates e.g. I claim it you cannot use these kind any others that only support alphabetic characters).

I feel for FROST it makes sense to increase the threshold 5 bits (1 character) to make it possible to express any threshold up to n-of-n where n is the max value index. We could of course allow a full 32 bytes for the index to allow backing up of any share but maybe in a different format with different bech32 prefix.

The 4 byte identifier is also a good idea but I think it makes sense to require it must be derived from the public polynomial coefficients so that when you get t of the backups together and interpolate them you should be able to get this same value.

The motivations for this are very similar to those of BIP93. I imagine people would use this to encode their shares on slips of paper and give one to accountant, one to lawyer and one to spouse etc for inheritance. They can do this while maintaining the actual live shares on devices.

Another key motivation is interoperability between software. People really like the ability to take seed words from one piece of software and put it into another one and have it just work and I think it's a reasonable expectation.

My opinion is that we could leave it out for a separate BIP seeing as any secp256k1 field based shamir secret sharing style scheme could use it.

[real-or-random]

We should, for each DKG in the BIP, specify at least one backup data structure (tuple?) or blob from which the setup can be restored (and ideally, also the recovery algorithm).

Apart from this, my thinking is that I want to keep the scope of this particular document limited to the actual cryptographic questions, for which we can make use of our expert knowledge. So I'd be hesitant to specify a concrete encoding method (e.g., bech32 or how many bits the int should have). But yeah, I agree, other standards that build on top will be necessary if we want interoperability... What you bring up are important questions, I just don't think they should be answered in this BIP (and that I want to be involved).

[LLFourn]

Sure. We will work on this as a separate effort then. I'd say the scope of the share backup BIP in general is just to have a good format for secp256k1 shamir share backups in general and how to interpolate those shares to produce the public polynomial and key.