Either system could be compromised in any way and as long as the same person/group didn't compromise both then they would never be able to use the partial keys alone.
You are describing how to generate a secure paper wallet on two compromised machines (that are not compromised by the same attacker).
May I ask what is the original purpose for that? If it was for the one paper wallet savings account that you occasionally withdraw from then, in order to sign the withdrawal transaction (which in your proposal is not a multisig), you are still faced with the problem of at least securely booting into a minimal OS (which you could then have used to the generate the paper wallet in the first place).
The split keys described here are useful where you (the user) may be one of the attackers. In the traditional banking system, it is typical for institutional checking accounts to have 4 or more signing authorities, where at least 2 are required to authorize a transaction. Using the rules outlined in this thread, it is possible to build an electronic "checkbook" such that 2 of 4 keyholders are required to sign a Bitcoin transaction. The outputs would go to the payee and the next "check" in the checkbook. That is to say, each "check" would be single use (and sequentially numbered to facilitate that).
My concept assumes that this description is correct:
The math works out fine for any number of keys, but the amount of exchanging of information between devices gets annoying:
Private key is A
Public key of A is A'
Public generator point of the Bitcoin elliptic curve is G.
Device 1: Creates private key A. Computes public key which is A*G = A'
Device 2: Creates private key B. Computes public key which is B*G = B'
Device 3: Creates private key C. Computes public key which is C*G = C'
Ultimately, the combined private key will be A*B*C, and the public key will be (A*B*C)*G. However, in order to do this, Device 3 needs to give device 2 its public key (C' = C*G). Then Device 2 can produce B*(C*G)=(B*C)*G. Then you transfer that to device 1 which can then produce A*(B*C)*G = (A*B*C)*G. No one device has seen any private keys other than its own (so far). Send coins to the address associated with that public key.
In order to create the private key, you just collect A, B and C onto the same computer and multiply to get (A*B*C). Import that into a wallet and sign. If you want to play with this, I recommend downloading Armory and run it in offline mode (because you won't actually use it for your wallet), then go to "Tools->ECDSA Calculator".
Private key is A
Public key of A is A'
Public generator point of the Bitcoin elliptic curve is G.
Device 1: Creates private key A. Computes public key which is A*G = A'
Device 2: Creates private key B. Computes public key which is B*G = B'
Device 3: Creates private key C. Computes public key which is C*G = C'
Ultimately, the combined private key will be A*B*C, and the public key will be (A*B*C)*G. However, in order to do this, Device 3 needs to give device 2 its public key (C' = C*G). Then Device 2 can produce B*(C*G)=(B*C)*G. Then you transfer that to device 1 which can then produce A*(B*C)*G = (A*B*C)*G. No one device has seen any private keys other than its own (so far). Send coins to the address associated with that public key.
In order to create the private key, you just collect A, B and C onto the same computer and multiply to get (A*B*C). Import that into a wallet and sign. If you want to play with this, I recommend downloading Armory and run it in offline mode (because you won't actually use it for your wallet), then go to "Tools->ECDSA Calculator".
In my example, I want to set up a Bitcoin checkbook such that 2 of 4 signers are required to authorize a transaction. For each 'check', each person will generate a new, unique private key: that I will designate A, B, C, D. BB code does not support nested formatting, and I want to write in English rather the pseudo-code. That is why I am making it clear here that A, B, C, D are different for each check.
For each check (of which an arbitrary number can be generated ahead of time):
- Generate a UNIQUE sequence number (stored in 'check')
- Each person generates a random, private key on their own machines (A, B. C, D)
- Each person computes their Public key: For example person 1 would; A*G = A'
- Each person shares their public key with every other person.
- Each pair of people generate a joint key:
Person 1 Pairs with person 3: A*C'=(A*C)*G
Person 1 Pairs with person 4: A*D'=(A*D)*G
Person 2 Pairs with person 3: B*C'=(B*C)*G
Person 2 Pairs with person 4: B*D'=(B*D)*G
Person 3 Pairs with person 4: C*D'=(C*D)*G
- Each pair of people now sends their newly computed public key to every person not in their group..
- Each person encrypts their private key with the public key of every group for which they are not a member.
- Each of the results from the previous step are stored in the 'check'.
- The group generates a combined public key:
Person 3 passes the result to person 4.
Person 4 multiplies their private key with the previous result: D*(A*B*C)*G=(A*B*C*D)*G
That result is stored in the 'check'
Edit: as a basic sanity check, Persons 1, 2 may want to do the same thing with the Person 3, 4 joint key. (and compare results)
To spend a 'check'
- A pair of people share their private keys
- They use their combined private key to decrypt the individual private keys encrypted with the combined public key
- They typically generate a transaction with two outputs:
2. To the next 'check' in the 'checkbook' (randomizing the order may be wise, but may not do much if this output is always larger).
Notes:
- Any participant can through malice or error hold all the funds ransom. I stopped trying to think of a work-around when I realized this applies to the two-person case as well. The parties should reasonably trust each other.
- If I am not mistaken, the data storage requirements grow factorially with the number of participants. Strictly for small groups.
- If you want to add or remove a signing authority, a new 'checkbook' must be generated. You would then spend the old 'checkbook' to the new one.
- Because of the complexity and lack of fail-safes, I recommend testing any implementations on testnet first.
