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.

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

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 .

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!

I have read about Lighthouse a few months ago but I didn't realize it was already operational / usable. I guess I'll have to look again. I'm not sure if their "open source only" policy would apply here - the Android-based OtherCoin app will be open source, but the JavaCard-based secure component running on the secure element will not be. You will always need a secure element for the app to function (I have some medium-term plans to allow first time users to remotely access a secure element that we host in order to try the app before they buy the secure element, but that would negate the anonymity part, we would know who's accessing our hosted secure element).

I'm still working on it (I've actually resumed working on it a few weeks ago). The app is fully functional (both the Android controlling app and the JavaCard secure part that runs on the microSD secure element). I am now working on eliminating the last centralized part of the system (the authority that signs Bitcoin balances) and replacing it with a SPV-style proof. This would allow semi-offline situations where the clients download just the block headers (thus maintaining their privacy - they don't indicate what transactions they're interested in), then the payer proves the balance of a private key by giving the payee the transaction data and a Merkle branch indicating how the transaction connects to a particular block (that the payee is supposed to already know about).

I've managed to port the smartcard side of the app to Infineon chips as well (this used to be an NXP-only affair given that I only had access to their proprietary APIs - now I have access to Infineon's as well).

I'm also looking for additional funding (that was my reason for stopping work on the project a few months ago - ran out of funds and had to go back to my consulting gig for a few months to support myself and my family). I haven't solved this yet, it's frustrating to not be able to focus on this 100% (given that I really love the project and it's what I want to do in the long run), if anyone has any suggestions or business proposals, feel free to message me.

Finally, I plan to enter the Coinbase Hackathon ( https://developers.coinbase.com/bithack ) - I'm trying to finish the SPV proof mechanism before I submit my entry (not sure if it will be ready by then though). This means I will also put together a new demo video showing the current state of the app.

Thanks everyone for your patience and support.
Razvan

Well, according to https://communities.intel.com/thread/57334?start=0&tstart=0 it's not very clear if it's a 64-bit processor or a 32-bit one (their reference kernel is 32-bit and nobody's been able to make it work in 64-bit mode so far - see the thread above).

It ran fine for over 24 hours with the new settings, I'll try to take them out one by one and see if things change.

For the fun of it, I've installed X Windows and Bitcoin QT on the Edison and gave it a try (side by side with a web browser and a terminal) and you can see the result below:



So we basically have Bitcoin QT (a full visual Bitcoin node, with full verification!!) running on something the size of a postage stamp.

The dbcache setting is from an IRC discussion - see http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/09/18 . If things work ok with these settings, I'll remove the restrictions one by one and see what happens. I now have 8 incoming and 8 outgoing transactions, memory usage 330MB. Stable so far.

Ok, I'm running it now like this


Memory appears to be stable at around 290MB, let's see if it still crashes after 16 hours, I'll leave it running overnight.

It's not the initial sync, I've copied the blockchain ("blocks" and "chainstate" folders) from an in-sync node and it took a while to start, but now it's synchronized, the crash happens during normal operation, it's not using much processor time, just a ton of memory. I don't have swap enabled, I'm really not very keen on enabling swap to flash - but does it really need swap when it has 1 GB of RAM?? As I said, memory usage is around 350MB (I've restarted it a few hours ago and now it's at 293MB (the VSZ field in "ps -w").

I'm now running it with -debug and sending output to the console, so I should see it when it crashes, previous runs were without -debug.

Also, I can't run the 64-bit version, this is a 32-bit x86 system based on Intel Atom.

Hello everyone,

I'm trying to run Bitcoin Core on a tiny Intel Edison board (http://en.wikipedia.org/wiki/Intel_Edison). The plan is to eventually create the smallest physical Bitcoin Node (it's the size of a postage stamp!). The board has a dual core Intel Atom on board with 1 GB of RAM and 4 GB of storage, I'm using an external 32 GB USB drive to store the blockchain.

The thing is that bitcoind appears to crash after about 16 hours - I see no messages as to why in debug.log, I simply leave it running overnight and find it dead. Memory usage (when running normally) is around 350MB.

I've tried to mess with the startup options, like this:

./bitcoind -maxconnections=16 -daemon -disablewallet -datadir=/mnt

but it still crashes after less than 24 hours.

I'm using version 0.9.3, the 32-bit x86 binary.

I could always restart it when it crashes, but it just doesn't seem the right thing to do, I'd rather get to the bottom of this and see why it crashes and how to recover. I understand people have been running bitcoind on machines with less RAM (512MB Raspberry Pi for instance), so I thought 1 GB should be more than enough (if that's the reason for the crash).

Any ideas on how to proceed?

Thank  you,
Razvan

Thanks, but that's an Android wallet and I'm not running Android, my board is a very simple embedded Linux device (low memory, small flash, etc). As I said, I have a working solution now using Bitcoinj so I'll stick to that for now.

Bitcoin Core is out because of its blockchain space requirements, I only have 4GB of storage and that won't fit the current 20+ GB of the blockchain. I was able to implement it using Bitcoinj, thanks hhanh00 for your suggestion but I'm considerably more familiar with Java (your project uses Scala), so I guess I'll stick to that (and Bitcoinj).

Thanks again everyone.

Thanks ffe, but I'm looking for something that does not require an external server. I've managed to prototype this using Bitcoinj, if anyone knows of a better/simpler solution, I'm all ears. Again, this must receive/parse transaction data from the Bitcoin network, not talk to a server.