bitcoin mobile phone specification?

[jgarzik]

For the purposes of discussion, let us assume 1 million mobile phones exist, each with a bitcoin wallet, and the ability to make payment via bitcoin.  If we naively follow the current bitcoin client design, each one of those 1 million mobile phones would connect to the bitcoin P2P network, and relay the entire world's transactions to its ~8 network peers.

Quite unscalable; unrealistic to expect a mobile phone to do that, especially in many parts of the world where data traffic is expensive and/or incredibly slow.  So what are the alternatives?  Three come to mind:

1) Connect to a bank or service that provides a web API.  Easy, non-standard. Requires trusting a third party SPOF.
2) Set up your own bitcoin, and access that remotely via JSON-RPC from mobile phone.  Moderately difficult, and not scalable.
3) Connect to the P2P network, and using a subset of the existing P2P network protocol, send and receive transactions for the wallet stored on the mobile phone.

While options #1 and #2 are the most reasonable and realistic in the short term, it seems helpful if attention is directed to option #3, which is the most decentralized, pro-privacy option.

Therefore, I propose that we seek to identify a subset of the current bitcoin P2P protocol, that may be used optimally by low power, low bandwidth devices such as mobile phones.


Suggested bitcoin specification for mobile phones, version 0.1

The following is a list of basic operations one needs to support decentralized mobile phone wallet/spend, with suggested implementations.

• Spending bitcoins -- creating and sending a new transaction -- appears easy.  Connect to one or more P2P nodes, and send a 'tx' message.  For bonus points, sample several random network locations, to make sure your TX is getting passed around the network.
• Waiting for confirmation of a recent spend -- Poll one or more P2P nodes for newly created blocks using 'getblocks' and 'getdata'.
• Receiving bitcoins -- Poll network nodes every few minutes, download all new blocks seen using 'getblocks' and 'getdata'

Creating and distributing a TX seems straightforward, but receiving bitcoins is definitely an inefficient operation.  One wonders if there is any modification to the bitcoin protocol that could improve the situation?  Perhaps a new network message 'polltx', that scans recent transactions/blocks for activity on a list of public keys (wallet addresses).

The main goal of all this is (a) avoid relaying all the world's bitcoin transactions, while (b) remaining a fully decentralized bitcoin payment solution that requires nothing more than the P2P network itself.

[ribuck]

... it seems helpful if attention is directed to option #3, which is the most decentralized, pro-privacy option

Yes. In a decade, mobile data will be ubiquitous, so it's best to work towards the best long-term solution.

• Receiving bitcoins -- Poll network nodes every few minutes, download all new blocks seen using 'getblocks' and 'getdata'

How about: poll the network and download new blocks whenever the phone is charging and connected to WiFi, but otherwise only on demand.

Most of us can get through the day spending BTC that are already known to the phone, and an overnight resync will be enough. But if someone sends us an SMS saying they've paid us, and we absolutely need to confirm it today, we can pay (with data charges and battery life reduction) to confirm it sooner.

[MoonShadow]

Therefore, I propose that we seek to identify a subset of the current bitcoin P2P protocol, that may be used optimally by low power, low bandwidth devices such as mobile phones.

There is a subset that exists to support a 'lightweight' client, that neither generates nor requires a complete blockchain, but only the blockchain headers and transactions relevent to the phone's balance.  Such a thin client has not yet been coded, but it's need has been considered in advance.

[theymos]

I see a few options for learning about your transactions:
- Have the sender give you the transaction hash, and then use getdata
- Download (and then discard) all new blocks
- Use IP transactions (hopefully with some sort of authentication). Maybe using a built-in system like Tor's hidden services.

"Polltx" would be really bad for anonymity. Even people who are not paranoid would probably have a problem with the information divulged there.

[jgarzik]

There is a subset that exists to support a 'lightweight' client, that neither generates nor requires a complete blockchain, but only the blockchain headers and transactions relevent to the phone's balance.  Such a thin client has not yet been coded, but it's need has been considered in advance.

The point of this thread is to flesh out / discover the specifics of this approach.

"transactions relevant to the phone's balance" is, in particular, not immediately obvious, at least not without knowing ahead of time the TX hash.