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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1X1ugV-0004H5-1s for bitcoin-development@lists.sourceforge.net;
Tue, 01 Jul 2014 09:49:07 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of m.gmane.org
designates 80.91.229.3 as permitted sender)
client-ip=80.91.229.3;
envelope-from=gcbd-bitcoin-development@m.gmane.org;
helo=plane.gmane.org;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1X1ugT-0004Wm-4y
for bitcoin-development@lists.sourceforge.net;
Tue, 01 Jul 2014 09:49:07 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1X1ugL-00050J-Ky for bitcoin-development@lists.sourceforge.net;
Tue, 01 Jul 2014 11:48:57 +0200
Received: from f052195207.adsl.alicedsl.de ([78.52.195.207])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Tue, 01 Jul 2014 11:48:57 +0200
Received: from andreas by f052195207.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Tue, 01 Jul 2014 11:48:57 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Tue, 01 Jul 2014 11:48:44 +0200
Message-ID: <lou05t$2ra$1@ger.gmane.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>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: f052195207.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.6.0
In-Reply-To: <CANEZrP1HvKAg6d7tTcnY3BJr0_5LuCN1FGYQvQ1+RpL1B6cwHw@mail.gmail.com>
X-Enigmail-Version: 1.5.2
X-Spam-Score: -0.4 (/)
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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [80.91.229.3 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
1.1 DKIM_ADSP_ALL No valid author signature,
domain signs all mail
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1X1ugT-0004Wm-4y
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 09:49:07 -0000
On 07/01/2014 10:18 AM, Mike Hearn wrote:
> However 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.
I think the way to go here is using multiple r= parameters.
> 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?
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=
URL fails.
> I think having multiple r= 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.
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.
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.
(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.)
|
