[Bitcoin-development] Bill Request Message - (another) Proposed BIP 70 extension

[Bitcoin-development] Bill Request Message - (another) Proposed BIP 70 extension

[Paul Goldstein]

[-- Attachment #1: Type: text/plain, Size: 2135 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3635 bytes --]

Re: [Bitcoin-development] Bill Request Message - (another) Proposed BIP 70 extension

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 3401 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5438 bytes --]

Re: [Bitcoin-development] Bill Request Message - (another) Proposed BIP 70 extension

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

Alright. I still tend to think it's not a big deal, but there's no reason
both or all mechanisms can't co-exist.

BTW: a QR code next to a cash register can be fixed i.e. printed on paper
when using BIP70. The PoS would upload payment details to the server and
the URL for that particular PoS unit would then serve it when the user
scans the QR code. Alternatively, Andreas' work on Bluetooth may be more
appropriate: the QR code can contain the BT MAC of the device and the
payment request is downloaded that way. That's already implemented! I still
feel that if a seller can scan a users phone, the users phone can certainly
scan some rectangle that's physically near by the sales counter.

The other nice thing about that approach is the QRcode can also be an NFC
tag i.e. have the tag behind it with a little icon in the middle of the QR
code to indicate that touching works as well as scanning.

One project I keep wanting to play with is making these little NFC-QRcode
hybrids and a simple PoS app to go with them. But no time, alas ....

[-- Attachment #2: Type: text/html, Size: 1166 bytes --]