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-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WLsWn-0003FQ-C5
for bitcoin-development@lists.sourceforge.net;
Fri, 07 Mar 2014 11:01:21 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.176 as permitted sender)
client-ip=209.85.214.176; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f176.google.com;
Received: from mail-ob0-f176.google.com ([209.85.214.176])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WLsWm-0001Zz-GH
for bitcoin-development@lists.sourceforge.net;
Fri, 07 Mar 2014 11:01:21 +0000
Received: by mail-ob0-f176.google.com with SMTP id wp18so3929428obc.21
for <bitcoin-development@lists.sourceforge.net>;
Fri, 07 Mar 2014 03:01:15 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.54.138 with SMTP id j10mr6569683oep.51.1394190075204;
Fri, 07 Mar 2014 03:01:15 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Fri, 7 Mar 2014 03:01:15 -0800 (PST)
In-Reply-To: <lfc6mi$qth$1@ger.gmane.org>
References: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
<lf9m0e$q7t$1@ger.gmane.org>
<CAJoe_wFeyFvxbd2nSD2yztJ_qjRQ=AKZj8pBOXs-ChKKbaZeuQ@mail.gmail.com>
<lfc6mi$qth$1@ger.gmane.org>
Date: Fri, 7 Mar 2014 12:01:15 +0100
X-Google-Sender-Auth: sb5otwASd_kgYS8qBACar6zE22s
Message-ID: <CANEZrP3sQWqjpt2vMS8paQvWM=Fn=jPkEOk9g_ZukM3Ouhkw=A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=089e0112cd322e9b9a04f4022cfe
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: 1WLsWm-0001Zz-GH
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Instant / contactless 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: Fri, 07 Mar 2014 11:01:21 -0000
--089e0112cd322e9b9a04f4022cfe
Content-Type: text/plain; charset=UTF-8
>
> Interesting side note: They recommend messages transmitted via NFC to
> not exceed 1 KB in order for a snappy experience. This (again) questions
> usage of bulky X.509 certificates in our payment request messages.
> Bitcoin Wallet currently does not sign payment requests, so I could not
> try how it would feel.
I think you could just put a signed PaymentRequest into an NFC tag and try
reading it from that. It's the same underlying radio tech so the transfer
speeds should be similar, I'd think.
Common X.509 certs are bigger than they need to be for sure, but a lot of
the bulk comes from the use of RSA rather than ECC. An RSA signature alone
can be 256 bytes! There's nothing that states you have to use RSA for
certificates and ECC certs are out there (Google uses one), but I think
they are harder to get hold of. I guess over time SSL will migrate to
mostly ECC (secp256r1) based certs.
--089e0112cd322e9b9a04f4022cfe
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 class=3D"HOEnZb"><div class=3D"h5"><span st=
yle=3D"color:rgb(34,34,34)">Interesting side note: They recommend messages =
transmitted via NFC to</span><br>
</div></div>
not exceed 1 KB in order for a snappy experience. This (again) questions<br=
>
usage of bulky X.509 certificates in our payment request messages.<br>
Bitcoin Wallet currently does not sign payment requests, so I could not<br>
try how it would feel.</blockquote><div><br></div><div>I think you could ju=
st put a signed PaymentRequest into an NFC tag and try reading it from that=
. It's the same underlying radio tech so the transfer speeds should be =
similar, I'd think.</div>
<div><br></div><div>Common X.509 certs are bigger than they need to be for =
sure, but a lot of the bulk comes from the use of RSA rather than ECC. An R=
SA signature alone can be 256 bytes! There's nothing that states you ha=
ve to use RSA for certificates and ECC certs are out there (Google uses one=
), but I think they are harder to get hold of. I guess over time SSL will m=
igrate to mostly ECC (secp256r1) based certs.</div>
</div></div></div>
--089e0112cd322e9b9a04f4022cfe--
|
