User talk:Vbuterin

K_of_N_redundant_offline_private_key_proposal

User:Vbuterin/K_of_N_redundant_offline_private_key_proposal

I just checked Recent Changes and was excited to see you putting this together! A few things:

1. Does this bear any similarity to "Shamir's secret-sharing scheme"? (which I know little about other than having skimmed the Wikipedia article)
2. Your proposal points out that the payload will have varying lengths, but the same time, stipulates a prefix of 0x86 for the benefit of the user. Off the top of your head, how much do the lengths vary? The reason I ask is that the prefix on the base58 string as seen by the user only stays constant when the number of bytes in the message is constant. If the variation isn't that much, then adding padding bytes might work. For example, the private key that starts with '5' suddenly starts with a 'K' or 'L' when an extra byte is added. If it isn't clear why, a simple analogy can be made for hexadecimal vs. decimal: all four-digit decimal numbers that start with 5 (i.e. decimal numbers between 5000 and 5999) will have a hex equivalent that starts with 1, but it's not true for non-4-digit numbers: 50000 and 59999 will have a hex equivalent that starts not with 1, but instead, C, D, or E.
3. Somewhere in the message, there should be a 1-bit flag that tells whether to create the bitcoin address from the uncompressed vs. compressed public key.
4. Somewhere in the message, there ought to be a small handful of bits taken from the resulting bitcoin address, so a user interface accepting parts one by one can reliably detect and complain: "The last part you entered does not belong to the part(s) you entered before".
5. Somewhere in the message, there should be a count that tells the UI how many total parts are needed and how many exist. (e.g. the values of K and N)

Casascius (talk) 19:54, 5 August 2012 (GMT)

1. @1 I came up with the idea myself, so it wasn't inspired by Shamir's scheme.
2. @2 The longest piece should be 256 + n*log2(k) bits long, so 257 for the degenerate (1,1) case, 264 for (5,3) and 292 for (12,8). Thus, for high values of i, as it seems that you have already realized, the randomly chosen values do need to get progressively smaller if you want to impose a maximum size limit on the pieces. Making each piece random(0,min(2^256,2^288/k^(3*k))) rather than random (0,2^256) might be a good idea.
3. @3,4 Sure, sounds good
4. @5 Neither N nor K is strictly necessary, but I can see how it would be nice to have for usability purposes.

Vbuterin (talk) 23:25, 7 August 2012 (GMT)