Hello,
Today me and leifi wrote the last piece of code to make BitPay work. It will be the worlds first working smartphone application for sending and receiving bitcoins. It uses 2D barcode using the camera for transfering the bitcoin address of the receiver.
The project is licensed as Apache V2 which is completely open source and easily accessed at
https://github.com/warpi/BitPay. The code sucks but it works
Please notice that we really prioritized that the application should come up at market as soon as possible before beauty or usability
This is how you download it and install it
http://www.youtube.com/watch?v=OW7Y7eAqBXYIf you have any ideas or comments, please write it here or add issues to github.
Happy bitcoining!
Nifty idea. Might I propose that you begin standardizing a 2D barcode data format to make this useful in a point-of-purchase setting. I think that the 2D barcode information should include:
- A bitcoin address
- An optional description of an item
- An optional price of an item
- An optional 64 bit item identification number
- An optional public key signature of the description, price, and item number
A retailer could embed the description, price, and 'stock number' of an item for sale in the 2D barcode and could sign it with their public key. Your bitcoin software could read such a 2D barcode and when detecting these optional fields present a more detailed 'pay' screen listing the item description, its price, and optionally its item identification number (although that would generally not be useful for the end-user to see). The software would also verify that the signature of the description, price, and item number matches the signature of the bitcoin address to ensure that the owner of the address really described the item using those fields and there hasn't been tampering. Also, the software might optionally validate that the public key is really that of the retailer (maybe the retailer could have a separate bar code somewhere secure in their store that you can scan to tell you the retailer's public key). The reason for this would be to prevent someone printing out fake bar codes and pasting them on items in the store that would then pay them instead of the retailer for the item.
Once the above information is acquired, the software would generate a transaction for the given amount, to the given bitcoin address, with data embedded in the transaction (in some standardized form) giving the identification number of the item as well.
Then the retailer would be able to, once the transaction is verified, know exactly which item was paid for.
On the way out of the store, the user would re-scan the bar code at some checkout point which would verify that there was a transaction that paid the correct amount for the item.
This would make a nice point of sale system. Retailers would just need to have a device that generated 2D bar codes, one per item, with a nice UI for configuring the barcodes (i.e. setting up a single description and then running off 200 unique bar codes, each one with a different item number, each one individually signed, to be affixed to each of the 200 instances of that item they have in stock).
The only problem is the transaction verification delay before the user could verify their purchase and leave the store ...
