Off-chain anonymous transactions by secure transfer of private keys

[Peter Todd]

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?

Sorry! I must have read your reply and forgotten about it.

The blockchain itself can be used as a clock in a few ways. The most obvious way is to process the block headers and just use the latest one lower bound on what time it is. However then you have to ask how does the card get the blockchain? You can add to the protocol an encrypted field that essentially lets anyone feed the card with block headers within any transaction going to it - if I'm sending you money I can inform your card about what time it is against your will.

However, all the block headers are kinda large for a Java card, so you really want to only send a subset. When you think about it every header the card gets is essentially making a kind of statement that some amount of work was done claiming the current time at least blockHeader.nTime Every header the card gets pushes the likely current time in some direction, usually forward. Making a bunch of fake block headers with high difficulty is very expensive, so you can probably come up with some rule that makes faking headers to lie to the card about the current time unprofitable. You can be a bit more clever with this by using interactive or non-interactive proofs, but long story short, Bitcoin doesn't support that yet.

You can also force the owner of the card to provide recent block headers via timestamping and merkle paths. The card would generate a nonce and and the card owner would be required to timestamp that nonce in the Bitcoin blockchain and provide the card with a merkle path from the nonce to the block header. The user is forced to keep providing the card with new blocks; with a minimum difficulty the cost of compromise is well defined, almost. Unfortunately it is possible for a group of card owners to collude and have some fake block headers generated so as to let them all benefit, driving the per-card cost of faking the time down. (possible without timestamping too I might add)

Timestamping infrastructure doesn't exist yet, but creating it isn't hard. I have a project called OpenTimestamps that was doing just that - I'd be happy to put some time into it again.

As for centralized time services personally I'd be very hesitant to use any kind of centralized service simply because it'd be temping for a court to order them to either shutdown, change keys, or sign fake timestamps as a way of disrupting OtherCoin users.

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.

Good idea! How long will this pin be? What will you do to prevent brute-forcing it?

[1715045616]

1715045616

[1715045616]

1715045616

[1715045616]

1715045616

[drazvan]

Thanks Peter! In all honesty, I haven't had the time to look into the timestamping issue yet, thanks for the suggestions! I'm trying to keep the initial release as simple and as "blockchain agnostic" as possible. All it does for now is secure private keys, it has no notion of blockchain/transactions/ECDSA/etc, so it can be easily reapplied to just about any other altcoin that uses private keys (are there any that don't? ).

I need to get the marketing materials done so I will probably stop adding features for a few weeks and focus on getting it launched. There's always room for a version 2 .

Regarding the PIN, it's 4 digits / 3 tries. It's sent encrypted together with the private key and stored as an OwnerPIN JavaCard object (those are especially protected by the JavaCard runtime). You get 3 attempts to unlock the key - if you fail, the key is permanently blocked (I should probably make it delete it at that point to save space and prevent further attacks).

[Peter Todd]

Thanks Peter! In all honesty, I haven't had the time to look into the timestamping issue yet, thanks for the suggestions! I'm trying to keep the initial release as simple and as "blockchain agnostic" as possible. All it does for now is secure private keys, it has no notion of blockchain/transactions/ECDSA/etc, so it can be easily reapplied to just about any other altcoin that uses private keys (are there any that don't? ).

I need to get the marketing materials done so I will probably stop adding features for a few weeks and focus on getting it launched. There's always room for a version 2 .

Heh, I certainly do recommend you consider seriously that option! I've got a lot more ideas than there are hours in the day.

Regarding the PIN, it's 4 digits / 3 tries. It's sent encrypted together with the private key and stored as an OwnerPIN JavaCard object (those are especially protected by the JavaCard runtime). You get 3 attempts to unlock the key - if you fail, the key is permanently blocked (I should probably make it delete it at that point to save space and prevent further attacks).

Sounds good.


You can put me down for a pre-order BTW.

[beeblebrox]

Hello Drazvan,

How are you going and how is the project coming along?

I'm curious to know what are the limits regarding how many keys the card can hold at once,  could you please tell me?

Thanks
Beeblebrox

[drazvan]

Hey beeblebrox, good to have you back!

Right now, each key takes 32 bytes (the private key) + another 32 bytes stored as an encrypted blob (that is actually the half of the key that the phone knows, encrypted with AES by the phone). That blob is used to be able to move the smartcard between phones and re-build the OtherCoin key database if you only have the card (and a master password). The blob is not mandatory, but the current Android OtherCoin implementation uses it, so let's assume 64 bytes/key.

The current microSD smartcards we use have about 144K of storage (chip is NXP J5C145_M3) and the OtherCoin app itself is probably around 4K or so (haven't checked exactly). So 140000/64 = 2187.5. So you can safely assume that you can store about 2000 keys in the app - that would prove to be a bit unwieldy at this point with the current OtherCoin Android app since it shows them all to you and you choose the ones to transfer. Once we automate the process it will become easier. I think most people will have 100 keys or less in the system at any given time though.

As a status report, we're waiting for all 3 (yes three ) hardware manufacturers we use to fix their products. There will be 3 form factors for the OtherCoin product - a microSD card, a Bluetooth Low Energy keychain-style dongle and an actual Android device with a real (SIM-sized) smartcard inside. We're waiting for a new firmware from the microSD manufacturer to support Android 4.4 KitKat (current version does not work with KitKat and units cannot be upgraded in the field, so we would have had to recall them for an update or mail everyone new units). The Bluetooth Low Energy dongle will be available mid-May (around May 20th or so we've been told). The Android device has a bug with long-running smartcard operations (it times out too soon) and the manufacturer is supposed to send us an updated firmware next week.

I'm trying to make sure everything works on the smartcard side since that's very hard (if possible at all) to upgrade in the field. On the Android side we can always push an update through the Play Store if we find any issues. The app itself appears to be rock-solid, it's just these last minute interface bugs that drive me crazy. They have nothing to do with OtherCoin itself but with the way smartcards are read by the OS.

[drazvan]

BTW, over the Easter holidays I tried to get away from the OtherCoin project and clear my mind a little bit, so I wrote this: https://bitcointalk.org/index.php?topic=586830 . Now I'm back to the serious stuff.

[ThePurplePlanet]

Can it transfer fractions of the wallet? If not can it have multiple addresses of small amounts?

[drazvan]

Can it transfer fractions of the wallet? If not can it have multiple addresses of small amounts?

"Fractions of the wallet" - yes. "Fractions of a key" - no. Keys (and their associated balances) are transferred altogether, so you cannot transfer less than a key (that would effectively mean you are sharing it with someone else and the whole point is to make sure the key is only held by a single person at any given time). If you need to "break" a key into smaller amounts, you can easily do so through the Bitcoin network - transfer the key you want to split to the Bitcoin wallet, then fund two (or more) OtherCoin addresses from it with any values you need. This is also how you can pay the exact amount requested = you pay the majority in OtherCoin, then if the merchant wants to receive _exactly_ what he's asked for, you either pay the rest via Bitcoin or you break an OtherCoin key into two smaller ones, then transfer one to the merchant (for the remaining amount to pay).

[beeblebrox]

Can it transfer fractions of the wallet? If not can it have multiple addresses of small amounts?

"Fractions of the wallet" - yes. "Fractions of a key" - no. Keys (and their associated balances) are transferred altogether, so you cannot transfer less than a key (that would effectively mean you are sharing it with someone else and the whole point is to make sure the key is only held by a single person at any given time). If you need to "break" a key into smaller amounts, you can easily do so through the Bitcoin network - transfer the key you want to split to the Bitcoin wallet, then fund two (or more) OtherCoin addresses from it with any values you need. This is also how you can pay the exact amount requested = you pay the majority in OtherCoin, then if the merchant wants to receive _exactly_ what he's asked for, you either pay the rest via Bitcoin or you break an OtherCoin key into two smaller ones, then transfer one to the merchant (for the remaining amount to pay).

To ease the use the smartcard key exchange for purchases I envision that it would be best if people had many wallet keys (from now on I will call them coins) with balances of standard denominations (example denominations: 1 uBTC, 10uBTC, 100uBTC, 1mBTC, 10mBTC, 100mBTC, 1BTC, 10BTC, etc) so that they can give the exact amount or be given return change by totalling multiple coins in the manner similar to normal fiat eg: to give 0.8253BTC use 8x100mBTC + 2x10mBTC + 5x1mBTC + 3x100uBTC.   You could quickly top-up your smartcard with more coins by asking other people directly for change or using a change service over the internet.

By-the-way Drazvan,  this is what I was going to write an email about to you a couple of months ago.  I am now sending a PM with some further details that you may be interested in.

[drazvan]

That sounds like a good idea - although I'm not sure a web service is needed to do the change. If you want to split 1 BTC into 10 * 100mBTC or 100 * 10mBTC you can always go through Bitcoin (that is redeem a 1 BTC OtherCoin, then feed the balance into 10 or 100 smaller OtherCoins).

A web service could be useful though for premium services - that is the ability to split a larger coin into smaller ones without advertising this on the Bitcoin network and also getting confirmed or balance certified coins in return. So you would give the service your 1 BTC OtherCoin and it would give you 10 * 0.1BTC OtherCoins with more than 6 confirmations on their balance (or simply with a signed balance - regardless of the number of confirmations).

I plan to spend the next couple of weeks redesigning the user interface of the app a bit - that is way overdue! Right now it displays a list of the coins and their balances and you can long click on each to access the available options (Spend, Redeem, Delete, etc). This doesn't make much sense for the average user and looks downright weird when you have more than a few coins, so I plan to aggregate the view and just display a count of coins in each bucket (1 BTC, 100mBTC, 10mBTC, 1mBTC, etc) as well as keep a "floating" BTC balance (that is a pure Bitcoin balance that is not stored on the card but available to the Android app as a buffer to either create new coins or split existing ones or as an intermediate buffer for redeemed values). This way, if you want to split a larger coin or aggregate a few smaller ones you simply select them and it internally moves them to the floating BTC balance first (gets the private key and sweeps their value), then funds the coins you want to create. This would get rid of the requirement to have the Bitcoin client on board (you can still have it installed if you want to fund the floating balance externally or want to get some of the floating balance out).

[drazvan]

Ok, I have a little bit of a dilemma: if we move to multiple OtherCoin denominations, each transaction would mean a transfer of multiple private keys (each key being 32 bytes secret on-card part and another 32 bytes known by the Android app). So it's 64 bytes/key. If we go all the way down to 0.1mBTC and assume people won't pay more than 10 BTC through the system (probably a safe bet at first), the maximum number of coins would be transferred when you pay 9.9999 BTC (45 keys, that's about 3 kilobytes including protocol overhead). That's a little too much for QR codes and could become a problem even for SMS chaining. It could be sent over NFC and over the Internet.

We could go with animated QR codes but I've used those before (I wrote this: www.visualbtc.com) and they're not exactly easy to use. So I wonder if I should drop QR codes altogether and keep SMS and Internet and NFC comms. SMS might be tricky (or expensive) for large transfers, it already uses concatenated messages but still, those are up to 140 bytes (160 characters) each, so you would need 20 or more to send a 45 key transfer. I've already implemented a small server that OtherCoin apps can send the info through (it's just a relay type of system, nothing fancy). Of course, QR codes and SMS have the advantage of not requiring and Internet connection, but we're going to need one anyway to split coins and do BTC transfers anyway.

Any thoughts would be appreciated. Thank you!
Razvan

[beeblebrox]

Ok, I have a little bit of a dilemma: if we move to multiple OtherCoin denominations, each transaction would mean a transfer of multiple private keys (each key being 32 bytes secret on-card part and another 32 bytes known by the Android app). So it's 64 bytes/key. If we go all the way down to 0.1mBTC and assume people won't pay more than 10 BTC through the system (probably a safe bet at first), the maximum number of coins would be transferred when you pay 9.9999 BTC (45 keys, that's about 3 kilobytes including protocol overhead). That's a little too much for QR codes and could become a problem even for SMS chaining. It could be sent over NFC and over the Internet.

We could go with animated QR codes but I've used those before (I wrote this: www.visualbtc.com) and they're not exactly easy to use. So I wonder if I should drop QR codes altogether and keep SMS and Internet and NFC comms. SMS might be tricky (or expensive) for large transfers, it already uses concatenated messages but still, those are up to 140 bytes (160 characters) each, so you would need 20 or more to send a 45 key transfer. I've already implemented a small server that OtherCoin apps can send the info through (it's just a relay type of system, nothing fancy). Of course, QR codes and SMS have the advantage of not requiring and Internet connection, but we're going to need one anyway to split coins and do BTC transfers anyway.

Any thoughts would be appreciated. Thank you!
Razvan

Perhaps you could use denominations based on binary,  ie: 10uBTC, 20uBTC, 40uBTC, 80uBTC,.... .  To cover the 10e6 fold range from 10uBTC to 10BTC you only need a maximum of 20 keys if you sum it the most efficient way.  (I started at 10uBTC to allow for transactions such as paying for reading an item of news from a web-site, or paying to get change from an internet change site , etc.)

Is twenty keys too many for a QR code?

Of course most people would have trouble working out how to represent arbitrary amounts in binary but the phone/computer would do this behind the scenes anyway.  All they would really need to know is the total amount they hold while the computer handles using the correct change in a transaction.   By default you could just have their total displayed with a option to display a summary of the holdings of each denomination and a further option to show the details of each individual coin's key/wallet.

Each time a person engages in a transaction their phones could automatically negotiate with each other to top-up with any coins they need if one has excess in some denominations but shortage in others  (the phone could even monitor the owner's usage pattern over time and determine their most commonly used denominations and build up a store of them).  This would lessen the need for people to use 3rd party online change services.

[beeblebrox]

This obviously doesn't offer the same guarantees (the entity running the server would see your requests to the virtual smartcard, so it could theoretically tell when you're paying someone and who you're paying - based on their public RSA key).

I don't understand what you mean.  Which server are you talking about?   Drazvan's system doesn't rely on a 3rd party server,  it is a private key exchange between two people.

[drazvan]

This obviously doesn't offer the same guarantees (the entity running the server would see your requests to the virtual smartcard, so it could theoretically tell when you're paying someone and who you're paying - based on their public RSA key).

I don't understand what you mean.  Which server are you talking about?   Drazvan's system doesn't rely on a 3rd party server,  it is a private key exchange between two people.

No, Eternity's right, we could theoretically look at our proxy to see the (encrypted) traffic between parties. We could see who's transferring to whom. However, the actual transaction is encrypted with a negotiated key (Diffie Hellman exchange), so we can't see that.

So yes, using our proxy makes things a little less private - but remember, you're coming from Bitcoin transactions where _everything is public_. In a Bitcoin transaction _everybody_ knows who you're paying, in a proxied OtherCoin transaction we could theoretically know who you're paying (but not to what address and how much). And in OtherCoin you have the option to just pay in person using NFC or QR codes or SMS (although you could say SMS goes through the wireless operator, so they would know that you're paying someone).

The proxy is there for convenience and is optional, it doesn't automatically push the data through us - there's a button that you need to press to upload the data to our proxy. It makes things easier for transactions with remote users if you choose to use it.

[beeblebrox]

That sounds like a good idea - although I'm not sure a web service is needed to do the change. If you want to split 1 BTC into 10 * 100mBTC or 100 * 10mBTC you can always go through Bitcoin (that is redeem a 1 BTC OtherCoin, then feed the balance into 10 or 100 smaller OtherCoins).

A web service could be useful though for premium services - that is the ability to split a larger coin into smaller ones without advertising this on the Bitcoin network and also getting confirmed or balance certified coins in return. So you would give the service your 1 BTC OtherCoin and it would give you 10 * 0.1BTC OtherCoins with more than 6 confirmations on their balance (or simply with a signed balance - regardless of the number of confirmations).
....

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.

[drazvan]

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!

[marcus_of_augustus]

Interesting to know it is still alive.

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

[drazvan]

Interesting to know it is still alive.

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 .

[drazvan]

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.

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 .