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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1X1tHD-0002vJ-Uj for bitcoin-development@lists.sourceforge.net; Tue, 01 Jul 2014 08:18:55 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.181 as permitted sender) client-ip=209.85.214.181; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f181.google.com; Received: from mail-ob0-f181.google.com ([209.85.214.181]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1X1tHC-0002wl-2V for bitcoin-development@lists.sourceforge.net; Tue, 01 Jul 2014 08:18:55 +0000 Received: by mail-ob0-f181.google.com with SMTP id wp4so9849822obc.26 for ; Tue, 01 Jul 2014 01:18:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.115.67 with SMTP id jm3mr47697528oeb.8.1404202728469; Tue, 01 Jul 2014 01:18:48 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.35.234 with HTTP; Tue, 1 Jul 2014 01:18:48 -0700 (PDT) In-Reply-To: References: <20140320215208.GC88006@giles.gnomon.org.uk> <20140326224826.GE62995@giles.gnomon.org.uk> Date: Tue, 1 Jul 2014 10:18:48 +0200 X-Google-Sender-Auth: qYpeJlLoJMutX1p-8vdD-lHxizQ Message-ID: From: Mike Hearn To: Alex Kotenko Content-Type: multipart/alternative; boundary=089e01161982d2bb2904fd1d6c8d 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: 1X1tHC-0002wl-2V Cc: Bitcoin Dev 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: Tue, 01 Jul 2014 08:18:56 -0000 --089e01161982d2bb2904fd1d6c8d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > =E2=80=8BHowever it's not ideal at the moment. Basically the main problem= is that > in the BIP72 there is no way to provide a fallback alternative URI for > payment request fetch if client wallet supports BIP70 but doesn't not > support fetching over bluetooth or bluetooth connection fails for any > reason. > So the idea here is that the recipient wallet both uploads to the internet and exposes the payment request over Bluetooth simultaneously, then let's the sending wallet pick whatever radio layer works best in its current conditions? I think having multiple r=3D params is reasonable, but the Bluetooth suppor= t is not specced in any BIP anyway. And if it were to be, people would point out the lack of link-layer encryption. So this is a bit tricky, overall. Right now I'd say things are kinda half baked: not only is bluetooth not standardised nor encrypted (my fault, I prototyped this code during a hackathon), but Bitcoin Wallet doesn't properly implement BIP 72 either. To push this work forward I think we need to sit down and do some more spec and implementation work :/ --089e01161982d2bb2904fd1d6c8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BHowever it's not ideal at the moment. Basically the main probl= em is that in the BIP72 there is no way to provide a fallback alternative U= RI for payment request fetch if client wallet supports BIP70 but doesn'= t not support fetching over bluetooth or bluetooth connection fails for any= reason.=C2=A0

So the idea here is that the r= ecipient wallet both uploads to the internet and exposes the payment reques= t over Bluetooth simultaneously, then let's the sending wallet pick wha= tever radio layer works best in its current conditions?

I think having multiple r=3D params is reasonable, but = the Bluetooth support is not specced in any BIP anyway. And if it were to b= e, people would point out the lack of link-layer encryption.

So this is a bit tricky, overall. Right now I'd say things a= re kinda half baked: not only is bluetooth not standardised nor encrypted (= my fault, I prototyped this code during a hackathon), but Bitcoin Wallet do= esn't properly implement BIP 72 either. To push this work forward I thi= nk we need to sit down and do some more spec and implementation work :/
--089e01161982d2bb2904fd1d6c8d--