You are right Piotr, it can be made into a standalone wallet (and I expect others to do just that once the OtherCoin card is released). My focus right now is completing development on the JavaCard smartcard side and adding compatibility with the standard Android Bitcoin wallet. But I am also the author of VisualBTC (https://bt.irlbtc.com/view/210371.0) so at some point in the future I could also try to merge the two. I'm just taking it one step at a time .

I've been waiting for this....   https://bt.irlbtc.com/view/147933 ... and so it begins.

I'll make a prediction here-- the popularity of off-line transaction will mean that bitcoin fees never peak above 200 BTC/day averaged over a month.  In fact they may have already peaked-- more people use bitcoin now than ever before and yet the fee's have never passed 100BTC/day at seven day rolling average and seem to be declining when averaged over longer time spans. ( http://blockchain.info/charts/transaction-fees  )

Once electronic schemes like become popular for smaller amounts and large off-chain bank-like transfers for larger amounts there will be little reason for anyone to use on-chain for normal commercial transactions.

And these people include almost everyone here,  indeed I'll speculate and assume you yourself have participated in an off-chain transaction. 

Ask yourself this question: "Have I ever used an exchange to buy or sell bitcoin?"-- cause if you have then it most likely involved an off-chain transaction.

In the case of the OtherCoins, we're definitely not "holding bitcoins on the user's behalf". They're Bitcoins and remain Bitcoins, accessible at any time without contacting any external servers. The idea is to just allow them to be passed on to another person without going through the blockchain, but they can be used on the Bitcoin network just as easily - the OtherCoin smartcard simply makes sure that you can only do one or the other - it keeps parties honest, it doesn't hold your bitcoins.

If you read this thread, you'll see that it doesn't have the notion of Bitcoins and balances and doesn't even know what address you're using.

Thank you beeblebrox! My answer was directed at justusranvier, I was just explaining that we do not hold our users' bitcoins in any way and we have no idea if/when transactions take place and what the value of those transactions is.

I don't think it's going to be an "all or nothing" situation - I'm definitely not trying to replace the blockchain transactions, I am trying to augment them. Just as beeblebrox said, whenever they need anonymity or instant confirmation, people will pay off-chain. For large amounts and high security, they will go to the blockchain. For instance, I fully expect merchants to "redeem" their private keys onto the blockchain every now and then.

The "off-the-blockchain" transaction chain could be shorter or longer depending on how much you trust the system and how anonymous you want/need to be. This is why I'm trying to make it clear what the system knows and what its capabilities are and intentionally limit its abilities in order to prevent it from being abused by the issuer (which could be us or a licensee).

My main concern is on malware - the Payment Protocol (as hard as it is to implement properly on a secure device, IMHO) provides a way to address that, while this would create another trust issue to be solved.

Overall the idea looks interesting - there's some significant chatter those days about using smartcards as generic certified key generation devices - such as Fido/U2F https://sites.google.com/site/oauthgoog/gnubby - and this fits right in.

On a side note regarding smartcard platforms, I've done some research on the existing and open (as in, you can buy them right now without NDAs) Java Card that would be suitable for bitcoin applications and JCOP 2.4.2 looks nice (supporting Elliptic Curve key generation, SHA256 and ECDSA with SHA256) - it can be found on the Yubikey Neo. I've ported the BTChip application to it as a proof of concept and will be releasing the code shortly with a GPL license.

Right, but I think that's easily solved by having the physical wallet boot in Payment Protocol only mode, and require a user action (physically on the wallet itself) to reenable the old insecure behavior.


Not to turn this thread into a Java Card support party, but do you have the same behavior if you get/initialize the signature object when the applet is created ? I'll make some tests later and move that to Yubico forum.

Also, paying by sending a private key allows for some very interesting form factors for the hardware wallets. Right now, the wallet needs to be able to read or receive the address of the recipient (so it needs a camera to read a QR code or an NFC reader or Internet connectivity). If payment is done by giving away the private key, the wallet no longer needs to "read" anything from the payee and payment can be prepared in advance, without knowing the final destination address. It's also safer since the payee has no way to inject any code/data into the wallet, it never sends it anything.

I was actually thinking of writing a wallet for these: http://wyolum.com/projects/badger/ - you would sync the wallet with the blockchain via USB once a day or so, then all payments would be done by simply selecting the amount using the 5 on-board buttons, then displaying a QR code containing the payment transaction to an address generated by the wallet and the private key associated with that address. The recipient would scan it, post the payment transaction to the blockchain, then post a second transaction sweeping the funds to whatever address it uses.

Just my 2 cents - this would be something separate from OtherCoin but equally interesting.

If anyone's interested, I have completed a first version of the OtherCoin app (both the smartcard applet and an Android demo app).

The Android demo app can access 3 types of smartcards - a microSD internal card, a Bluetooth-based smartcard reader (namely this one: https://www.certgate.com/products/cgtoken/) and an NFC card (tested on the Yubikey Neo).

As mentioned in the whitepaper, private keys are generated by adding together two halves - one generated by the card and another one generated by the smartphone. This way the OtherCoin card never has access to your private key but can still guarantee the security of the system by keeping its half private.

The Android app can add new keys (that is ask the smartcard to generate them), request a BTC transfer (ask the card to send its signed public identity that the other card can verify to make sure it's talking to a legit card) and scan a response from the other smartphone (that contains the encrypted Bitcoin private key to import). It uses QR codes for the communication but it could be adapted to use Bluetooth, WiFi or just about anything else.

I've modified the protocol a bit to use ECDH key exchanges instead of RSA (that is the two parties now negotiate a symmetric encryption key using their EC public identities and use that to transfer the Bitcoin private key). RSA was just way too slow and keys were too large to fit into a decent (=readable) QR code.

Finally, it integrates with the Android Bitcoin Wallet to add funds to a specific OtherCoin key (it starts the Bitcoin Wallet with a prefilled destination address - you can see this in the demo movie at around 1:03) and to reveal a key (that is remove from the card and import it into the Bitcoin Wallet for use on the blockchain - see the demo movie at 0:35).

The video is at http://youtu.be/YXGOGMnRx2Y , it probably needs some annotations here and there, I will add them in the coming days.

Feel free to comment and ask questions. The Android app will be open-source to show you how to interact with an OtherCoin card (either via microSD, Bluetooth or NFC) and we're going to need some testers soon. The app is fully functional, everything described in the whitepaper is there and appears to be working fine.