Hello!
I am new to the world of Bitcoin and am pretty excited about its potential! I was introduced to Bitcoin yesterday and got to daydreaming on its future.
As I'm sure most here would, I hope for Bitcoin to become widely used, and I feel that it is necessary for a system that enables brick-and-mortar merchants to use BTC POS. Such a system would surely promote Bitcoin, if it's easily adoptable. The idea I have in mind could also work for face-to-face transactions. Please let me know what you think!
Before I go on, I read the following posts which discuss this, but lacked any resolution on direction of development:
http://forum.bitcoin.org/index.php?topic=7539.0http://forum.bitcoin.org/?topic=7872.0The latter post is somewhat in the direction I was thinking. These main points were listed:
• There should be a public RFC spec for the online wallet site
• Anyone should be able to deploy such site online, in case that person has reservations about other such sites out there, aka open source reference design
• There should be a common API for sending transactions to such site, authorizing the site to perform a money transfer
Here's my idea as an example.
In the system I am thinking, a customer, Bob, has Bitcoins and wants to buy a cup of coffee. The cashier rings up the total and Bob presents his card. It is a home-printed QR code (placed in a plastic sleeve
). It is scanned, and the QR contains the following pieces of data:
* A public key generated by a wallet service
* IP address, domain name or other location info of the wallet service
* [additional needed info that fits within the QR alphanumeric size limit]
Once the information is scanned, the merchant processing terminal communicates with the wallet service using a standard protocol. It could begin by sending the wallet service the customer's public key, transaction details, some logging information, etc. The wallet service would then reply with a user-defined security key phrase or image to be displayed on the POS system, and await a PIN confirmation. Once the PIN is confirmed, the wallet service could finally reply with the actual Bitcoin transaction, and possibly location of nodes in the swarm whom the transaction was broadcasted (to hasten confirmation)
The 'terminal' could be a laptop with a webcam, with a secondary keypad for the PIN, all cheap and accessible hardware for most merchants.
The Security Key image or phrase is set up upon wallet service, and can be changed at any time for enhanced security.
Since all needed information can be stored on easily-destroyable and printable QR codes, new "cards" can be generated whenever a user feels the need to be more secured. The wallet services could retire older QR-cards' keys, or they could expire.
I feel it is important, as mentioned by Vasili in the quoted post, that the wallet service be designed such that anyone may deploy/design one. Of course, there may be a security/availability incentives so not to host one yourself, but the option should be available. Since the conformation of transactions would be built into the protocol, there should be no fraud issues due to this option.
Online wallet services could also communicate in real-time with customer cellphones or other devices for verifications, instead of security key/pin, which allows for added security. Such an auxiliary verification could be worked into the protocol, with an option for merchants/customers to prefer/require one or the other. A customer's QR code could be scanned, and then the wallet service would direct the verification to the customer's device, opposed to a possibly-compromised terminal. Another option for POS transaction flow would be for the POS terminal to await PIN entry, but also provide the option to defer the security entry to a secondary method. A Customer at the PIN entry stage would hit cancel, and then verify elsewhere.
Similar QR-based exchanges could work between smartphones for person-to-person exchanges. A money-sender with a printed or device-displayed QR 'debit card' could be scanned by the recipient's smartphone, verified on the recipient's smartphone with security key/pin (requires trust from sender), or verified on an third terminal, email, SMS, etc, depending on how the wallet service is set up.
Just would like to restate that this hypothetical wallet service is intended to be open and self-deployable if desired, although the incentives would likely dissuade most from this.
That's the bulk of my thoughts. Hope I wasn't too long-winded. Please let me know if you think this is something that could work. Seems like it could be a cost-effective means of reaching a wider audience. The only hardware needed for merchants is a laptop with a webcam, or even simply a smartphone with a bitcoin POS app. And, of course, a "wallet service".
Thanks,
Dan
