I'm not convinced this inversion is really a problem, but as this is quite
a complex proposal (e.g. new barcode types) the best way to move it forward
at this stage is to implement it in some existing wallets.
FWIW NFC is a lot more common than you might think. For the drive-thru case
you could also consider using wifi hotspots with a special name or
Bluetooth LE tags. So I suspect before trying to write a specification it'd
be better to explore different technologies and see what works best in
practice.
On Tue, Jun 24, 2014 at 9:44 PM, Paul Goldstein <p...@realfoot.com> wrote:
> Here's an idea for a BIP 70 extension to let wallets be scanned by
> merchant bar code readers to start off a payment request flow instead of
> the other way around (wallet scanning the merchant QR). Useful for brick
> and mortar merchants and mobile wallet apps.
>
>
> Motivation:
> A mechanism is needed for mobile wallets to request a bill, so that a
> payment protocol flow can be initiated. Current mechanisms for initiating
> BIP70 payment flows generally require wallets to either scan a merchant
> barcode (not optimal, see below), or click on a specially formatted url
> link (only suitable while browsing and purchasing on a merchant website).
>
> Successful non-bitcoin mobile wallet apps to date (a popular coffee shop
> app comes to mind) allow for the wallet app to be scanned by the merchant
> and not the other way around (as is commonly done in bitcoin wallets
> today). For broad bitcoin adoption we need a mechanism for wallets to be
> scanned by merchant bar code readers at brick and mortar shops. This will
> also greatly ease checkouts at drive throughs and allows merchants to
> leverage existing hardware (barcode readers).
>
> Other technologies like NFC may obviate the need for this extension,
> however, those technologies remain somewhat uncommon and may not be
> suitable for smaller wearables hitting the market.
>
> message BillRequest {
> required uint64 time = 1;
> optional uint64 expires = 2;
> required string bill_request_uri = 3;
> }
>
>
> time - Unix timestamp (seconds since 1-Jan-1970 UTC) when the BillRequest
> was created.
> expires - Unix timestamp (UTC) after which the BillRequest should be
> considered invalid (wallets may only be monitoring for messages for a short
> time).
> bill_req_addr - Typically a URL where a BIP70 payment request can be sent
> that is being monitored by the wallet. However this could also support URIs
> like "sms:860-555-1212" or "mailto:a...@gmail.com"; allowing for a variety
> of connection options.
>
> Recommendations: it is recommended that wallet apps display a non-QR
> barcode like a PDF417 barcode to initiate the Bill Request flow. This will
> avoid confusion with existing QR code usage in wallet apps.
>
> --------
> Paul G.
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
