Point addition on a given curve (where everyone knows the parameters, like secp256k1) is easily invertible. Point subtraction is only slightly slower than point addition.
Agree.
Additionally, it is very unwise to rely on any method that requires keeping public keys secret.
Agree. However, there is nothing in the proposed two key system that requires that any public key be kept secret. All three public keys a*G, b*G and (a+b)*G are, at all times, publicly available keys. Knowing all three public keys give you no new information. Anyone can use point addition or point subtraction to calculate any one of the three from the other two but that is pointless (grin) since all three are public keys anyway.
Going back to casascius' original idea: you CAN use Diffie-Hellman shared-secret techniques to SECURELY create a shared key. If Alice has (a, a*G) and Bob has (b, b*G), then by publicly broadcasting their public keys, Alice and Bob can both compute the elliptic curve point (a*b*G) and no one else can.
Agreed. This would work. And you have just created a shared key that only Alice and Bob can know, yes. But since this shared key is going to be a public key why does it need to be a shared secret?
(1) (A and B) Alice and Bob create the point (a*b*G) from each others' public keys, and use the result as a new public key. They calculate the address hash and put it in the TxOut field of a transaction. Then when the money needs to be spent, Alice or Bob can send the other one their private key, and then the combined private key can be computed and used to sign the inputs. This is perfect for casascius application, but not many other applications (see below).
Agreed. This would work. However the proposed point addition system will also work just as well.
(2) (A or B) Alice and Bob create the public key as above, and then use the x component (or combination of x and y components) to derive a new private key. This private key can be converted to public-key/address that can be included on a transaction, and then Alice or Bob can sign for that transaction. This isn't relevant for casascius' application, but it is cryptographically secure, and has plenty of other useful applications.
True.
The problem with (1), in general, is that it's a terrible idea to create a crypto process that relies on exchange of private keys. While a wallet/app will attempt to use a different private key for every transaction, there's a possibility that things go wrong -- someone else sends that private key money, a bug in their client (or someone manipulates their client) to reuse private keys, multiple clients using the same wallet don't realize the key has been used, etc. And a problem like this would go unnoticed by the user until someone has already exploited it.
Agree with the general statement. However what is being discussed here assumes the key pair is going to be used one time for a specific purpose.
This is in the same vein as requiring public keys to be kept private -- private keys should never have to be made public.
There is nothing in the proposed point addition scenario that requires any of the points (pubic keys) to be held as secrets. Where did you get that idea?
Except for casascius' application: his CONOPS already involves exchanging private keys and his software is specialized to do this correctly. For general multi-signature protocols over the internet with untrusted parties (1) should never be used. (2) could be used cryptographically-responsibly to replace 1-of-2 multi-sig transaction types, but that's for some other application.
I agree that your proposal would also work for the coin application. But since your only objection to the proposed point addition method is based on the incorrect assumption that it requires that one or more of the public keys be kept secret do you now agree that the proposed point addition system will also work?
P.S. -- I am very interested in ways that an (A and B) transaction could be created using "responsible" cryptography, but so far no one has suggested a way. Such as a way for Alice to only compute the combined private key with her own private key and Bob's signature (or vice versa)...
Me too.