Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WQSdO-0000Ps-5m for bitcoin-development@lists.sourceforge.net; Thu, 20 Mar 2014 02:23:06 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.176 as permitted sender) client-ip=209.85.220.176; envelope-from=alexy.kot.all@gmail.com; helo=mail-vc0-f176.google.com; Received: from mail-vc0-f176.google.com ([209.85.220.176]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WQSdN-0008TC-1J for bitcoin-development@lists.sourceforge.net; Thu, 20 Mar 2014 02:23:06 +0000 Received: by mail-vc0-f176.google.com with SMTP id lc6so219011vcb.21 for ; Wed, 19 Mar 2014 19:22:59 -0700 (PDT) X-Received: by 10.52.65.165 with SMTP id y5mr945272vds.51.1395282179497; Wed, 19 Mar 2014 19:22:59 -0700 (PDT) MIME-Version: 1.0 Sender: alexy.kot.all@gmail.com Received: by 10.59.0.38 with HTTP; Wed, 19 Mar 2014 19:22:19 -0700 (PDT) In-Reply-To: References: From: Alex Kotenko Date: Thu, 20 Mar 2014 02:22:19 +0000 X-Google-Sender-Auth: gEheqTpSLqEf5ZJ04GdXvc8UzV8 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=20cf307f3256aba6a204f50072a6 X-Spam-Score: -0.3 (/) 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 (alexy.kot.all[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.3 HTML_FONT_FACE_BAD BODY: HTML font face is not a word -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1WQSdN-0008TC-1J Cc: Andreas Schildbach Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 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: Thu, 20 Mar 2014 02:23:06 -0000 --20cf307f3256aba6a204f50072a6 Content-Type: text/plain; charset=UTF-8 Hi Andreas I'm implementing support for BIP70 in my POS at the moment, and I've just realized that with options you're proposing usecase I'm looking for is not covered. Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I need to still be able to use it for backwards compatibility. But at the same time I want to be able to support BIP70. And also I want to avoid using external servers, the concept of my POS is that everything is happening between just payer's phone and payee's POS device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me. You're also offering an option to include Base43 encoded PR body right inside the Bitcoin URI, but in a way that is not backwards compatible with BIP21. In the end this all means that there is no way for me to at the same time keep backwards compatibility with all wallets not supporting NFC and BIP70 (all other wallets right now), and keep things inside POS without need for external servers. I understand your intention behind base43 encoding and noncompatible URI - you want to make most possible use of QR codes. But I wonder - did you compare this base43 to base64 encoded request in a binary QR code format? How much do we actually win in total bytes capacity at a price of noncompatibility and increased complexity? And also maybe we can extend BIP72 to include encoded payment request in the URL directly in a backwards compatible way? Best regards, Alex Kotenko 2014-03-02 11:50 GMT+00:00 Mike Hearn : > Thanks Andreas. > > For BIP standardisation, I think the VIEW intent seems like an obvious > one. Bluetooth support probably should come later if/when we put > encryption/auth on the RFCOMM link (probably SSL). > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --20cf307f3256aba6a204f50072a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andreas


I'm implementing support for BIP70 in my POS at the moment, and I'v= e just realized that with options you're proposing usecase I'm look= ing for is not covered.

Right now, before BIP70, I'm sending BIP21 URI vi= a NFC or QR code, and I need to still be able to use it for backwards compa= tibility. But at the same time I want to be able to support BIP70. And also= I want to avoid using external servers, the concept of my POS is that ever= ything is happening between just payer's phone and payee's POS devi= ce. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable f= or me.=C2=A0

You're also offering an option to inc= lude Base43 encoded PR body right inside the Bitcoin URI, but in a way that= is not backwards compatible with BIP21.=C2=A0

In the end this all means that there is n= o way for me to at the same time keep backwards compatibility with all wall= ets not supporting NFC and BIP70 (all other wallets right now), and keep th= ings inside POS without need for external servers.=C2=A0

I understand your intention behind base43= encoding and noncompatible URI - you want to make most possible use of QR = codes. But I wonder - did you compare this base43 to base64 encoded request= in a binary QR code format? How much do we actually win in total bytes cap= acity at a price of noncompatibility and increased complexity?

And also maybe we can extend BIP72 to inc= lude encoded payment request in the URL directly in a backwards compatible = way?


Best regards,=C2=A0
Alex Kotenko


2014-03-02 11:50 GMT+00:00 Mike Hearn <mi= ke@plan99.net>:
Thanks Andreas.

For BIP standardisati= on, I think the VIEW intent seems like an obvious one. Bluetooth support pr= obably should come later if/when we put encryption/auth on the RFCOMM link = (probably SSL).

-----------------------------------------------------------------------= -------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D126839071&iu=3D/4140/ostg.clktrk
__________________= _____________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--20cf307f3256aba6a204f50072a6--