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 <paul@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:asdf@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
>
>