Off-chain anonymous transactions by secure transfer of private keys

[justusranvier]

So OtherCoin proposes a more subtle change, one that would really make Bitcoin anonymous and isolated from any online intervention/analysis - that is harder to understand than a new mining chip or a new (online) fancy wallet. Or maybe I'm just nuts and people don't really care about their privacy and are perfectly ok with the pseudonymous nature of Bitcoin .

Part of the issue might be trusting that secure transfer of private keys is actually possible.

[drazvan]

Ok, is there anything that you think people need in order to confirm that this actually does what it says? Smartcards are not tamper-proof (nothing probably is), they are tamper resistant, but the cost of extracting a key from the smartcard might exceed the balance of said key.

If you're talking about the actual protocol used to move the key between cards, I can detail that as well. It's nothing fancy (you can't do very fancy stuff in JavaCard ). It's plain ECDH to negotiate a session key (each party verifies the other's public key first) and AES to encrypt the private key with the session key. Feel free to ask if you need me to go into details.

[justusranvier]

Smartcards are not tamper-proof (nothing probably is), they are tamper resistant, but the cost of extracting a key from the smartcard might exceed the balance of said key.

A more conclusive analysis of the cost of extracting a key would be a great help.

[JeromeL]

Just discovered this thread. Awesome project. I am wondering why this has so little attention from the community. Projects like this give a very good reason to stay conservative regarding the max block size limit.

So OtherCoin proposes a more subtle change, one that would really make Bitcoin anonymous and isolated from any online intervention/analysis - that is harder to understand than a new mining chip or a new (online) fancy wallet. Or maybe I'm just nuts and people don't really care about their privacy and are perfectly ok with the pseudonymous nature of Bitcoin .

And yet this is the kind of project that would need tons of funding to really take off because it benefits/suffers from the network effect. The more people/merchants who would use OtherCoin, the more it would become useful and so on. And the more it would benefit Bitcoin in general.

It's a pity to see 21&Co... raising so much money for dubious projects while the promising ones are underfunded

[celestio]

With off chain transactions, what's the point of using a cryptocurrency then? I always believed that off-chain transactions far better suit centralized applications, as using it with a cryptocurrency basically makes the cryptocurrency itself irrelevant in the scheme of things since the transactions are done off-chain.

[dansmith]

@drazvan
I stopped reading the whitepaper to ask here first.
So, you will not open source OpenCoin firmware and yet you suggest people simply trust you and risk their funds?

This doesn't make sense. I must be misunderstanding something.

[dansmith]

OK, did read a little further to see that you reassure the reader that you are on the up and up.
How will you prove that the smartcard is not generating random-looking private keys which in fact are not random but have some deterministic element?

[drazvan]

OK, did read a little further to see that you reassure the reader that you are on the up and up.
How will you prove that the smartcard is not generating random-looking private keys which in fact are not random but have some deterministic element?

The OtherCoin Android application will be open source, it's just the part that runs on the secure microSD card that will be closed. The Android app generates its own random key that is _added_ to the one the smartcard generates and you can verify the Android app to ensure that the key is really random. So, even if the smartcard generates the most deterministic key (let's say it always generates 0 as its random key), you always add a random value of your own (generated by the Android app) to it. The result is obviously random (random + deterministic = random).

This is very similar to how vanity Bitcoin address generators work (see https://vanitypool.appspot.com/faq for instance). Also check out point #3 in the  "What it doesn't do" section of the whitepaper.

[drazvan]

With off chain transactions, what's the point of using a cryptocurrency then? I always believed that off-chain transactions far better suit centralized applications, as using it with a cryptocurrency basically makes the cryptocurrency itself irrelevant in the scheme of things since the transactions are done off-chain.

The whole point of OtherCoin is that it transacts _Bitcoin_, so there's no centralized authority that guarantees the funds. Whenever you want to get out, you don't have to check if the central issuer is still in business and they can't block your request or ask any questions - OtherCoin simply secures the transfer of _Bitcoin_ private keys that can be instantly redeemed on the blockchain. So it's off-chain but decentralized. The cryptocurrency is not irrelevant - it's the way you get your money in/out of the OtherCoin system. In most (all?) other off-chain systems, the central authority can not only track your payments (you tell them when you want to pay someone) but also control your deposits and withdrawals. With OtherCoin, deposits are simply Bitcoin payments to a random address that the app generates, withdrawals are simply private key sweeps (the app tells you the private key and destroys it from its secure storage). Transactions are off-chain and anonymous (you move Bitcoin private keys between offline devices).

[drazvan]

OK, did read a little further to see that you reassure the reader that you are on the up and up.
How will you prove that the smartcard is not generating random-looking private keys which in fact are not random but have some deterministic element?

Also take a look at http://bitcoin.stackexchange.com/questions/3853/can-one-safely-buy-vanity-addresses-from-a-third-party-without-risking-ones-coi - it contains a more technical description of why the way we do things in OtherCoin is safe for the end user (it's the exact same process).

[marcus_of_augustus]

In most (all?) other off-chain systems, the central authority can not only track your payments (you tell them when you want to pay someone) but also control your deposits and withdrawals.

Not all, but none widely deployed afaik, however openTXS systems have blind signature cash transfers that are untraceable by the server. The control aspect can be mitigated by a federation of servers facilitating blind transfers of the same/linked instruments.

[drazvan]

Smartcards are not tamper-proof (nothing probably is), they are tamper resistant, but the cost of extracting a key from the smartcard might exceed the balance of said key.

A more conclusive analysis of the cost of extracting a key would be a great help.

There has been some research on the physical security of smartcards - I couldn't find any recent studies on cost, one study from 2004 ( http://www.cs.ru.nl/~erikpoll/hw/slides/04_smartcard_attacks.pdf ) indicates a cost of $100K for such an attack. The smartcard manufacturers (NXP and Infineon in our case) also guarantee their chips against side channel attacks if a strict set of rules is followed when running crypto algorithms - that's the reason we chose to stick with their proprietary functions instead of (possibly insecurely) implementing our own.

[drazvan]

In most (all?) other off-chain systems, the central authority can not only track your payments (you tell them when you want to pay someone) but also control your deposits and withdrawals.

Not all, but none widely deployed afaik, however openTXS systems have blind signature cash transfers that are untraceable by the server. The control aspect can be mitigated by a federation of servers facilitating blind transfers of the same/linked instruments.

A server or a federation of servers would have to be maintained ($$$) and kept online and in business for the life of the product. It would also still know when a transaction takes place (just not the exact details). With OtherCoin, we don't know when a transaction takes place and even if we go out of business, the system still functions just fine (the software on the cards enforces the rules, not an online entity). This is also the reason I'm removing the centralized balance signing feature from the application and moving towards SPV proofs - even though it would make for a better business model (we could charge people a small fee to sign their balances), it would make the system vulnerable in case we go (or are forced) out of business. OtherCoin should not (and will not) depend on any online entity other than the Bitcoin network and should be as resilient as the Bitcoin network itself. 

[marcus_of_augustus]

In most (all?) other off-chain systems, the central authority can not only track your payments (you tell them when you want to pay someone) but also control your deposits and withdrawals.

Not all, but none widely deployed afaik, however openTXS systems have blind signature cash transfers that are untraceable by the server. The control aspect can be mitigated by a federation of servers facilitating blind transfers of the same/linked instruments.

A server or a federation of servers would have to be maintained ($$$) and kept online and in business for the life of the product. It would also still know when a transaction takes place (just not the exact details). With OtherCoin, we don't know when a transaction takes place and even if we go out of business, the system still functions just fine (the software on the cards enforces the rules, not an online entity). This is also the reason I'm removing the centralized balance signing feature from the application and moving towards SPV proofs - even though it would make for a better business model (we could charge people a small fee to sign their balances), it would make the system vulnerable in case we go (or are forced) out of business. OtherCoin should not (and will not) depend on any online entity other than the Bitcoin network and should be as resilient as the Bitcoin network itself. 

Sounds ideal. Can't wait to test it out.

I was merely clarifying your "most(all?)" point(query?), nothing more.