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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CALDj+BYkOyNuEiiuTgjd7L-ZeHN4Mb4034W+OeCFob1RwJn=Vg@mail.gmail.com>
References: <leuunm$tjk$1@ger.gmane.org>
	<CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com>
	<CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com>
	<CAJHLa0N4J_Z907+D0ENSNKfNAW2N=7Jf4JzSCO=SU558GtGTzA@mail.gmail.com>
	<lge7nk$3mf$2@ger.gmane.org>
	<CANEZrP0J849oDvMWjf8LWi0xj44Q8DaUwDip5_smVBMNgeQ3mw@mail.gmail.com>
	<CALDj+BZJ0rSKuDHdbL7ANN0Vtaa3-KGYgusqMDzzB-CUxjMz7g@mail.gmail.com>
	<CANEZrP3szn=oQS+ZuqSzjUoSAjtkyPxPWJFaU1vDW43dRNVeNQ@mail.gmail.com>
	<20140320215208.GC88006@giles.gnomon.org.uk>
	<CANEZrP3kHRJ6U-O_Jgei4U6s9GyQGvB_p5ChtcHJEkYR0wWPvQ@mail.gmail.com>
	<20140326224826.GE62995@giles.gnomon.org.uk>
	<CANEZrP2HtJsOf5zOsPz32U=Jot7U9k80yEu=hj5uMPkRC+WGsQ@mail.gmail.com>
	<lgvnc2$eu4$1@ger.gmane.org>
	<CANEZrP1==hL1mW6SWV0qXUMVVx7U_HUXtorpb7qVK2R4mOfzbg@mail.gmail.com>
	<A1269E16-63BC-44D5-B460-D793D45587AD@riseup.net>
	<CALDj+BYkOyNuEiiuTgjd7L-ZeHN4Mb4034W+OeCFob1RwJn=Vg@mail.gmail.com>
Date: Tue, 1 Jul 2014 10:18:48 +0200
Message-ID: <CANEZrP1HvKAg6d7tTcnY3BJr0_5LuCN1FGYQvQ1+RpL1B6cwHw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Alex Kotenko <alexykot@gmail.com>
Content-Type: multipart/alternative; boundary=089e01161982d2bb2904fd1d6c8d
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Precedence: list

--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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
 style=3D"font-family:&#39;courier new&#39;,monospace;color:rgb(0,51,0)">
=E2=80=8BHowever it&#39;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&#39;=
t not support fetching over bluetooth or bluetooth connection fails for any=
 reason.=C2=A0</div>
</div></div></blockquote><div><br></div><div>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&#39;s the sending wallet pick wha=
tever radio layer works best in its current conditions?</div>
<div><br></div><div>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.</div><div><br>
</div><div>So this is a bit tricky, overall. Right now I&#39;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&#39;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 :/</di=
v>
</div></div></div>

--089e01161982d2bb2904fd1d6c8d--