Today's #bitcoin-dev featured an interesting discussion of mobile phone use, centered around the following use case:

• customer walks into real-world stores, selects several items, and walks to cashier to check out
• cashier displays QR-code on customer-facing screen
• customer uses mobile phone to take picture of QR-code
• mobile phone displays "Big Box Store Corporation, Inc, requests a payment of 300 BTC.  Do you agree?  Yes / No"
• customer agrees (or cancels the sale), triggering BTC transfer from customer to merchant

As such, tcatm, nelisky and I started typing out notes for APIs at http://www.bitcoin.org/wiki/doku.php?id=phone_api   I'll let tcatm or nelisky talk about payment requests if they wish, but I wanted to focus on defining a QR-code specification that people could start using immediately.

Each of these is a text string in the style of RFC822 headers (“key: value”), where “value” is further separated by semicolons. Strings containing semicolons or spaces may be quoted with double-quotes (").  Double-quotes themselves are escaped in the obvious way, with a back-slash.

1) Bitcoin address.  Not directly related to the purchase-via-mobile-phone scenario just described, but obviously necessary.

Using this QR-code, you may share bitcoin addresses with others via mobile phone.  Use this QR-code on the forum or your website, to give out your bitcoin donation address!


2) Merchant request for direct payment via bitcoin network.

Using this QR-code, the mobile phone knows enough to ask the user if they wish to pay 300 BTC to My Bitcoin, Inc. at the given bitcoin address.  Presumably the mobile phone has the ability to make bitcoin payments, either directly (a lightweight bitcoin client) or indirectly via a payment API such as this.


3) Merchant request for indirect payment via a custom payment processor.

Using this QR-code, assuming that the mobile phone app is aware of an API known as "mtgox", the mobile phone knows enough to ask the user if they wish to pay 300 BTC to My Bitcoin, Inc., using the specified custom Web API.

The "1" suffix implies version 1 of that QR-code.  An incompatible change would imply "bitcoin-address1" becomes "bitcoin-address2", etc.

NFC could easily transfer these strings too...

Encourage to use a DataMatrix!

QR-code is more proprietary than DataMatrix and DataMatrix fully implemented in very good open source library and utils called 'dmtx'.

Here on the end of the page you can see the comparison of the codes with same text: https://btcex.com/

QR-code has one advantage - it is recognizable by 'typical users'.

I could not find open source utility that would be correctly encoded raw 8-bit data (for pgp keys backup)

Also, the shape of the big Data Matrix labels will not necessarily be square, as far as I know.


Almost any computer parts already contains a small datamatrix label

Basically this is duplicating the work we are doing on the bitcoin URI scheme. Since we can encode the URIs can easily be represented using QR codes I think we should stick with the bitcoin:-URI Scheme 

Just my 0.02 BTC

There is however the other usecase where I just want to share an address and a name:
- I go out with friends and want them to have my public account address
- I just want to put a donations image on my homepage

Ideally that would contain a name (If in one evening I get a dozen of addresses from friends I want to be able to distinguish them later), a description and an address.

That is imho not handled by URI's or x-btc. There is a need for standartizing that kind of information



The vector of the information is irrelevant! It needs to be so short it can fit in a QR, tweet, DataMatrix, SMS, needs to be unique, possibly human readable and that's it.

Let's worry about the vector later. As soon as there is a good standard we can all get behind, we can worry about how and where to encode the information