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
135
136
137
138
139
140
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mw@osfda.org>) id 1X1vnU-0002ID-NB
for bitcoin-development@lists.sourceforge.net;
Tue, 01 Jul 2014 11:00:24 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of osfda.org
designates 217.23.13.216 as permitted sender)
client-ip=217.23.13.216; envelope-from=mw@osfda.org;
helo=smtp.osfda.org;
Received: from smtp.osfda.org ([217.23.13.216])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1X1vnS-0006jy-Px for bitcoin-development@lists.sourceforge.net;
Tue, 01 Jul 2014 11:00:24 +0000
Received: from [192.168.1.117]
(207-38-214-214.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com [207.38.214.214])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp.osfda.org (Postfix) with ESMTPSA id 79CB313A017F;
Tue, 1 Jul 2014 12:42:34 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Wozniak <mw@osfda.org>
In-Reply-To: <lou05t$2ra$1@ger.gmane.org>
Date: Tue, 1 Jul 2014 06:42:33 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4B82FD9-8078-48B2-9F91-8A3AB23AEAA7@osfda.org>
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>
<CANEZrP1HvKAg6d7tTcnY3BJr0_5LuCN1FGYQvQ1+RpL1B6cwHw@mail.gmail.com>
<lou05t$2ra$1@ger.gmane.org>
To: Andreas Schildbach <andreas@schildbach.de>
X-Mailer: Apple Mail (2.1878.2)
X-Spam-Score: -1.6 (-)
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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1X1vnS-0006jy-Px
Cc: 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 11:00:24 -0000
I think it makes more sense to not add a duplicate parameter. Current =
implementations will break if multiple r parameters are used (either =
reject the URI completely, or do something undefined). If a new =
parameter is used, then the current implementations will just ignore it =
if they don=E2=80=99t support it.
-
Michael Wozniak
On Jul 1, 2014, at 5:48 AM, Andreas Schildbach <andreas@schildbach.de> =
wrote:
> On 07/01/2014 10:18 AM, Mike Hearn wrote:
>> =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.=20
>=20
> I think the way to go here is using multiple r=3D parameters.
>=20
>> 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?
>=20
> Either that, or just use the other ones as a fallback. Currently,
> Bitcoin Wallet just falls back to BIP21 if fetching the PR via the r=3D
> URL fails.
>=20
>> 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 be, =
people
>> would point out the lack of link-layer encryption.
>=20
> Its "specced" in code and implemented by several parties. I think its
> clear that link-layer encryption has to be an add-on to the current
> unencrypted connection, just like HTTPS is on top of HTTP. Anyway,
> that's unrelated to the question of how to provide fallback URLs.
>=20
> One more thought: We have a similar problem with the BIP70 payment =
URL.
> It doesn't allow for fallbacks either. I brought this issue up in the
> discussion phase of BIP70, but it was dismissed I think because of
> "let's not get too complex for the first version". The fallback here =
is
> to send the transaction via the P2P network.
>=20
> (I think BIP70 via P2P radio will get used more often in future. I =
plan
> to look into Bluetooth 4 LE as soon as I have devices and wanted to =
try
> WIFI Direct again also. I hope we can skip BIP72 for both of those, =
but
> lets see.)
>=20
>=20
>=20
> =
--------------------------------------------------------------------------=
----
> Open source business process management suite built on Java and =
Eclipse
> Turn processes into business applications with Bonita BPM Community =
Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
