Off-chain anonymous transactions by secure transfer of private keys

[piotr_n]

Does that answer your question? You can't go completely without a wallet, you would need at least a screen and some network connectivity. But the wallet will not be a specific wallet, any wallet should be able to just send/receive requests to/from the card. It's a simple library to send/receive APDUs (http://en.wikipedia.org/wiki/Smart_card_application_protocol_data_unit) through filesytem operations.

Yes, thank you - it does answer my question.

Though I disagree with the part that a card cannot go without a wallet.
I believe a card can be a wallet and the authority certifying it's software can be both; a great business model and a great invention for the masses.

And BTW, this thread is the best offline bitcoin payment solution/proposal/debate that I have seen so far.


Yes, I understand that a card does not have a display, not OK/Cancel buttons - thus it cannot be a wallet per se.
But if you sell it together with a secured terminal - the card in such a terminal is the wallet.
The wallet that is quite secured, IMO, and most important: one that can be used offline.
You trust the smart card telling you how many bitcoins are protected by a private key that it is giving to you...
And the card itself does not need to be familiar with bitcoin protocol whatsoever - it's just a simple wallet.

[1713876411]

1713876411

[1713876411]

1713876411

[drazvan]

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://bitcointalk.org/index.php?topic=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 .

[piotr_n]

Sure.
Take your time and good luck with your projects!
They look promising - far more promising than bitcoin 0.9

[beeblebrox]

I've been waiting for this....   https://bitcointalk.org/index.php?topic=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.

[justusranvier]

I've been waiting for this....   https://bitcointalk.org/index.php?topic=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.

Off chain transactions are only suitable for people who don't require certainty as to actually owning the bitcoins they think they own.

[beeblebrox]

Off chain transactions are only suitable for people who don't require certainty as to actually owning the bitcoins they think they own.

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.

[justusranvier]

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.

That depends on how how you define the boundary of a transaction.

In my case, there is nearly a 1:1 relationship between off-chain transactions and blockchain transactions related to buying and selling Bitcoins.

For example, when I purchase via Coinbase, they first allocate some of their bitcoins reserves to me via an internal database operation, which could be considered an off chain transaction, but as soon as those bitcoins are accessible I immediately withdraw them to my own wallet.

As far as I'm concerned, I'm not performing any off chain transactions because I never consider the purchase complete until the bitcoins I have bought move on the blockchain to an address I control.

I understand that several startups have a strong financial incentive to push a different paradigm, to convince users to let them hold their bitcoins on their behalf. When they inevitably steal/lose/confiscate their user's funds I won't be affected.

[drazvan]

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.

[beeblebrox]

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.

I'm not sure if this reply is directed at me or at  justusranvier.  If it was at me,  I would like to say that I do understand what you scheme is: it is very similar to this one that I outlined as an example of an electronic off-chain transaction using DRM on personal computers and phones- https://bitcointalk.org/index.php?topic=148232.msg1578079#msg1578079 (elsewhere in that thread I even say that it is possible to use smart cards).

The reason I mention bank-like off chain transactions above was because for most people conducting off-chain transactions with large amounts of money they would prefer the safety and reassurances that a bank like institution provides (eg: similar to how in the real world not many every day citizens by new cars/houses/businesses with cash-- they use bank cheques and the like).

Local off-chain electronic private key transfer is a great alternative for smaller items and would appeal to the masses, it would be very convenient for transactions like buying groceries and petrol etc.  Most people would accept the security risk associated for small amounts like this (eg: in the current fiat world few people here in Australia have reservations loading bus cards with a $20-to-$100 or so).   However, personally I wouldn't use private key transfer for anything more than a few thousand and I think will you find that many people wouldn't even use it for that much-- maybe just a few hundred.

There is a real need for your scheme and it is a great development.  Previously I've offered 50BTC for an open-source smart phone version for secure private key transfer, however at the moment smart-phones don't seem to have the necessary hardware-- Samsung KNOX comes close.  So I'll pledge 15BTC to your smart card idea on successful completion and public release (non-open source accepted).
  

[drazvan]

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 understand that several startups have a strong financial incentive to push a different paradigm, to convince users to let them hold their bitcoins on their behalf. When they inevitably steal/lose/confiscate their user's funds I won't be affected.

[justusranvier]

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.

My comment was not specific to OtherCoin.

In general though, I don't expect any services that provide weaker security guarantees than blockchain transactions to survive in the long term. As more value moves into the ecosystem the incentive to steal will grow, and the thieves will target the softest targets first.

I could be wrong, but I think the blockchain is a case where we must put all our eggs in one basket.

[drazvan]

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).

[drazvan]

There's also another very interesting application for this technology/idea: Bitcoin addresses are anything but human-readable and since they are supposed to change with each incoming payment, there's no chance for the user to remember them.

The Bitcoin Payment Protocol (https://en.bitcoin.it/wiki/BIP_0070) addresses this concern by allowing payment requests to be signed using standard X.509 certificates. However, this requires the Bitcoin client to redo all the work that the browser has already done when accessing the site over HTTPS, present the certificate to the user for verification, etc. Browsers already do that and have done it for years and people are starting to get used to the iconography and visual cues that come with this process ("green lock", "green address bar", various warnings in the browser that the certificate doesn't match, etc).

So I was thinking that we could reuse this knowledge and leave the verification and the UI to the browser and the user. People already know how to check the certificate and ensure that they're not sending money to a phishing site. When they enter their credit card number on a site, they only have to check that the site is genuine, not check the merchant's bank account number or ask the bank to confirm that it really belongs to the merchant.

Users could simply pay by entering the private key of a Bitcoin address holding the funds in a text field on the site (just like they enter their credit card details) after they verify that the site is genuine. It would then be up to the merchant to sweep the funds to the correct address. This would also make it a lot easier to track down payments since they would no longer have to match incoming payments from the Bitcoin network to invoices/payment requests issued over HTTPS.

This could also work in face to face transactions - you would give the key to the other person after you are personally satisfied that they are who they say they are (or ask them for an ID if you don't). I guess what I'm trying to say is that people (and their computers) are becoming pretty good at identifying sites and other people, so maybe we should reuse that knowledge.

What do you think?

[btchip]

So I was thinking that we could reuse this knowledge and leave the verification and the UI to the browser and the user. People already know how to check the certificate and ensure that they're not sending money to a phishing site.

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.

[drazvan]

The problem with the payment protocol and malware is the one I described on the Trezor thread ( https://bitcointalk.org/index.php?topic=122438.msg3448363#msg3448363 ). Basically, browser malware could simply strip the payment protocol parts and change the destination address. Since most individuals and some of the merchants will not have certificates, the wallet cannot simply refuse to pay to addresses that do not present a certificate.

So it's basically safe if you absolutely know that the merchant implements the protocol (so if it presents the wrong cert or no cert at all, you do not pay them) but kind of useless to secure interactions with merchants you've never used before or individuals.

The YubiKey Neo is a great tool for development, I've actually used it to test the OtherCoin code over NFC. It does have some problems though with RSA key generation and randomness - see my thread on the Yubico forums at http://forum.yubico.com/viewtopic.php?f=26&t=1207 .

[btchip]

The problem with the payment protocol and malware is the one I described on the Trezor thread ( https://bitcointalk.org/index.php?topic=122438.msg3448363#msg3448363 ). Basically, browser malware could simply strip the payment protocol parts and change the destination address. Since most individuals and some of the merchants will not have certificates, the wallet cannot simply refuse to pay to addresses that do not present a certificate.

So it's basically safe if you absolutely know that the merchant implements the protocol (so if it presents the wrong cert or no cert at all, you do not pay them) but kind of useless to secure interactions with merchants you've never used before or individuals.

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.

The YubiKey Neo is a great tool for development, I've actually used it to test the OtherCoin code over NFC. It does have some problems though with RSA key generation and randomness - see my thread on the Yubico forums at http://forum.yubico.com/viewtopic.php?f=26&t=1207 .

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.

[drazvan]

So it's basically safe if you absolutely know that the merchant implements the protocol (so if it presents the wrong cert or no cert at all, you do not pay them) but kind of useless to secure interactions with merchants you've never used before or individuals.

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.

That only works if the majority of the merchants support the Payment Protocol. Otherwise the user will receive the "insecure payment" warning a lot and will eventually disable it altogether since most of the time it simply means the merchant (or individual) being paid does not run the protocol rather than something fishy going on.

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.

Yes, that's precisely when it happens (when the Signature object is initialized when the applet is created). It does _not_ happen if the signature object is created right before signing. Thanks for your help, I would appreciate it if you could give it a try, let's move that part to the Yubico forum though, as you suggested.

[drazvan]

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.

[drazvan]

I've described how private key transfer could be used in person to person transactions (between trusted parties) or by online merchants - even in the absence of a secure chip - in this thread: https://bitcointalk.org/index.php?topic=329320.0 .

I plan to make this a part of the OtherCoin ecosystem at a certain point - if the recipient supports OtherCoin off-chain transactions, the key will be securely pushed to him that way. If he doesn't support it, payment can still take place by a transfer of private keys, if said key is encoded in a short human-readable phrase (a PayPhrase) that can be read over the phone or simply typed in an input field on a website.

I hope to see a future when Bitcoin addresses will go the way of IP addresses - they're still the basis of communication but nobody uses them directly or types them into anything. Humans are not meant to read those and I think the same applies to Bitcoin addresses.

[drazvan]

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.