It's not a terribly large amount of code, and it's easy to test, even with a "live" key (since testing that any n of m can be recombined doesn't force a spend or reveal anything externally).
Also, it's a fairly well-known system, so I don't see it being collectively "forgotten" on the timescale of a few decades (it's been around since the late 70's i believe).
I'd love to get it integrated into wallet software, as it's such a safe and reliable way of storing secrets that lets you be as "secure" or as "reliable" as you want with just a slider.
This is what I had in mind. And it can scale to any "n of m" you want, without any if the downsides if multisig wallets (namely larger transactions, and more complex Bitcoin wallets required)
it's called 2 of 3 multisig and it's a standardized part of most cryotocurrency. it requires X of Y separate key signings to complete a transaction from an address
You don’t really want to split the key (as in if the key is n bytes, split it in 3 segments of n/3 bytes) because if one has two segments, I imagine it’s not inconceivable to infer the third segment from the public key and the other two (though I haven’t made the math).
Rather you have a private key p of n bytes. Create two cryptographically random keys k1 and k2 of n bytes each. Derive a key k3=(p XOR k1) XOR k2. k1, k2 and k3 are your distributed keys. To recompute p you need to do p = (k3 XOR k2) XOR k1.
A XOR is trivial to implement and I would expect be reasonably robust.
