Topic: Off-chain anonymous transactions by secure transfer of private keys (Read 17273 times)

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

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

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. 

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.

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.

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

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

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.

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

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.

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

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

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.

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

I think the apparent lack of interest is due to the fact that OtherCoin doesn't claim (or is expected to have) a net effect on the Bitcoin price. Its intention is to simply make off-chain truly private transactions possible. As a side effect, it would also make any blockchain transaction analysis useless (since coins could exchange hands offline hundreds or thousands of times without any trace in the blockchain or anywhere else on the Internet). It also removes the one to one mapping between addresses and persons - in the current system, once you've identified who owns a particular address, you can safely assume that any past or future payments sent to that address belong to that person. With OtherCoin in place, an address could effectively be "owned" by hundreds of people, just at different moments in time.

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 .

It's very much alive, thank you! . Just going slowly due to (current) lack of funding (and being a one-man-show more or less, with me filling in all the roles ). As soon as I've removed the dependency to the centralized balance signatures, OtherCoin will become truly and fully decentralized - even if we go out of business at some point, the system will continue to work and all cards will continue to be valid indefinitely.

Thanks for the $50 tip/donation to whoever sent it, it's the first donation I see in a long time .

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.

Interesting to know it is still alive.

Hello everyone,

I have updated the whitepaper at http://www.othercoin.com/OtherCoin.pdf to reflect the most recent changes in the protocol and application. I've decided to get rid of the centralized balance certification and use SPV proofs (as suggested in this thread). It's not fully implemented yet, but it shouldn't take very long now. Each device will simply download block headers, then at the time an OtherCoin key is funded, the payer waits for the transaction to be included in a block, then fetches the Merkle branch that links the transaction into the block and uses the serialized transaction + Merkle branch + block hash as a proof that the transaction really exists. Since each participant downloads his/her own blockchain headers, the payer cannot feed it fake blocks.

I've also detailed the PIN-based escrow mechanism that is built into the system and listed the hardware that we've tested it on and the hardware we expect it to work on.

Finally, I've submitted the app to the Coinbase Hackathon (I'm not sure if it will be accepted - their Terms and Conditions do not rule out older apps, but their submission page says the app should be "new" (as in created after April 7th - and OtherCoin obviously isn't) ). If they abide by the T&Cs, they should accept it, but we'll see.

BTW, here's the demo video I've created for the Hackathon: https://www.wevideo.com/view/395666124 . Enjoy and wish me luck!

Hi Drazvan,

Here are the advantages for a web change service that I had in mind-

These two you have already pointed out:

-Speed of receiving pre-confirmed (and certified) coins is the main advantange of using a web-service for change.  The service will be more or less instant when compared to creating change coins on the block chain and waiting for them to confirm at the time of the transaction (in cases where the receiver insists on confirmed coins).  

- Anonymity offered to the sender since they're not using their own wallet address to create the coin, the person recieving dosen't get to see any of the wallet addresses of the sender.


There are also a couple of others that I have thought of:

- You can offer a service guarantee that all the coins that you have personally created and certified are clear of taint from the major theft events (clear of publicly recorded/verified affected addresses atleast).  The person receiving the coins doesn't have to check them against the block-chain for taint.

- it may be cheaper to use the web-service.  Since the web-service has plenty of time to pre-make coins it can use lower-priority transactions (even feeless ones if the service operator waits a long time).  So the web-service can sell their change coins cheaper than a person can make them for themselves if the person has to make it confirm quickly (ie: in the next block) at the time of the transaction.  


The speed and the cheapness form the main economic case that I can see for the web-service being successful/profitable.