1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <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
X-Google-Sender-Auth: qYpeJlLoJMutX1p-8vdD-lHxizQ
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
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
<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:'courier new',monospace;color:rgb(0,51,0)">
=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</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'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'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 :/</di=
v>
</div></div></div>
--089e01161982d2bb2904fd1d6c8d--
|
