Split wallet - create a key and split it with Shamir's scheme (also recombine shares from previously split key)

[weissjeffm]

No description provided.

[pointbiz]

Jeff, I'm working on a branch that has pulled this request. Two methods in ninja.splitwallet.js are of particular interest: stripLeadZeros and hexToBytes. Can you explain why they are needed and could you provide an example using the unit test called "testSplitAndCombinePrivateKey3". I tried to use a key with one 0 removed at the start but the test fails.

Basically I need an example that would trigger the usefulness of those two methods in a unit test.

[pointbiz]

Jeff, another topic I wanted to discuss was the Base58 encoding. I think it might be better to use hex format for "parts of a key". Which is what was done on the Vanity Wallet tab. So as not to confuse the parts with the whole key in base58.

If I remove the base58 encode and decode in the .map it breaks things. How can we have the shares stay in hex format and be combined from hex format?

[weissjeffm]

@pointbiz

stripLeadZeros - without this I think the output could look like "01Bds245..." and since we're just outputting a number (whether hex or base58) it doesn't make sense to have leading zeros. So I strip them to get "1Bds245..."

hexToBytes - this is just like the hexToBytes in Crypto.util, except it properly handles cases where there are an odd number of hex digits. The built in one I'm sure never needed to handle that case.

The reason I used Base58 was because I stamped these split keys onto pieces of metal, and it's a lot easier to do with 1/3 the characters. While the shares do look like private keys, you could see that as a feature too - a thief who finds a share won't (easily) know that it's not a full key.

I think though that if you want to keep hex, you need to remove two calls: map(this.hexToBytes).map(Bitcoin.Base58.encode) because the conversion from hex to base58 has an intermediate as a byte array. And then remove .map(Bitcoin.Base58.decode).map(Crypto.util.bytesToHex). from the decode. I haven't tested this myself yet, but it should work.

I'll work on those unit tests when I get a spare moment. Thanks!

[pointbiz]

Jeff, you convinced me to leave the base58 because of the stamping you did in metal and what others might do on wood etc. And now I see the '3' as a cool way to denote it's a piece in a bitcoin shamir's secret sharing key (unofficially).

I've made another commit, it has all the unit tests I think we need. I think it's ready. It doesn't have any explanation at this point though.

I started it with 2 of 3 because I thought it would be a more common scenario than 2 of 4. I tried to work out a couple use cases, do you have any to share?

Example use case 2 of 3:
Division of 3 shares:
1 share in a safety deposit box ("Box")
1 share at Home
1 share at Work
Threshold of 2 can be redeemed in these permutations
Home + Box
Work + Box
Home + Work

Example use case 7 of 13:
Division of 13 shares:
4 shares in a safety deposit box ("Box")
3 shares with good friend Angie
3 shares with good friend Fred
3 shares with Self at home or office
Threshold of 7 can be redeemed in these permutations
Self + Box (no trust to spend your coins but your friends are backing up your shares)
Angie + Box (Angie will send btc to executor of your will)
Fred + Box (if Angie hasn't already then Fred will send btc to executor of your will)
Angie + Fred + Self (bank fire/theft then you with both your friends can spend the coins)

7e760cb

[weissjeffm]

@pointbiz excellent! 👍

I think 2 of 3 is a fine default. It's the minimum value that makes Shamir's useful.

I can't think of any use cases that differ significantly from yours. You could come up with one with a higher threshhold if you were worried about Angie and Fred colluding. But that gets complicated, especially if you want Angie and Fred to collude but only after you're dead (I can't think of any good way to do this without a dead man's switch). I think you can leave it up to the user's imagination :)