Quote from: drazvan on May 01, 2014, 04:05:31 PM

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.