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.

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.