Of course, this doesn't mean I can't add a password or a PIN into the mix - but I wanted to minimize the amount of extra information needed to claim the funds. If I have a channel to securely send you an extra PIN or password, I might as well send you the whole key.

And for storing personal funds, I wanted to be able to take a picture of my family for instance, then secretly add some funds to it, then tell my daughter when she's older to look for that family photo and find a little "surprise present" in it if she knows where to look .

The hash of the image is the key, so no, it's not encrypted. The recipient is not meant to leave the funds there indefinitely, I expect them to sweep them to their own wallets on receipt. And unless an attacker has access to your email and starts hashing all image attachments and checking the blockchain for a match, they would not even know you're sending (or receiving) money.

Also, if you're using this to store your own funds, it's similar to a brainwallet - that is not encrypted with anything either . But instead of remembering it, you just save/secure an image that hashes to the key. It's not as secure as a true 256-bit random key and it's not meant to be - it's just way easier to covertly store and transfer.

What version of Android are you running? It should install all the way down to 4.0.3. I have only tried it on 4.3 and 4.4 myself, but it's declared to support everything above 4.0.3.

I haven't thought about making this for altcoins, it shouldn't be too hard, as long as there's interest and the altcoin private keys are 256-bit values (or smaller, I can truncate the output of the SHA256 hash), they should be fine. And yes, it will eventually be open-sourced, just need to clean up the code a bit (it was essentially hacked together over the Easter holidays, it works fine but it reuses parts of my OtherCoin and VisualBTC projects).

Yes, anyone that has access to the image has access to the funds. The trick is that the image is not modified in any way, it's just an image, so an attacker that finds your phone would not know where to start (or even know that you've used this at all), unless they start hashing any and all images found on stolen phones to look for funds .

BTW, over the Easter holidays I tried to get away from the OtherCoin project and clear my mind a little bit, so I wrote this: https://bitcointalk.org/index.php?topic=586830 . Now I'm back to the serious stuff.

Hello everyone,

I've just published a small Android app called "Show Me The Bitcoin!" that allows you to use any image in your phone gallery as a Bitcoin private key and wallet. You can add funds to an image using your regular wallet, email it to someone else and claim/sweep funds received from a third party in the form of a simple image email attachment.


Possible uses are:
1. Covert transfer of funds (to an outside observer you are simply emailing that person a funny photo).

2. Hidden Bitcoin storage (add funds to a personal image in your gallery and remove the Bitcoin wallet app). If your device is searched, they will find no trace of Bitcoins, just a few personal photos in your Gallery. At a later time, you can reinstall the app and reclaim the funds.

3. Bitcoin shared wallet for family/friends (anyone with access to the image can claim the funds and also deposit funds on that image for use by other members).

4. Reward website users by hiding Bitcoins in images on your blog / website (scavenger-hunt style).


Here are a few screenshots:






A demo video is at http://www.youtube.com/watch?v=rTmnLlyUjHQ.

Give it a try at https://play.google.com/store/apps/details?id=com.cayennegraphics.showmethebitcoin , it's free! It will nag you after you've sent $50 (0.1 BTC) or more through it for a donation, you can donate as much (or as little) as you want or not donate at all, your call. Or you could send directly to 1Razvan4KEK2q5DNxemvsHwGncF1T3NqR .

For the technically inclined, the way it works is by doing a SHA-256 hash of the image and using that as a Bitcoin private key - it derives an address from it, then allows you to send funds to that address or sweep them to your wallet. Nothing fancy, just pure old fun .

Finally, if you've read this far, I have a tip for you: I've hidden 3 small amounts (0.05 BTC) into 3 logo images present on Bitcoin-related sites (or vendors related to Bitcoin). So you just need to navigate to the site, save the logo image and then load it into Show Me The Bitcoin! to sweep the funds (or add more if you're into that sort of fun ). I will post tips and possibly more bounties here over the next days, feel free to join in.

Cheers,
Razvan

Hey beeblebrox, good to have you back!

Right now, each key takes 32 bytes (the private key) + another 32 bytes stored as an encrypted blob (that is actually the half of the key that the phone knows, encrypted with AES by the phone). That blob is used to be able to move the smartcard between phones and re-build the OtherCoin key database if you only have the card (and a master password). The blob is not mandatory, but the current Android OtherCoin implementation uses it, so let's assume 64 bytes/key.

The current microSD smartcards we use have about 144K of storage (chip is NXP J5C145_M3) and the OtherCoin app itself is probably around 4K or so (haven't checked exactly). So 140000/64 = 2187.5. So you can safely assume that you can store about 2000 keys in the app - that would prove to be a bit unwieldy at this point with the current OtherCoin Android app since it shows them all to you and you choose the ones to transfer. Once we automate the process it will become easier. I think most people will have 100 keys or less in the system at any given time though.

As a status report, we're waiting for all 3 (yes three ) hardware manufacturers we use to fix their products. There will be 3 form factors for the OtherCoin product - a microSD card, a Bluetooth Low Energy keychain-style dongle and an actual Android device with a real (SIM-sized) smartcard inside. We're waiting for a new firmware from the microSD manufacturer to support Android 4.4 KitKat (current version does not work with KitKat and units cannot be upgraded in the field, so we would have had to recall them for an update or mail everyone new units). The Bluetooth Low Energy dongle will be available mid-May (around May 20th or so we've been told). The Android device has a bug with long-running smartcard operations (it times out too soon) and the manufacturer is supposed to send us an updated firmware next week.

I'm trying to make sure everything works on the smartcard side since that's very hard (if possible at all) to upgrade in the field. On the Android side we can always push an update through the Play Store if we find any issues. The app itself appears to be rock-solid, it's just these last minute interface bugs that drive me crazy. They have nothing to do with OtherCoin itself but with the way smartcards are read by the OS.

Thanks Peter! In all honesty, I haven't had the time to look into the timestamping issue yet, thanks for the suggestions! I'm trying to keep the initial release as simple and as "blockchain agnostic" as possible. All it does for now is secure private keys, it has no notion of blockchain/transactions/ECDSA/etc, so it can be easily reapplied to just about any other altcoin that uses private keys (are there any that don't? ).

I need to get the marketing materials done so I will probably stop adding features for a few weeks and focus on getting it launched. There's always room for a version 2 .

Regarding the PIN, it's 4 digits / 3 tries. It's sent encrypted together with the private key and stored as an OwnerPIN JavaCard object (those are especially protected by the JavaCard runtime). You get 3 attempts to unlock the key - if you fail, the key is permanently blocked (I should probably make it delete it at that point to save space and prevent further attacks).

Thank you! What do you think it would take to make it go from Good to Great? Any specific features you'd like to see?

If you look at the phone interface in the video you'll see that the owner can declare the location of the card (if he wants to). It's declared as RO ("Romania") in the video. This allows you to select cards from your own country (or the same region, like the European Union).

But yes, your bank will think you are travelling a lot - they might call you a couple of times to ask if you've authorized those transactions - you can say yes and that should be the end of it.

The location is whatever the owner declares, it's not based on the issuer of the card. That should allow you to declare your location as China for instance if you plan to do a lot of trades/exchanges with users in China - you can proactively call you bank and tell them you will be travelling to China and that they shouldn't be worried about transactions coming from there.

Thanks for the feedback!

A quick status update: OtherCoin is progressing nicely, I have cleaned up the protocol a bit and added the ability to send PIN-locked keys. A locked key is transferred just like any other Bitcoin key in the OtherCoin system but it's also protected by a PIN. Without the PIN, the recipient is unable to spend it or transfer it to another user. This allows a primitive type of escrow - once a key is transferred, the sender no longer has it but without the PIN, the recipient cannot do anything with it (other than verify that it exists and has funds on it). So the two parties have to agree in order for the recipient to obtain the necessary PIN to unlock the key.

I'm still working on the final packaging for the cards and their associated microSD readers (we will include a reader in the package for each card - for phones that do not have a microSD slot). On the Android side we've hit a bit of a problem with Android 4.4 KitKat - https://code.google.com/p/android/issues/detail?id=67406 . This prevents OtherCoin from working on Android 4.4 since the phone can no longer talk to the card. The miniature Bluetooth card readers that we plan to offer as an alternative (see http://www.certgate.com/products/cgcard/ ) will only be available in May, so one way or another we'll have a working solution for Android 4.4 by mid-May.

Finally, another important part of the OtherCoin ecosystem has been prototyped - the Card2Coin system I described here: https://bitcointalk.org/index.php?topic=339389 now has a prototype and a demo movie at https://www.youtube.com/watch?v=ZsOzeELdjxM . It's a distributed BTC/fiat exchange based on the idea of remotely charging someone else's credit card in exchange for your Bitcoins. This will eventually be integrated with the OtherCoin system, allowing you to buy Bitcoins, transfer them and sell them for USD _within_ the system, without ever touching the blockchain or any of the centralized exchanges, while still preserving your ability to go through the blockchain at any time.

(God, I picked the wrong day to announce this ). This is NOT an April Fool's day prank, this actually exists and works as seen in the video . Donations are welcome if you'd like to see this happen sooner ( 1Razvan4KEK2q5DNxemvsHwGncF1T3NqR ).

Hello again everyone,

I have finally completed the prototype for this idea and posted a quick demo video on YouTube at https://www.youtube.com/watch?v=ZsOzeELdjxM .

The video shows a contactless MasterCard card connected to a Raspberry Pi and allowing remote users to charge it in exchange for BTC. At the terminal, there's a Nexus 5 phone that relays requests from the POS to the card over 3G / Tor. In the video you see the screen populate with the information as the terminal sends it to the card and as the card replies. You'll see the credit card number, expiration date, the amount being charged, the currency and so on.

As soon as the phone has enough data to determine the amount the terminal wants to charge, it starts the Bitcoin client so that you can pay the corresponding amount in BTC. When the BTC payment is complete, it notifies the Raspberry Pi that acts as the credit card proxy. The Raspberry Pi verifies the transaction and if the amount in BTC is sufficient it allows the remote terminal to charge the card (if you're familiar with the EMV protocol, that's the GENERATE_AC command - it never reaches the card unless a corresponding BTC payment has been sent).

Both the phone (Nexus 5) and the Raspberry Pi use the TOR network (https://www.torproject.org/) to communicate to preserve anonymity. Also (since I'm sure someone will ask), there is not enough information sent over the wire for an attacker to clone the card. Magstripe transactions are also blocked because for those the actual amount being charged is not sent to the card, so Card2Coin has no idea how much you want to pay and what is the corresponding BTC amount to charge.

The beauty of this system is that it can form the basis of a distributed BTC exchange by allowing you to charge someone else's credit card in exchange for your BTC. You buying habits are hidden (since you would use a different card, potentially from a different country or continent, for each purchase). The TOR network hides the location of the parties. Finally, transactions made through this system show up as "card present" (the POS in the store thinks it's talking to a physically present credit card), so they cannot be easily reversed (if at all).

Feel free to ask questions, I'm sure there will be quite a few.

Is this still available? I'd like to get one, shipped to Romania.

Thank you!
Razvan

Thank you Peter, I'll look into those paywords, I wasn't aware of that system. Smartcards do not have an internal clock, so I was initially thinking of using a certified time source (that is a web service that accepts a nonce and returns a signed time+nonce packet indicating the current time), but if this could be done in a distributed fashion it could be interesting. I'm not sure how that would work though, how would you limit the amount being transacted or do you only suggest limiting the number of transactions that a card can do in a given time interval?

I am trying to keep the on-card system as simple as possible and only use cryptographic primitives that the chip manufacturer (NXP) has certified against various attacks (SPA/DPA). They have an entire document that describes how those primitives must be used in order to maintain security.

Adding on-card processing in JavaCard can be extremely slow and can leak information, that's the main reason why I haven't implemented Adam Back's suggestion to change the private key halves every time they are exchanged by adding a random value on the smartphone and subtracting the same value on the card to make sure that previous owners of a key cannot steal your smartcard and use the key half they used to know to reconstruct the Bitcoin key. JavaCard has no native BigInteger implementation and rolling our own would require careful testing against timing and power analysis attacks.

I am also trying to make this as independent of third party Internet services as possible. Certified balances (like btchip suggested) are going to be there, but they will be optional (you will always be able to just lookup the balance on the blockchain).

And yes, you are right about the granularity problem, you could either have smaller amounts on different keys or just send _most_ of the amount over OtherCoin and then post a transaction on the Blockchain to "split" a certain key into two (a remainder to pay and a change, sent to another OtherCoin address). I expect wallets to manage this the same way people manage their cash in large denominations. Merchants could also calculate a change amount and return it to the payer via OtherCoin (they don't care as much about their anonymity, so they can easily post to the Bitcoin network to split large OtherCoin keys into smaller ones or fund new keys with small change amounts).

Thanks for the feedback!
Razvan

FYI everyone, I've posted a message on the OtherCoin thread about that blacklist / transaction history issue we talked about above. It's at https://bitcointalk.org/index.php?topic=321085.msg4915443#msg4915443 . The short version is that we decided to not implement this at all in order to protect the privacy of the OtherCoin users (if we cannot extract the history of a certain private key, neither can law enforcement or anyone else - it's not a matter of encryption, the info just isn't recorded anywhere).

Hello everyone,

Just a quick update on the software side: the initial plan was to have each OtherCoin keep track of the history of each received Bitcoin private key in order to be able to help with identifying a potential attacker that had managed to crack one of the cards and extracted its private key, allowing him/her to attempt double-spends (either simultaneous spends in the OtherCoin system or spending a key in OtherCoin and immediately spending the same key in the Bitcoin network).

After careful consideration, I've decided _not_ to implement this. Allow me to explain:

1. The main purpose of OtherCoin is to allow a way to _privately_ transact Bitcoins, without any traces in the blockchain or anywhere else. If we would be able to recover the history of a certain private key, someone else could do it too (or they could force us to do it for them). The easiest way to make sure the payment history cannot be recovered is to simply _not_ record it anywhere.

2. Provided that we don't make any stupid mistakes in the actual protocol (and we're going to make extra sure we don't), OtherCoin would only be vulnerable to physical attacks to the smartcard chip. Those are extremely expensive and require very specialized equipment and labs, not something your average script kiddie would have. The estimates I've seen were in the range of a few hundred thousand dollars in costs to attack / recover keys from a single card.

An attacker that manages to defeat one of our cards would only find his/her own private key, essentially allowing him to attempt double spends. However, to recover the high cost of the key recovery process, they would either have to attempt to double-spend a huge amount ($100k for instance) or a lot of smaller amounts (let's say 1000 payments of $100 each). As much as I'd like to see OtherCoin used for payments of hundreds of thousands of dollars, most recipients would probably immediately drop the transaction onto the blockchain to get it confirmed, so the attacker would no longer be able to double spend. For the 1000 * $100 scenario, the attacker must have 1000 people to transact with and hope that all of them do _not_ attempt to spend the OtherCoin Bitcoins on the blockchain before he's done (and none of the 1000 can identify him).

3. I suspect that if someone would ever attempt to crack an OtherCoin card (in the physical, expensive way), it would be the NSA or a similar govt funded entity. These entities would most certainly not do it in order to double spend anything, they would do it in an attempt to trace payments or identify persons/entities behind the OtherCoin addresses. However, if the cards do not contain any history information, an attacker would have nothing to gain by cracking a user's OtherCoin card (other than gaining access to his/her private keys and possibly spend the funds associated with those keys - something they can probably obtain with a $5 wrench - http://xkcd.com/538/ ).

I would be happy to hear your pro/con arguments. I realize that not implementing this makes us "deaf" in case of a successful crack of an OtherCoin card. We would know it has happened (the double-spend would be visible), but we would not know who has done it (unless we work our way backwards from the current owner of the key and count on them knowing/remembering who they got the key from, then rinse and repeat). But the upside is that there is no payment history, not in the blockchain, not on the card and not anywhere else. There's nothing for us or anyone else to extract, the info is just not there.

Let me know what you think.

Thank you Beeblebrox! Yes, that is correct, you can transfer the private key over OtherChain as many times as you want (as long as you feel comfortable). If at any point you have reason to believe something fishy is going on, you can ask the OtherCoin card to reveal its half of the private key - from that point on it's just a simple Bitcoin private key, so you can sweep the funds to your wallet or do anything else you want.

Private message sent with my email Beeblebrox.

Yes, it does so now. The encrypted Bitcoin key it receives is also signed by the sender card (see below for details). Of course, if you compromise the card and extract its private key, you could sign Bitcoin keys that you've created outside the card (that you can later attempt to double spend).

However, this offers little reward for considerable effort. There's nothing stopping a recipient of funds from immediately running them on the Bitcoin network (and I actually expect people to do just that for higher amounts). So if you spend tens (if not hundreds) of thousands of dollars compromising a card to do a double spend and then the first person you try this on sends your transaction to the blockchain, you've accomplished nothing and lost a lot of money! Also, the wallet apps will monitor the blockchain for any transactions involving addresses they hold the keys to. If at any point they see money going out of an address they own, they should raise an alarm and report this to us, so it's not something that can be done "silently".


Each OtherCoin card has two keys used for encryption - one is a symmetric key (that all cards share) that is used for privacy (each outgoing message is encrypted with that shared key with a random seed (initialization vector) ). This hides the identity of the person sending the funds (so you could transact with the same person twice and not know that). It also makes things a bit harder for people that try to attack the card (since it's harder to craft meaningful messages to the card - you have to properly encrypt them, otherwise the card will drop them immediately since they decrypt to a bunch of nonsensical data).

However, the security of the system is given by the second key - it's a public/private keypair, generated by the card itself. It used to be RSA but now it is an Elliptic Curve key. Each card has a different one and it is used in an ECDH key exchange (see http://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman). Card public keys are signed by our master private key (that is obviously NOT present on any card, it's actually on a smartcard connected to an offline computer, each OtherCoin gets provisioned/signed there).


Not at this point, but that's planned. With a bit of luck, this will actually be ready when we start selling the cards (in a couple of weeks). We will provide a signed blacklist of compromised public keys that each wallet can optionally download and send to the card (since the wallet receives only encrypted messages, it can't tell what public key the other OtherCoin card has).

To summarize, there is very little reward in compromising a single OtherCoin card. You would have to crack the shared key, then crack the private EC key and all that would give you would be the possibility to spend funds you already have twice (not create money out of thin air), while hoping and praying that the recipient doesn't post them to the blockchain or does not raise the alarm when you double spend them (and they see a transaction involving the keys they currently hold).

Keep in mind that these are EAL 5+ level cards that are certified for use by Visa, Mastercard and a bunch of governments. I'm not saying a well funded attacker cannot break one, but all they would get would be the private key for their card, allowing them to double spend funds they already own, in a very public way. I'm sure there are better ways for someone that has the technical ability to do this to make money .

The recipient of the funds receives two keypairs: the one that the payer's smartphone has generated and the one the payer's smartcard has generated. The one from the smartphone is in the clear, he can take a look at it. The one from the smartcard is encrypted and can only be decrypted by the recipient's OtherCoin card. The payee imports the secure (encrypted) half into his OtherCoin (the OtherCoin verifies that the encrypted key came from a similar OtherCoin card). If the OtherCoin card has accepted the encrypted half, the user can be sure that the sum between the key that he holds and the key that the card holds is a private key for the funds and that it hasn't been used before.



The recipient gets the key in an offline transaction. The only thing he can't verify offline is the balance (how much that key is worth). He knows for sure that he holds the key to a particular Bitcoin address (he just doesn't know what that key is, half of it is stored in the OtherCoin card). Part of the OtherCoin service will be "certifying" balances for people that want to transact completely offline. Most users however will just look at the blockchain to see how much a Bitcoin address is worth.


Yes, they obviously can transfer it away, to a similar OtherCoin card. The guarantee comes from the fact that each and every OtherCoin card in the chain verifies that the sender is also an OtherCoin card, meaning that it has followed all the rules of the system (has not made copies of the key, etc). Think of it as a tamperproof computer sitting inside your smartphone - it guarantees that all participants in the protocol follow certain rules and even though it runs inside your smartphone you can't control what it does.


No, a key is either transferred via OtherCoin to a similar card or revealed to the user to be used in a Bitcoin transaction. It's either one or the other, as soon as the card gives you the secure part of the private key, it destroys it from its storage, so it can no longer be transferred via OtherCoin. It also destroys it as soon as it's transferred to someone else via OtherCoin.

So, to summarize, the security comes from the fact that all participants use the same hardware and software and that they cannot change the way the software works. They can't change the software to tell it to _not_ delete a private key after sending it or tell it to reveal its keys. It's a black box as far as the smartphone is concerned, you send some input to it and gives you some output, you don't control how it processes your input. What it does though is fairly public, it's described in the whitepaper and I can describe it further if needed.