Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WzlIu-0007CQ-Pp for bitcoin-development@lists.sourceforge.net; Wed, 25 Jun 2014 11:23:53 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.170 as permitted sender) client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f170.google.com; Received: from mail-ob0-f170.google.com ([209.85.214.170]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WzlIt-0004C3-1x for bitcoin-development@lists.sourceforge.net; Wed, 25 Jun 2014 11:23:52 +0000 Received: by mail-ob0-f170.google.com with SMTP id uz6so1913346obc.29 for ; Wed, 25 Jun 2014 04:23:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.114.229 with SMTP id jj5mr7202252obb.53.1403695425538; Wed, 25 Jun 2014 04:23:45 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.35.234 with HTTP; Wed, 25 Jun 2014 04:23:45 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Jun 2014 13:23:45 +0200 X-Google-Sender-Auth: PdwEBpUxIPXkmCjqBoD7Mm3-bGk Message-ID: From: Mike Hearn To: Paul Goldstein Content-Type: multipart/alternative; boundary=001a11c2f64436541604fca74fef 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 (mh.in.england[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: 1WzlIt-0004C3-1x Cc: Bitcoin Dev Subject: Re: [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: Wed, 25 Jun 2014 11:23:53 -0000 --001a11c2f64436541604fca74fef Content-Type: text/plain; charset=UTF-8 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 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 > > --001a11c2f64436541604fca74fef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 w= ay to move it forward at this stage is to implement it in some existing wal= lets.

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 specificat= ion 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 &= lt;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 mobil= e 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 B= illRequest 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 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.

-----------------------------------------------------------------------= -------
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.ne= t/sfu/Bonitasoft
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a11c2f64436541604fca74fef--