From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WQU8Y-0000IJ-3J for bitcoin-development@lists.sourceforge.net; Thu, 20 Mar 2014 03:59:22 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.160.169 as permitted sender) client-ip=209.85.160.169; envelope-from=jgarzik@bitpay.com; helo=mail-yk0-f169.google.com; Received: from mail-yk0-f169.google.com ([209.85.160.169]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WQU8W-0006VG-To for bitcoin-development@lists.sourceforge.net; Thu, 20 Mar 2014 03:59:22 +0000 Received: by mail-yk0-f169.google.com with SMTP id 142so840694ykq.0 for ; Wed, 19 Mar 2014 20:59:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=J/lBMkqz0pyWsCWvltamZu6X26BiiGCt4m38r/f1jVY=; b=eBiPfBztFh5SaUkKFlmIZ4dV0mVXmV8yxMpOVR1k0gcS0PlZWK7YYhHwCtpcSuwA4E E0vPATnHipAAL9IjXHBC04tyFASD4m8l4oPok9VFrPyTb7X2vFW+RM1KdBUSzUuar5Hk S4Y47zoiYMeM13NmoiSitxAJEptczoIDmGU2BE+qARt6tOxJlghT65AaJ/HFyCO0Imud I7kv+lz240AISAXuZyPlV3qFPDL44iyLPKl23gfnZhcfgk2lWJtjtHLNoKSPU6GA93gD OTDCFIkBT4Sifnc0kfKI/QMa0QsFiEfgToRiahkxPen2+yn4l4NQF/XQT5vQ33P7D893 iIoA== X-Gm-Message-State: ALoCoQkgaSnr1CwaeG2FyFMw+rEhgPaWnjXaTXW1dno0kazhfF7+VqbDUtG9rulI8XZs0cmC8ltG X-Received: by 10.236.124.104 with SMTP id w68mr32090979yhh.2.1395286316165; Wed, 19 Mar 2014 20:31:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.170.162.214 with HTTP; Wed, 19 Mar 2014 20:31:36 -0700 (PDT) In-Reply-To: References: From: Jeff Garzik Date: Wed, 19 Mar 2014 23:31:36 -0400 Message-ID: To: Alex Kotenko Content-Type: multipart/alternative; boundary=20cf300fac333c3fa504f501697e 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 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: 1WQU8W-0006VG-To Cc: Bitcoin Dev , 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 03:59:22 -0000 --20cf300fac333c3fa504f501697e Content-Type: text/plain; charset=ISO-8859-1 Take a look at BIP 73: https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki On Wed, Mar 19, 2014 at 10:22 PM, Alex Kotenko wrote: > 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 >> >> > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --20cf300fac333c3fa504f501697e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 19, 2014 at 10:22 PM, Alex Koten= ko <alexykot@gmail.com> wrote:
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.=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.=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.=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,=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



-----------------------------------------------------------------------= -------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases = and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf= .net/sfu/13534_NeoTech
_____________________________________________= __
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment




--
Jeff Garzik
Bitc= oin core developer and open source evangelist
BitPay, Inc. =A0 =A0 =A0https://bitpay.com/
--20cf300fac333c3fa504f501697e--