Off-chain anonymous transactions by secure transfer of private keys

[drazvan]

I have spent the past few days polishing the UI and adding the ability to send/receive the keys over SMS. I am deliberately trying to avoid sending the keys over the Internet in any way - to make the transfer less likely to be noticed by someone looking at Internet traffic. SMS goes only through the facilities of the GSM operators while QR code goes nowhere (it's strictly screen to camera).

I will try to post another demo movie in the next few days to show off the new UI (new icons, less text) and demonstrate an SMS exchange.

I have also deliberately avoided exchange protocols over NFC and Bluetooth to keep the technical requirements as low as possible and also to "free" those two wireless options for communication with alternative form factors of the OtherCoin (NFC is used if you have a Yubikey Neo with the OtherCoin software on it while Bluetooth can be used to talk to the cgToken form factor (external Bluetooth smartcard reader).

[drazvan]

As promised, I've uploaded a more detailed demo of the OtherCoin system to YouTube at http://www.youtube.com/watch?v=ZR8gz0uVBHk&feature=youtu.be (make sure you view it in HD).

It shows it running side by side on a Samsung Galaxy Note 2 and a Vodafone Smart Mini (a.k.a. Vodafone 875), sending keys back and forth over SMS and interfacing with the Android Bitcoin Wallet to reveal a key (remove it from Othercoin and import it into the wallet) and add funds to a key (stored securely in the OtherCoin smartcard). Sending/receiving keys via QR code still works, it's just not shown in this video.

If you have any questions, ask away. If you feel generous (or supportive), 1VeriFivRsUxUqdWMgUmHrgfQXL9J3dfe .

Thank you,
Ravan

[beeblebrox]

Congratulations on achieving demo status for your project.  This is a game changer for Bitcoin- the greatest innovation in a year since Bitcoin ATM's.  I can't understand why this isn't the top comments thread of the month  -- no comments anywhere yet?.  I think most people here just don't understand what this project is.

Previously I pledged 15 BTC on this thread to you for this- I have just sent you 5BTC and will send another 10 when it has the finishing touches and is publicly realeased.  Please spend this as you see fit (preferably on the project though I don't mind if you spend it otherwise-- you deserve it!).  

I'm interested in knowing if you familiar with the Samsung Knox Android phone- it has very strong privacy and security feature with allow apps to run in secure isolated containers.  Knox would be a great match for this project.  I'll give you another 0.5BTC if you port your software to make use of the available Knox features.  This shouldn't be too hard or take too long, from what I understand you contract Samsung and provided they approve the app they assist in wrapping the Android files to make use of the Knox features.

Have you thought about patenting your split key idea of using both the phone and the card?  It would be a good idea even if you are motivated to introduce this system for the benefit of bitcoin and not so much for your personal gain because it would help your system to become standard.  The widespread use of electronic off-chain private key exchange needs/requires very few solution providers so that people can exchange with others without compatibility issues.

Also how do you plan to advertise/introduce it to the bitcoin community.  I imagine that you could perhaps gain access to users by introducing it to local bitcoin groups and retailers.  This project needs to penetrate where people meet face to face regularly to conduct bitcoin transactions.

By-the-way:  I want this project of yours to succeed, so if it would help it I can lend you interest free up to 20 BTC to be paid back at your leisure as a gentlemen's agreement.  If you would like more I could lend it to you interest free up to 250BTC but this would require a formal agreement (you would have to pay the costs of drawing up a contract).  Even more is possibly available but it would require that I receive benefits in return (eg: exclusive rights to sell in my country, or a part of the business, etc.)

[drazvan]

Thank you Beeblebrox, 5 BTC received.

I'm not sure what you mean by "public" - taking it commercial will take a bit longer (the main showstopper being the actual hardware - I have a few of each of the various hardware form factors for the OtherCoin card and obviously need to get some initial stock and selling these to end users requires various little details like a manual, a logo (engraved or silkscreened) on the actual card, a streamlined card issuance/provisioning mechanism (right now it's all manual and I don't scale very well ). I also plan to have a limited beta test with a few users just to confirm that I haven't missed anything obvious.

My plan for the coming weeks is to raise enough funds (either via donations such as yours or by preselling exclusive distribution rights) to allow me to focus on this project exclusively and take care of these little details before I go fully public.

The source code for the Android app has just been published at https://github.com/razvandragomirescu/OtherCoin - any interested party can take a look and verify that it actually works the way I described (keys are split between the smartcard and the phone, the card has no access to any network and communicates only to the smartphone, etc). It should also serve as a reference on how to interface with the various form factors that the OtherCoin will have (microSD card, external Bluetooth token or NFC token).

Regarding Samsung Knox, it already works with it. I've actually had Samsung wrap OtherCoin + the official Android Bitcoin Client + the helper tools for the Bluetooth OtherCoin and they all run from within the Knox container (tested on a Galaxy Note 2). The problem comes when interfacing with the OtherCoin card - Knox containers disallow communication to external storage (so no microSD or USB) and also block NFC. Only Bluetooth should work, but it doesn't (there's an exception in the BluetoothSocket system class - not in my code). I'm all over Samsung's support for this, they have specifically told me that Bluetooth should work but now they claim that only very specific "whitelisted" Bluetooth smartcard readers are allowed. But yes, it works in Knox, if you have a Samsung device that supports it let me know and I'll email you the wrapped APKs to try it.

Regarding user adoption, the plan was to get some early regional resellers that can help by promoting it at local Bitcoin meetups and conferences in their area. Preselling exclusive distribution rights (per country or per region) would also help us raise the necessary funds to turn this from something I'm working on in my spare time into a real business. I'm not sure where you are located, but if you're interested in acquiring the exclusive distribution rights in a certain area or country, make me a reasonable offer and I'll take it. You would not only get the exclusive rights for OtherCoin in your area but also the rights to the Card2Coin sub-project (see https://bitcointalk.org/index.php?topic=339389) that will become part of the OtherCoin ecosystem, closing the loop by allowing you to exchange your OtherCoin keys to dollars directly, without ever having to touch the blockchain.

Depending on how much we raise from early regional resellers, I might take those 20 BTC you've offered as a loan, I really appreciate the offer. Thank you!

(we should probably move the discussion to the Project Development area sometime, right now it's a mix of tech + project dev)

[beeblebrox]

......
Regarding Samsung Knox, it already works with it. I've actually had Samsung wrap OtherCoin + the official Android Bitcoin Client + the helper tools for the Bluetooth OtherCoin and they all run from within the Knox container (tested on a Galaxy Note 2). The problem comes when interfacing with the OtherCoin card - Knox containers disallow communication to external storage (so no microSD or USB) and also block NFC. Only Bluetooth should work, but it doesn't (there's an exception in the BluetoothSocket system class - not in my code). I'm all over Samsung's support for this, they have specifically told me that Bluetooth should work but now they claim that only very specific "whitelisted" Bluetooth smartcard readers are allowed. But yes, it works in Knox, if you have a Samsung device that supports it let me know and I'll email you the wrapped APKs to try it.
.......

Yes, I should have realised  that Knox wouldn't allow communication to external storage such as the SD card.  But good to see that you've wrapped the parts anyway-- I am sending you 0.5BTC for that.

Depending on how much we raise from early regional resellers, I might take those 20 BTC you've offered as a loan, I really appreciate the offer. Thank you!

(we should probably move the discussion to the Project Development area sometime, right now it's a mix of tech + project dev)

Anytime you wish to take my up on the offer just post a message here or in the other thread (which I've just discovered) about this project in the Project Development area and I'll send it to you.



PS: regarding buying distribution rights.  For me personally I would require that you have some sort of patent protection so that other competitors couldn't steal the market with alternative products.  Unfortunately, the basic concept of off-chain electronic transactions by  secure private key exchange would most likely not be patentable since the mechanism has been publicly detailed previously by others.  However, your idea of splitting the private key across the phone and card offering further customer protection I believe is novel (not only novel but also a great idea too   ) and should be patentable.  The split key feature could provide a selling edge to establish your product in a market dominating position-- a dominating position in this market is golden due to the fact that it has a native lock-in factor owing to the compatibility issue surrounding the cards being able to talk to each other and establishing secure connections.  

 (Actually, as-an-aside: In my particular case of Australia it may even be the case that you cannot patent the split key idea as it is my understanding that our law requires that the idea never be published before the patent application-- however I think this is the exception of most countries than the rule.  I believe that in places such as the USA you have up to one year after publicly detailing the mechanism to patent it-- but I'm not a lawyer so not so sure.)

[drazvan]

Thank you, 0.5BTC received as well. If the smartcard reader whitelist that Samsung support mentioned is real, I will try to work with our supplier to get the OtherCoin/cgToken Bluetooth reader certified with Samsung to make it usable in the Knox container. Their support guy didn't sound very sure about it though, they had specifically told me to only use Bluetooth 2.1 (not 4.0 - that's not supported) and never mentioned this "whitelist" until I actually tried it and saw the exception being thrown in their system classes (the app passed certification just fine).

I'm not sure if the split key setup is patentable (but I am not a patent attorney either) - after all, that's how the vanity Bitcoin address generation works. They are not storing the secret half of the key in a tamperproof smartcard though or using the system to securely transfer value between parties.

One other thing that is interesting is that OtherCoin is not limited to just Bitcoin - any altcoin that still has the notion of a private key (used to transfer funds) can be integrated with it. If the altcoin uses Elliptic Curve crypto, then the split key scenario also works, but you can also use the system without a second half stored in the smartphone and just trust the smartcard to transfer the private key around safely.

I would definitely like to claim the remaining 10 BTC from your bounty as well, what would you like to see before that happens? The Android app can be in the Play Store in a few days but it's not very useful without the hardware (the OtherCoin card) - additional OtherCoin microSD cards will take a few weeks to arrive. Please let me know how you see this. You can also email me at razvan.dragomirescu (at) veri.fi or send me a PM.

To everyone else reading this thread, if you would like to be appointed as the exclusive reseller in your country or region (considering that the solution is not currently patented and, as Beeblebrox mentioned, we are not sure if it is patentable at all), feel free to make me an offer - I'm also willing to consider offers that pay a reservation fee immediately with the rest of it being due at the time the application starts selling.

[deuteragenie]

SMS traffic goes through the internet nowadays.  Better use two channels

[drazvan]

SMS traffic goes through the internet nowadays.  Better use two channels

OtherCoin is channel agnostic, I've implemented SMS and QR codes as samples but you can also use NFC, Bluetooth, WiFi or even the Internet. SMS appeared safer (especially if parties are on the same network - meaning that the messages only go through the SMSC of the operator and do not leave their infrastructure).

You can also mix channels if you feel like it (even in the current implementation, you can send your request via SMS but scan the response from the QR code, although I don't see why you would do that).

[btchip]

In my opinion offering a validation / stamping service to "bless" the public key of a device you want to use with OtherCoin looks like a better idea and business model than a patent - especially since the process had already been disclosed here 

[drazvan]

In my opinion offering a validation / stamping service to "bless" the public key of a device you want to use with OtherCoin looks like a better idea and business model than a patent - especially since the process had already been disclosed here 

Don't worry, that's coming:). Just didn't have time to implement that yet. This will be useful for completely offline transactions (right now transactions are simply off-chain but you still need access to a way to verify the balance associated with a private key - right now we use the BlockChain.info API with a pinned certificate to prevent man-in-the-middle attacks, but OtherCoin will also support signed "balance statements" that certify that at the time of the signature the balance of that particular key was x BTC (and as long as the key travels only between OtherCoin devices, its current balance can only be higher since nothing can be spent without the private key that is held securely in the smartcard).

I've also looked into using SPV to prove to the recipient that the key actually has a certain balance, but as far as I understood, SPV is _not_ safe if your only source of information is the potential attacker. SPV should be safe if the majority of the nodes you have access to are honest and in the case of an offline transaction, the only node you have access to is the sender of the funds who is also the most likely attacker.

[drazvan]

I've posted some initial pricing data and a few details on how to order a unit from our first batch in the Project Development area at https://bitcointalk.org/index.php?topic=319146.msg4494688#msg4494688 .

[drazvan]

Anytime you wish to take my up on the offer just post a message here or in the other thread (which I've just discovered) about this project in the Project Development area and I'll send it to you.

Beeblebrox, I think I'm going to accept your offer. I've spent the past few days talking to various people and it looks like most of them do not really understand what OtherCoin is/does. They keep asking questions like "how is this different from spending Bitcoins between two Android smartphones" (as in using the Android Bitcoin Wallet to spend the funds directly via the blockchain) or "why do I need a microSD card in my phone to do this" (they don't know what a smartcard is or are even aware of how vulnerable an Android smartphone really is, especially when rooted).

On the other hand, distributors want to see a finished product (packaged, ready to sell) before they commit to anything, so I guess the first order of business would be to get these to look more "commercial", then into the hands of a few key people and reviewers that can understand how OtherCoin is different from a regular Bitcoin payment. I also need a demo video that shows the actual product in action, from the time you insert the card into your phone to your first payment through the system.

Just to clarify, is the 10 BTC part of your bounty still on (for when this becomes a commercial product, which should be in a few weeks)? If the 20 BTC loan removes the 10 BTC part of the bounty, I'd rather struggle to get it out the door on my own, then take the 10 BTC and use them on the project. As you can see, I am a bit reluctant to get into debt (managed to stay debt-free for 35 years ...) but I really believe in this idea and its potential.

You are also welcome to become more involved in the development/company if you wish to do so, I could use an adviser / partner, even if you don't want to do this in an official position (but also if you do).

Thank you,
Razvan

[beeblebrox]

......
Beeblebrox, I think I'm going to accept your offer. I've spent the past few days talking to various ......

Thank you,
Razvan

I'm going to reply to this in the other thread since what we are discussing is more relevant to "Project Development" than Bitcoin "Development and Technical Discussion".

[drazvan]

Thank you Beeblebrox, will reply there.

Regarding the use of smartcards in Samsung Knox, here's Samsung's official response:

Currently there is no way to make any smartcard reader work with a wrapped app inside the KNOX container. Even the http://www.biometricassociates.com/products/smart-card-readers/3000mp-reader/ BAL-3000MP will not work with a wrapped app inside the container.

For KNOX 1.0 this is by design. KNOX 2.0 may allow some functionality for the container to connect with a smartcard but at this time we do not have a release date for KNOX 2.0

The app itself works fine but access to the smartcard is blocked by the Knox container. I do plan to work around it by having a hosted smartcard in the cloud (a physical one, plugged somewhere in your computer). That is planned, just not implemented yet.

[drazvan]

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.

[Peter Todd]

I agree with your analysis; given the use-case is low-value payments, better to have a solid privacy guarantee and slightly weaker loss reistance than the other way around. After all, this thing could be useful for privacy too.

Reminds me: it'd be good to add some features to make it possible to to secure trades on a blockchain. Right now your OtherCoin.pdf whitepaper suggests two functions, generate key, and securely transfer key to another card. I think you actually need a third function that does bi-directional key transfer atomically.

Suppose Alice has 50LTC and Bob has 1BTC. They want to trade like for like. They can do this by first transferring the currency into an address that their respective OtherCoin card has control of and letting the transaction confirm. Next they tell their cards the transaction they want to make, Alice: "Give up secret key Alice_LTC in exchange for secret key Bob_BTC" and Bob: "Give up sec key Bob_BTC in exchange for Alice_LTC"

Now the two cards can communicate with each other securely. (being fully atomic and non-jam-proof will be tricky) When they're finished either party can repeat the process, or potentially just reveal the secret keys entirely so the coins can be spend normally. Interestingly the cards themselves don't have to have any concept of trust; all the cards care about was that they got a signed ACK from the other side. Whether or not that signature was from a trustworthy card can be left up to the user to evaluate.

Speaking of, you forgot to include "Reveal a secret key" in your list of basic operations. In fact, what you actually want to do is a bit more subtle than in your whitepaper: you should always be able to get your OtherCoin device to produce an encrypted and then signed message containing a given secret key. What key the message is encrypted to is irrelevant: under all circumstances once this message has been produced the OtherCoin device is guaranteed to securely delete the key from memory and never produce another such message. At the same time the device is also guaranteed to only accept a new secret key if the key is encrypted and signed by a trusted sender.

What's neat about this is it gives a one-sided upgrade path: new devices can still accept secret keys from old, but still trusted, device. For instance if the master secret keys are ever lost, you can create a new set and issue new devices that can still accept secret keys from the old devices, even if the old won't accept keys from the new.

[Peter Todd]

With regard to history, I think there's an interesting attack-countermeasure possible without it, but first, a bit about how you'd actually use the card.

If the card is purely a secret key storage device, we have a practical problem of granularity: If Alice has 1BTC stored on one secret key, how can she send Bob 0.5BTC? Now, bi-directional transfers help here - if Bob happens to have 0.5BTC in one or more secret keys, he can give those keys to Alice in exchange for her secret key to make for the correct net amount transferred. Ideally you'd just fill your wallet with secret keys loaded with powers of two outputs, however that runs into the problem of minimum cost to spend a txout - at some point even if you had an output worth x BTC it'd cost you a significant fraction of that x BTC to spend in on-chain, so for the smallest amounts you'll want outputs along the lines of, say, 1.01BTC, so you can exchange it for Bob's 1BTC txout efficiently.

This is relevant to attacks when you consider the financial model of an attack. The attacker might spend, say, $50,000 worth of lab time to take apart one of these cards and extract the private keys on it. Once that is done the attacker can then create a fake software emulator and intercept the secret keys. However to actually profit from the attack the attacker needs to get something of value in exchange for pretending to delete secret keys, and the total value of on-chain txouts spendable minus the transaction costs to obtain them needs to be >$50,000 to break even.

Now suppose we limit the lifetime of a secret key to 1 year; after that year is up cards won't accept it. We can easily prove the creation date of a key by using the blockchain as a timestamped random beacon and committing a recent blockhash with ECC key derivation. Next we limit the total value of the secret keys that the card has access to per year. We can do this with Rivest's paywords scheme: the card calculates a chain of nonces derived from a root secret with w_i=H(w_{i+1}), revealing an additional step in the chain at each step. If peers expect a new, signed, nonce with every secret key exchange they can limit the total number of exchanges in a given time period by publishing those nonces. This can be a central server or decentralized p2p network; the requirements for consensus are very loose and not all nonces need to be published. Publishing two separate signatures for the same nonce - or overlapping range of nonces - is of course considered fraud and is easily proven. Storing the nonces isn't onerous, as they can be expired over time.

So long as the cost to attack a card is high compared to the cost of the card itself the economics work out. If a $5 card lasts two years and can move $25,000 worth of private keys per year, the cost to do so was 0.01% of the value of those keys. Meanwhile the attacker needs to keep the cost of the attack to <$25,000 to break even. I think the main question is what kind of economies of scale an attacker might get, and what kind of per-transaction cost users are willing to accept.

[Peter Todd]

Oh, and FWIW, the paywords stuff doesn't need specific support by the cards themselves beyond the ability to calculate an arbitrary paywords chain; the software talking to the cards can handle the rest.

[drazvan]

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

[drazvan]

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.