Launch of BitPay, worlds first smartphone-ewallet for bitcoins

[warpi]

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 using ewallets. 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=OW7Y7eAqBXY

More information:
https://en.bitcoin.it/wiki/BitPay
https://github.com/warpi/BitPay
https://market.android.com/details?id=com.bitcoin.bitpay

If you have any ideas or comments, please write it here or add issues to github.
https://github.com/warpi/BitPay/issues

Happy bitcoining!

https://ssl.gstatic.com/android/market/com.bitcoin.bitpay/ss-320-0-0
https://ssl.gstatic.com/android/market/com.bitcoin.bitpay/ss-480-1-0

[SgtSpike]

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

[bji]

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=OW7Y7eAqBXY

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

[EricJ2190]

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.

[Luke-Jr]

- An optional price of an item

Please be sure to do this right, using integer satoshi units, not some high-level units like BTC.

Might make sense to support the already existing bitcoin: URI standard encoded in QR-Codes.

[SgtSpike]

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?

[warpi]

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.

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!

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.

[Ian Maxwell]

I just downloaded the version in the Android Market. I realize this is a very early release, but there are a few features that would make it a lot more convenient:

• copy/paste addresses (!)
• an address book
• allow me to see the address of my Instawallet, so I can access my money if my phone is lost or destroyed (!!!)

[kangasbros]

There is hardcoded wallet in the source code

Code:

 24         //FIXME
 25         this.accountVector.add(new BitPayAccount("My Account_1", "174MgqAd2NqnwAcpajCQBo3AhwaEQDCUT1", "https://www.instawallet.org/w/9ODM4oWAiq9oXE4Ji6qTsg"));
 26         this.account = this.accountVector.get(0);

[luv2drnkbr]

I just downloaded the version in the Android Market. I realize this is a very early release, but there are a few features that would make it a lot more convenient:

• copy/paste addresses (!)
• an address book
• allow me to see the address of my Instawallet, so I can access my money if my phone is lost or destroyed (!!!)

I also vote for those ideas, except the last one.  Your Instawallet address generated by the program is shown in the "credits" tab at the bottom.

Also, the program keeps force closing on me right after the barcode scanner snaps the QR code.  I made a QR code in the exact same format in an attempt to test it and the program just force closes.  Still, I like the idea, it's a great interface, and as soon as you allow for a text box to type/paste addresses, and have an in-client address book, (and of course, get it working for me!), I will be ecstatic.  This is what will allow bitcoin to flourish.

Edit:  I'm using a rooted Droid 1 with UD 2.5

[ribuck]

... the worlds first working smartphone application for sending and receiving bitcoins ...

Not the first smartphone app!

Forum user doublec ported bitcoind to the Nokia N900 smartphone, and on December 7 2010 we exchanged coins phone-to-phone.

[warpi]

... the worlds first working smartphone application for sending and receiving bitcoins ...

Not the first smartphone app!

Forum user doublec ported bitcoind to the Nokia N900 smartphone, and on December 7 2010 we exchanged coins phone-to-phone.

Ok, thanks for reminding. I changed now to ewallet application then

There is hardcoded wallet in the source code

Code:

 24         //FIXME
 25         this.accountVector.add(new BitPayAccount("My Account_1", "174MgqAd2NqnwAcpajCQBo3AhwaEQDCUT1", "https://www.instawallet.org/w/9ODM4oWAiq9oXE4Ji6qTsg"));
 26         this.account = this.accountVector.get(0);

Sorry, this is a little embarrasing. To our defence, accountVector is not used, so nothing to worry about.

Also, the program keeps force closing on me right after the barcode scanner snaps the QR code.  I made a QR code in the exact same format in an attempt to test it and the program just force closes.  Still, I like the idea, it's a great interface, and as soon as you allow for a text box to type/paste addresses, and have an in-client address book, (and of course, get it working for me!), I will be ecstatic.  This is what will allow bitcoin to flourish.

Edit:  I'm using a rooted Droid 1 with UD 2.5

I have no idea what is wrong then?

I just downloaded the version in the Android Market. I realize this is a very early release, but there are a few features that would make it a lot more convenient:

• copy/paste addresses (!)
• an address book
• allow me to see the address of my Instawallet, so I can access my money if my phone is lost or destroyed (!!!)

I also vote for those ideas, except the last one.  Your Instawallet address generated by the program is shown in the "credits" tab at the bottom.

Copy paste addresses, what do you mean with this? That there shall be a input field instead of textfield?

Addressbook would indeed be nice!

[Blackhawke]

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

While I think that POS capability is essential to really see bitcoin take off in the brick and mortar retail setting, I'd like to point out that merchants don't really NEED all the stuff that was mentioned in the above abbreviated quoted post. Merchants already have their inventory control systems and cash systems and so on. Those systems are in place. What they really need is the bitcoin software that taps into that existing system.

For example: If you're going to pay with bitcoin, rather than getting a "slide your card" command on the card reader, maybe it pops up the QR code with the amount of sale. The buyer then reads that code from within whatever bitcoin app and whalla! Sale closed. If the merchant wants to expedite confirmation, they can add that fee into the price (or eat it, the way they already do with credit and debit card purchases). Again, this is already native to the existing bitcoin system. And from the merchant's perspective, it would be a "merchant services fee" or "bank transaction fee" on the accounting end. Again, their software already handles that. The bitcoin software would simply have to tap into their API.

Just my 0.02 BTC on mechant POS. 

[warpi]

Have anyone tried this at a merchant yet? Of what I read in the news, people have so far been carrying their laptops to buy things using bitcoins...

[done]

Don't forget us iPad users 

[warpi]

Don't forget us iPad users 

Sorry, but micro$oft and app£e are just to proprietary. Google sucks aswell, but atleast, their os is open source.

[done]

Don't forget us iPad users 

Sorry, but micro$oft and app£e are just to proprietary. Google sucks aswell, but atleast, their os is open source.

[netrin]

This is great news. I wish you luck with the project. May I suggest you accept firstbits.com minimal/unambiguous/case-insensitive addresses?

[realnowhereman]

This is lovely little app.

Here's some suggestions:

• "From Camera" is an enormous button.  Smaller would be nicer.  In fact, what about a little camera icon next to the receive address text field...
• ... the address on the send page should be a text field; that can be pasted into.  (Say I want to deposit to Mt.Gox, there is no QR code to scan; and even if there were I can't take a photo of the QR code on the phone's screen)
• Copying the account address to the clipboard should be possible. This is so it can be cut and pasted into a website (say I want to withdraw from Mt.Gox to my Instawallet address)
• How about integrating the APIs for Mybitcoin, Mt.Gox and Tradehill accounts as well?  It would be very cool to be able to switch to any of my online wallets and have the same UI for all.
• The balance should be displayed larger and should be outside the tabs (and "account" and the address for that matter).  Balance is neither "send" or "receive" related; and is arguably the key thing we want to know about the account.
• Ability to program our own Instawallet URL.  I already had an Instawallet.  It would have been nice to be able to connect to it instead of having BitPay make a new one.
• Updating balance should be done in a different thread.  During update the UI freezes, changing tabs isn't possible.
• When selecting the "amount" field on the receive tab to enter a number, the keyboard is in alphabetic mode.  We're never going to want to put letters in an amount field; set the keyboard to numeric mode
• The "amount" field on the send and recieve tabs should be in the same physical position on screen
• The screen real estate used by "Account: instawallet.org" is a bit of a waste; can't that be on the credits page?  We don't need to see it all the time.  Perhaps you're planning multiple account support in the future?  In which case I withdraw this point.
• The amount fields should all have more than two decimal places shown when they are showing zeros (or any other number)
• A widget that can be dropped on the home screen to show current balance

[warpi]

This is great news. I wish you luck with the project. May I suggest you accept firstbits.com minimal/unambiguous/case-insensitive addresses?

Thx

When I go to firstbits.com, It says "FirstBits.com is down for maintenance. Check back soon.". What is it about?

This is lovely little app.

Here's some suggestions:

• "From Camera" is an enormous button.  Smaller would be nicer.  In fact, what about a little camera icon next to the receive address text field...
• ... the address on the send page should be a text field; that can be pasted into.  (Say I want to deposit to Mt.Gox, there is no QR code to scan; and even if there were I can't take a photo of the QR code on the phone's screen)

Agree, added a issue about this on github.
https://github.com/warpi/BitPay/issues/12

• Copying the account address to the clipboard should be possible. This is so it can be cut and pasted into a website (say I want to withdraw from Mt.Gox to my Instawallet address)

Very good idea, already knew about the issue, but this should be an easy fix.
https://github.com/warpi/BitPay/issues/5

• How about integrating the APIs for Mybitcoin, Mt.Gox and Tradehill accounts as well?  It would be very cool to be able to switch to any of my online wallets and have the same UI for all.

Definitely, this would be our aim. I add it to the issueslist
https://github.com/warpi/BitPay/issues/13

• The balance should be displayed larger and should be outside the tabs (and "account" and the address for that matter).  Balance is neither "send" or "receive" related; and is arguably the key thing we want to know about the account.

Yepp, I have been thinking of moving the tabs to the bottom, and then maybe have the balance at the top?

If you have purposals, please comment these at this issue
https://github.com/warpi/BitPay/issues/3

• Ability to program our own Instawallet URL.  I already had an Instawallet.  It would have been nice to be able to connect to it instead of having BitPay make a new one.

Yep, added this in the issue below
https://github.com/warpi/BitPay/issues/13

I will come back to comment the other ideas aswell, but now I have to leave for work. Cya