Yes that works fine except instead of point addition, use point multiplication.

S1 and S2 are random numbers about the same size of the group order. Send the second party the coordinates of S1*G where G is the agreed "generator" point. The final public key is S2*(S1*G) and the private key is (S1 * S2) modulo the curve order.

ByteCoin

I don't think it's a matter of taking away trust, I just feel I can offer a better product if it permits its buyer to put more "trust in numbers" and require less trust in the manufacturer.

For example, we've got robkohr on another thread learning the best way to create his own bitcoin bills.  How sweet a product he would have, if his bills had two holograms on them, each one coming from a different party.  A built-in "check and balance" if you will.

I don't think anyone seriously thinks I will burn them on a 1 BTC coin, especially knowing that I'm charging 1.80 for the coin, and would be drying up a pretty sweet opportunity to sell them at an 80% markup by burning a few people.  When I start cranking out 100 BTC gold bars, people start wanting to be a little bit more cautious, and rightfully so, no matter who I am.

On the other hand, if it's possible to produce bars where no single party has the full private key, it's possible to produce higher-denomination bars with better assurance to the buyer that they are the only one with access to their funds.  Why not a 1000 BTC bar?  It would keep the premium low, and would appeal to the non-technically-oriented buyer.  Same thing would go for a paper savings wallet.

Unlike a 1 BTC coin, a bar also has enough surface area to hold multiple hologram stickers and multiple private keys.

I suppose I could just as easily create bars with nonstandard "two party" scripts that require two separate private keys to redeem, it would just add complexity to the redemption process as well as the production process (e.g. I would have to find a reliable miner who would accept these transactions into the block chain).  All the better if the magic can just be hidden in the math I suppose.

That NEVER happens. heh.

I believe there's a javascript address generator which you could include inthe ordering process.  The webpage would send you only the data necessary to construct the coin, and give the user the full address info.

Obviates the trust issue completely, but inevitably some users would fail to save this data and lose the coins.

Sorry, I don't follow.  Can you elaborate, please?

Edit: Oh, do you mean the coin has no resale value because the purchaser is not supposed to know what's under the hologram sticker?  I guess that's a concern.  Still, if we're talking about 1000BTC transactions, I wouldn't be trusting the integrity of the transaction to the integrity of a sticker anyway.

Yes, it is possible. Either with ByteCoin's suggestion:
Or with point addition (slightly different, but the security is the same):
The first party generates S1*G, and sends the X and Y to the second party. The second party adds to this point the point S2*G.
This means the public key is now S1*G + S2 * G = (S1+S2)*G, and the private key is (S1+S2). (Of course, everything modulo the curve order.)

Actually, they could, if the hologram is intact. Since under the hologram S2 is stored, the first buyer can't have redeemed the coins unless the hologram is broken. (Assuming safe holograms here.)
You, as a second hand buyer, of course have to trust the first buyer to give you the correct S1. But since the knowledge of S1 an sich is useless to the first buyer, there is no gain for them in scamming you. Unless they don't like you.


The "simple" case discussed up till now where all the keys involved need to be known is rather trivial, and is not threshold signing. That said, threshold signing may be useful, since invariably one of the parties is going to lose his key, and you don't want the money to be gone then.

Yes, this would work. You have to make sure the other party knows which public key goes with which gold bar though, so make sure your communication is clear on that.

For the record: Either of you can load the bitcoins onto the address. If you (casascius) want to do it, the other party needs to tell you the address(es).

If this is all true, then it has big unrealized implications for ways wallets can be secured, far stronger than wallet encryption.

Imagine a web wallet service which created and managed s1 and which signed your transactions after verifying them via SMS. (s1 would be mailed to you encrypted, or on a CD-R, as a failsafe)

Imagine a paper wallet printer which took s1*G and printed you a 100% safe paper wallet because you generated s1*G from a passphrase (s1=sha256(passphrase)) using an app on your smartphone.

I would be eager to understand the flaw you say you see.  I do not understand the math well enough to be qualified to see the flaw, I have to take someone's word for it.

Could you maybe tell what the flaw is?.. Because as far as I know, there isn't one.
Note: Your way of phrasing your comment makes it sound like you're lecturing. Maybe this wasn't intended.

Assuming the addition way of generating a joint key is secure (which it is, as far as I know), then you can do this symmetrically. Both generate a private key, calculate the public key, and then send the public key to each other. The public keys added are the total public key.