Mobile client design ideas

[Hal]

Several people have mentioned they are working on mobile clients (at least Android, don't know about iOS). But I haven't seen much discussion of the design in terms of security and performance issues.

In another thread, http://bitcointalk.org/index.php?topic=2957.msg41905#msg41905, [mike] made a provocative comment: "1) Are you trying to make an Android client? You don't want to verify transactions if so."

Can mobile clients get away without verifying transactions? Maybe they could just rely on the block chain. Any transaction in a block that has enough confirmations is considered to be good. Checking blocks is both easy and quick, pretty much just hashing.

The one problem I see would be a possible delay in knowing that payments to you are valid. It wouldn't matter for payments to merchants who can run regular clients, but payments from one mobile user to another might be slow to be validated.

Another possible shortcut would be for mobile clients not to forward blocks, transactions, and addresses the way regular clients do. Network transmissions draw a lot of power. Mobile nodes could just leech. If they don't process transactions, they wouldn't even need to read those.

iOS doesn't have true multitasking. I don't think a client could receive the block chain in the background. Android presumably doesn't have this problem, but the question would be impact on battery life to keep the client running all the time.

[theymos]

The one problem I see would be a possible delay in knowing that payments to you are valid.

Network nodes won't forward an invalid transaction, so it would probably be mostly safe to show an unconfirmed transaction if you received it from a few different peers.

[dirtyfilthy]

Can mobile clients get away without verifying transactions? Maybe they could just rely on the block chain. Any transaction in a block that has enough confirmations is considered to be good. Checking blocks is both easy and quick, pretty much just hashing.

The one problem I see would be a possible delay in knowing that payments to you are valid. It wouldn't matter for payments to merchants who can run regular clients, but payments from one mobile user to another might be slow to be validated.

Another possible shortcut would be for mobile clients not to forward blocks, transactions, and addresses the way regular clients do. Network transmissions draw a lot of power. Mobile nodes could just leech. If they don't process transactions, they wouldn't even need to read those.

iOS doesn't have true multitasking. I don't think a client could receive the block chain in the background. Android presumably doesn't have this problem, but the question would be impact on battery life to keep the client running all the time.

This is an excellent point and one I've been wondering about myself. Exactly how would a thin client operate? I've also heard talk about using the "headers" command (in the standard client but not currently used) to download just the block headers and not the transactions, though I'm not sure how this would work in practice. Don't you need the blocks to see the transactions to know if someone can spend the money?

I'm designing my client to leech only and not forward.

[theymos]

Don't you need the blocks to see the transactions to know if someone can spend the money?

You don't need to know whether they can spend the money -- the network will verify this for you through the block chain.

On first run, you can use the "headers" command to get all past blocks. This will take only minutes. However, after that you need to download full blocks in order to detect and use your own transactions. You can discard all transactions that aren't yours, though.

There is an even more lightweight mode that doesn't ever require downloading full blocks, but the sender has to give you extra data through some out-of-band method. This mode hasn't been implemented yet, whereas "standard lightweight" mode is already semi-implemented and can be enabled in Bitcoin by setting the fClient variable to true and recompiling.

- Normal mode: full blocks and transactions
- Lightweight mode: block headers and recent full Merkle trees
- Ultra-lightweight mode: block headers and those Merkle branches that are relevant to our transactions

Having the Merkle branch for a transaction allows you to securely find its number of confirmations without actually storing the transaction. In "standard lightweight" mode, you create complete Merkle trees for recent blocks after downloading the full blocks. Then you can discard the block bodies. In ultra-lightweight mode, senders must give you the Merkle branches for your transactions after sending them.

[Mike Hearn]

Trying to verify transactions for yourself on an Android phone is a bad idea, because secure storage is an extremely scarce resource on these phones. Bitcoin easily uses hundreds of megs of disk space today and it will only get larger in future.

Theymos has described the design I was heading for pretty well, before I ran into (non code related) issues with the open source release.

Walking the block chain means you don't have to store much data at all. In fact, you only need to store the block locator, a series of block headers that thin out exponentially from the head of the chain. I was planning on having the app download a signed copy of the latest block locator from my own server the first time it runs rather than doing a getheaders walk, as a performance optimization (you already have to trust the author of your wallet software).

Mobile clients cannot maintain long term connections to the network as that would rapidly drain their battery. A better design is to connect to a single node occasionally and then catch up with the head of the chain. Thus the block chain is taken to be proof that a transaction is valid (rather than multiple forwardings). It's also secure against your device connecting to malicious WiFi and then being fed illusory network connections, except for the potential for DoS.

Android makes it trivial to code up an app that wakes every night when it's plugged in to recharge and catch up with the block chain (by downloading full blocks). You could ramp that up to multiple times per day if necessary. Then you can do a final catchup in the background when the app is opened.

The next improvement is to use the C2DM framework along with a relay node. The relay maintains a list of addresses that mobile clients are interested in along with their C2DM registration IDs. When the relay observes valid transactions (where "valid" means the node accepts them and would incorporate them into a block), it then sends a message to the phone notifying it that it received some coins. This can trigger a notification to the user, updating of the balance etc - possibly with some UI marking the payment as "provisional" but as most attacks against such a system are fairly exotic, it might not be worth imposing the additional mental burden on the user.

The wallet can be backed up via the Android cloud backup system. However, note that this means the security of your wallet becomes equivalent to the security of your Google account (which isn't very secure given that you likely access it from machines that can get malware on them, people get phished etc). What you really want is the phone to encrypt the backups, have the key be generated on the device, and then be exported from it in such a way that the export/import process is secure. I haven't really figured that one out yet. Cloud printing may be the way to go in the long term - your phone could directly talk to a printer and print out a QRcode containing the key.

Once all this is in place, you are ideally situated to expose a BitCoin address via the NFC chip in modern phones like the Nexus S. This will allow touch-to-transact in which two people touch their phones together and one can then type in a quantity of BitCoins to send to the other. With the C2DM relay infrastructure transaction times would be measured in seconds, which is competitive with the existing VISA/MC infrastructure.

The final problem to solve is the user interface problem. Typing BitCoin addresses into a phone is even more awkward than on a PC. Ultimately, BitCoin addresses are not meant to be human friendly identifiers despite the use of "base58". A better solution is to re-use the C2DM infrastructure again, to make the BitCoin app be remotely controllable from your PC. You could then send coins by simply typing the address and quantity into some app run by the Android BitCoin developers, press "go" and then press confirm on your phones screen when it displays the confirmation activity a few moments later. Indeed, basically all actions can be handled via a web connected PC in this manner, and the security of the system comes from the need to physically press the device at the very last moment before a transaction takes place.

Hope that helps.

[theymos]

Walking the block chain means you don't have to store much data at all. In fact, you only need to store the block locator, a series of block headers that thin out exponentially from the head of the chain.

Don't you need all headers to find the chain length, so you know which chain is real? Do you have to re-download headers to get a transaction's number of confirmations?

[tcatm]

The final problem to solve is the user interface problem. Typing BitCoin addresses into a phone is even more awkward than on a PC. ...

What about QR codes to transfer addresses? I use them for js-remote and they work great for transferring coins from/to my Android phone. I'm using the URI scheme from the wiki.

[Mike Hearn]

I don't think so? You can just store the length/difficulty of the longest chain you know about alongside the block locator. Unless I'm missing something (I didn't actually implement that part yet).

QRcodes seem a lot less convenient to me than just copy/pasting an address between tabs in a web browser and pressing "go". Both Android and iPhone allow web apps to send messages directly to phones for free, so why bother with scanning stuff off the screen?

[tcatm]

QRcodes seem a lot less convenient to me than just copy/pasting an address between tabs in a web browser and pressing "go". Both Android and iPhone allow web apps to send messages directly to phones for free, so why bother with scanning stuff off the screen?

Even if you didn't use QR codes you could still use the URI scheme to transfer address, amount and a short message to the client. With Bitcoin we don't need bi-directional communication when transferring such payment requests, so it's useful to have one scheme that can be transmitted via different communication channels. Copy and pasting raw addresses will always work, but I think it's important to add extra information so the user knows what he's going to pay for and doesn't need to enter the amount manually, especially on a phone with only a touchscreen.

[Hal]

Walking the block chain means you don't have to store much data at all. In fact, you only need to store the block locator, a series of block headers that thin out exponentially from the head of the chain. I was planning on having the app download a signed copy of the latest block locator from my own server the first time it runs rather than doing a getheaders walk, as a performance optimization (you already have to trust the author of your wallet software).

What do you mean by walking the block chain? Could you clarify what you would do when you receive a block containing a payment transaction to one of your addresses? Do you need to go back and look at old blocks? Or can you just assume it's valid because it's in a block, possibly waiting for some confirmations, in which case maybe you don't need to save old blocks at all.

[Mike Hearn]

Yes, you keep a few block headers around so you can get back onto the main chain if you find yourself on a fork but otherwise they can be thrown away. Presence of the tx in a valid block is ipso-facto proof of tx validity. Without n out of band mechanism like signed tx's from a trusted relay node you'd have to wait a block to receive coins.

With OOB signaling you have lower latency coin receiving but you have to trust some third party network node.

[theymos]

The client is unable to process block chain reorganize events without all headers. After a reorganize, the number of confirmations for its transactions will change (and some may become invalid), but it won't be able to check the number of confirmations.

Additionally, the client won't even be able to recognize a reorganize. The length of the new chain can't be computed because the client doesn't know where the branching point is.

A trusted peer could provide this information, but that would give the trusted peer the power to double-spend. In that case, the trusted peer might as well do all the block chain stuff.

[Mike Hearn]

When the client triggers block chain download it has to provide the locator to the peer, and then the blocks start streaming in from wherever the closest block to the top is based on that.

Usually that'll be the last block in the locator. In the case where the block chain forks, it might be some blocks backwards, in which case you will know because the blocks the client sends connect to one of the middle blocks in the locator not the top.

If the chain does fork, you throw away the now useless branch and download the new best branch. Each block is scanned for transactions that are already in the wallet. Transactions that are in the wallet but not yet found in the new block chain are invalid and you must wait for them to be included again post reorganize before spending them.

I didn't implement support for this but as far as I can tell, it should work?

If not it's no big deal. Headers by themselves aren't too bad, it's what, 5 megabytes per year of operation or something like that? Storing hundreds of megabytes on Flash or SDcard storage is kind of obnoxious for a wallet app. 10-20 megabytes is a bit more reasonable. A block locator by itself would be even better but if it really can't work, we'll live.

[Andreas Schildbach]

I'd like to comment on the C2DM idea. I'm a bit sceptical about the benefits of C2DM.

First, it's platform dependent. You'd have to implement a relay for Android, and for iOS, and for WebOS, and so on.

How comes that none of the Google Apps, with the exception of the example app "Chrome2Phone", uses C2DM? There would be some that would fit the usecase of C2DM: Google Talk (IM), VoIP calls, Twitter, Google Reader.

A TCP connection while not receiving any data should consume no energy at all. Isn't it all a matter of limiting the data to relevant messages?

Perhaps an extension of the regular BitCoin nodes would be feasible, some kind of "I am only interested in BC-addresses x and y" filter that can be applied. Maybe this is a privacy problem, but wouldn't a C2DM relay need the same kind of filter?

[Mike Hearn]

Google apps do use C2DM. C2DM is just the public name for the push messaging service that is based on holding open a long lived Google Talk connection. Market, Talk, Contacts and more use this functionality, they just happen to use a private version of the APIs rather than the public API (for legacy reasons).

I don't think it's a good idea to try and recreate C2DM in the context of BitCoin. It's a long term project at minimum. As just one example of the things it solves for you, TCP connections time out if you don't use them. The timeouts are dependent on the carrier NATs and vary across networks. What's more they sometimes cannot be detected except by sending pings and hearing a response back. So the C2DM framework discovers the heartbeat interval needed for a particular network adaptively - if you wanted to be as power efficient as it is, you'd have to reimplement that logic.

Also, if the user wanders into an area in which there is no radio connectivity, you have to detect that outage and not try to constantly connect back to the network until it comes back.

C2DM connections are encrypted. Public P2P connections are not. That latter on doesn't matter that much because most of the time, the traffic on the P2P connections is broadcast traffic anyway, anyone can receive it. An eavesdropper can only figure out your addresses if you actually send money from them, and even then it requires carefully correlating inbound and outbound transactions. But if you had a monitoring command, anyone you connected to would be able to see all keys you own. With the C2DM model you only have to trust the C2DM relay node operator with your address list (which could even be yourself, if you wanted to do that, as C2DM registration is free). With the P2P model you have to trust everyone and there isn't any way around that.