From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WzWeH-00026M-Pp for bitcoin-development@lists.sourceforge.net; Tue, 24 Jun 2014 19:44:57 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.54 as permitted sender) client-ip=209.85.213.54; envelope-from=idigix@gmail.com; helo=mail-yh0-f54.google.com; Received: from mail-yh0-f54.google.com ([209.85.213.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WzWeF-0006sQ-Nj for bitcoin-development@lists.sourceforge.net; Tue, 24 Jun 2014 19:44:57 +0000 Received: by mail-yh0-f54.google.com with SMTP id i57so519672yha.13 for ; Tue, 24 Jun 2014 12:44:50 -0700 (PDT) X-Received: by 10.236.223.229 with SMTP id v95mr4494224yhp.128.1403639090257; Tue, 24 Jun 2014 12:44:50 -0700 (PDT) MIME-Version: 1.0 Sender: idigix@gmail.com Received: by 10.170.151.10 with HTTP; Tue, 24 Jun 2014 12:44:30 -0700 (PDT) From: Paul Goldstein Date: Tue, 24 Jun 2014 15:44:30 -0400 X-Google-Sender-Auth: p8DOm9lHGqhVWIcHV0tXv_aWNik Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c1ecbe5e25cd04fc9a3152 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (idigix[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WzWeF-0006sQ-Nj Subject: [Bitcoin-development] Bill Request Message - (another) Proposed BIP 70 extension X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:44:58 -0000 --001a11c1ecbe5e25cd04fc9a3152 Content-Type: text/plain; charset=UTF-8 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. --001a11c1ecbe5e25cd04fc9a3152 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here's an idea for a BIP 70 extension to let wall= ets 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). Use= ful 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 B= IP70 payment flows generally require wallets to either scan a merchant barc= ode (not optimal, see below), or click on a specially formatted url link (o= nly suitable while browsing and purchasing on a merchant website).=C2=A0

Successful non-bitcoin mobile wallet apps to da= te (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 f= or wallets to be scanned by merchant bar code readers at brick and mortar s= hops. This will also greatly ease checkouts at drive throughs and allows me= rchants to leverage existing hardware (barcode readers).=C2=A0

Other technologies like NFC may obviate the nee= d for this extension, however, those technologies remain somewhat uncommon = and may not be suitable for smaller wearables hitting the market.

message BillRequest {
=C2=A0required uint64 time =3D 1;
=C2=A0optional uint64 expires = =3D 2;
=C2=A0required string bill_reque= st_uri =3D 3;
}=C2= =A0


time -=C2=A0Unix ti= mestamp (seconds since 1-Jan-1970 UTC) when the BillRequest was created.
expires=C2=A0- Unix timestamp (UTC) after which= the BillRequest should be considered invalid (wallets may only be monitori= ng 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 wa= llet. 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 Re= quest flow. This will avoid confusion with existing QR code usage in wallet= apps.

--------
Paul G.
--001a11c1ecbe5e25cd04fc9a3152--