Quote from: SgtSpike on June 30, 2011, 03:23:16 AM

Quote from: EricJ2190 on June 30, 2011, 12:05:02 AM

Quote from: SgtSpike on June 29, 2011, 11:01:19 PM

Does it store the entire blockchain on the mobile device, or have you figured out a way to program a "lite" wallet?

It doesn't store any of the blockchain. It is not a Bitcoin client itself, simply a frontend for Instawallet.

Ahhh, ok. Still, that's neat, and that gets the ball rolling on mobile wallets, which are desperately needed!

I'm not sure what sort of 2D barcode format you are currently using, but why not simply adopt the now-standard QR code?

The idea was to make a light application which consumes little battery capacity, requires little cpu resources and memory, and where the transactions goes fast (dont require confirmations). The only way to solve this, is to use E-wallets.

Therefore we pick the best suited e-wallet today and we found InstaWallet.org. In future, BitPay could support a whole list of E-wallets.

Quote from: bji on June 29, 2011, 11:42:05 PM

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).

Thanks

I will think about how to implement QR in a better way for supporting reailers, this is good ideas!

Quote from: bji on June 29, 2011, 11:42:05 PM

The only problem is the transaction verification delay before the user could verify their purchase and leave the store ...

This is actually not a problem is you are using E-wallets. Within the same E-wallet the transaction would be instant, and between E-wallets, it would be up to their co-operation to ensure instant transation. Its only through untrusted nodes on the bitcoin-network you need to wait for confirmations.