Hmm, why are you doing stuff with EC math directly rather than using OP_CHECKMULTISIG? The latter is much easier to verify as correct.
Is there a way that's easier for the non-technical buyer to verify as correct? Last time I revisited multisig transactions, they had to be constructed in hexadecimal using bitcoind and RPC calls, but I could be behind the times on this. The buyer sophisticated enough to do this may well just manage his own wallet - the imagined typical buyer for an item like this is non-technical and prefers to have some sort of legal recourse that it performs as expected and then trust me in that respect.
The non-technical buyer has the option to verify that my public key times his private key also yields the same bitcoin address with my utility.
I agree that multisig is fundamentally better - it adds ways to take away the possibility that he gets scammed by malware while combining his two keys and allows outsourcing of part of the process without compromising security.
What exactly is the benefit of the coin? You lose the printout, you lose it all. Just like before, when people may use a paperwallet.
The benefit of the original Casascius coin was, for me, to have the funds in a, well, coin? Which may or may not be more robust and easy to lose than a printout..
This is more a functional proof of concept.
Here might be a perfect prototypical use: A charity wants to accept bitcoin donations, but the executives or controller don't want to delegate any ability to touch or handle money, but also aren't technically oriented. They shove a 2-factor physical coin in the safe and publish the address as the "we accept bitcoins" donation address, not wanting to deal with any technical challenges involved in accepting Bitcoins today, but aware that if they start receiving large donations on it, they know they can figure out a way to get them off (even if it's sending it via overnight courier to FastCash4Bitcoins or BitPay and getting money in their bank). In their mind, they're buying a pre-made bitcoin "account".
If I were to produce a presentation box for this bar (sort of like I have for the silver coins) where the box itself had a slot for the piece of paper, then keeping them together would be much more sensible. Ditto if I were to make a new version of the piece that fit the profile of an off-the-shelf presentation box (e.g. something in the form factor of my silver coin, but made of cheaper gold-plated metal like my 25BTC coin, where the user could stuff that extra piece of paper into the acrylic capsule). In such an event, I could provide the utility that pre-printed THEIR private key on a round piece of paper they cut out and shove into the capsule, or try to provide for others to do the same (e.g. get BitAddress to add private QR code to the vanity page so a buyer could cut it out).
Finally there is no reason their private key even has to be a randomly generated key. It could be a password/passphrase turned into a private key with a very expensive KDF. Since redeeming the bar is a once-in-a-blue-moon event, the KDF could be chosen to need seconds or minutes to run, providing reasonable security even without requiring brainwallet-quality passphrases. (the space of potential attackers is pretty small - 1 - me)
I downloaded the btcaddress utility but I dont see how to use the keycombiner. There is a source.zip file in the main btcaddress.zip
Do i have to unpack both in the same folder? How to start the combiner?
It's in btcaddress-alpha.zip. btcaddress.zip is a more stable release lacking this functionality. I'd like to do some more testing on it before seriously telling people "go put 1000's of BTC's on an address relying on the output of this mostly untested program".
