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
141
142
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1YPhMO-00079c-Uw for bitcoin-development@lists.sourceforge.net;
Mon, 23 Feb 2015 00:58:56 +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 1YPhMN-0007gV-II
for bitcoin-development@lists.sourceforge.net;
Mon, 23 Feb 2015 00:58:56 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1YPhMG-0007K4-Jx for bitcoin-development@lists.sourceforge.net;
Mon, 23 Feb 2015 01:58:48 +0100
Received: from f052012129.adsl.alicedsl.de ([78.52.12.129])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Mon, 23 Feb 2015 01:58:48 +0100
Received: from andreas by f052012129.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Mon, 23 Feb 2015 01:58:48 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Mon, 23 Feb 2015 01:58:42 +0100
Message-ID: <mcdu03$fva$1@ger.gmane.org>
References: <20150222190839.GA18527@odo.localdomain>
<54EA5A1C.2020701@AndySchroder.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: f052012129.adsl.alicedsl.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.4.0
In-Reply-To: <54EA5A1C.2020701@AndySchroder.com>
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 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: 1YPhMN-0007gV-II
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70,
NFC and offline payments - implementer feedback
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: Mon, 23 Feb 2015 00:58:57 -0000
On 02/22/2015 11:37 PM, Andy Schroder wrote:
> Andreas and I had a number of private discussions regarding the
> payment_url parameter. I had suggested a "additional_payment_urls"
> repeated parameter, but he didn't seem to like that idea and I
> personally am indifferent, so that is why we decided to just change
> payment_url to a repeated field. The spec is simpler without the
> "additional_payment_urls", but the wallets have to be a little bit
> smarter finding the right url they want to use in the list. It's maybe
> not a bad idea for the wallet to try all payment_url mechanisms in
> parallel. Should we add this as a recommendation to wallets in TBIP75?
I think it will cause too much chaos. My recommendation for the
payment_url field is prefer the same mechanism that was used for
fetching the payment request. Only if the recommendation fails use the
alternatives in order (or in reverse order, I'm not sure at the moment).
> Regarding the NFC data formats. I would like to clarify that the wallets
> are having those events dispatched by the android OS. The "URI" and
> "mime type" events are sent to the application in the same way as from
> other sources such as a web browser, e-mail, stand alone QR code scanner
> app, etc.. So, I don't think the wallet actually knows it is receiving
> the event from NFC.
I think it can know. The method for catching these intents is very
similar and you can reuse almost all code, but in fact you need to add
an additional line to your AndroidManifest.xml.
> That is one reason why so many existing wallets
> happen to support BIP21 payment request via NFC.
Many? Bitcoin Wallet and its forks were the only ones for about a year.
Only recently Mycelium caught up and the others still do not care I guess.
> I'm a little weary sending the "mime
> type" based format over NFC because of backwards compatibility and
> because of the long certificate chain that needs to be transferred. You
> want that tap to be as robust and fast as possible. A bluetooth
> connection can have a retry without any user interaction.
I agree whatever we do must be robust. However I see no reason why NFC
can't be robust, see my previous post.
> I don't really like the Airbitz proposal. Figuring out if your selecting
> is the right one is a real nuisance. The idea is neat in a few
> applications, but I just don't think it is going to work for people as
> the most efficient and trouble free option day to day. I realize they
> are probably doing it to work with Apple's limited functionality phones
> (and BLE is a new buzz word). However, I don't think we should base
> bitcoin around what Apple wants us to do. They've already had their war
> on bitcoin. They are going to do whatever they can to protect their NFC
> based payment system. We need to make their platform the the less
> desirable one if they are going to play the game that way. If that means
> an Airbitz like proposal is implemented as a fallback, maybe that is
> fine and POS systems need to support both, but I just don't think we
> should limit what we can do because of Apple's products capabilities.
Ack on Airbitz, and ack on our relationship to Apple (-:
> There is also the "ack" memo that I mentioned in reference [2]. I think
> we can improve upon this really. Can we make a new status field or
> different bluetooth message header? I know Andreas didn't want to change
> it because that is how his app already works, but I don't think the way
> it is is ideal.
I'm not against improving this point, but I felt the BT enhancements and
the r,r1,r2 proposals are already getting complex enough. I would like
to simplify the proposal by moving unrelated things to somewhere else.
|
