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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WQaKd-00031p-Fd
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 10:36:15 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.52 as permitted sender)
client-ip=209.85.219.52; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f52.google.com;
Received: from mail-oa0-f52.google.com ([209.85.219.52])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WQaKc-0003F8-Iu
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Mar 2014 10:36:15 +0000
Received: by mail-oa0-f52.google.com with SMTP id l6so650906oag.25
for <bitcoin-development@lists.sourceforge.net>;
Thu, 20 Mar 2014 03:36:09 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.37.199 with SMTP id a7mr37377496oek.41.1395311769271;
Thu, 20 Mar 2014 03:36:09 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Thu, 20 Mar 2014 03:36:09 -0700 (PDT)
In-Reply-To: <lge7nk$3mf$2@ger.gmane.org>
References: <lc5hmg$1jh$1@ger.gmane.org> <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>
Date: Thu, 20 Mar 2014 11:36:09 +0100
X-Google-Sender-Auth: 7BLTD2UedsUGGeaw3TZ614-ByGY
Message-ID: <CANEZrP0J849oDvMWjf8LWi0xj44Q8DaUwDip5_smVBMNgeQ3mw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=089e011769d15bc4c104f50756e9
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: 1WQaKc-0003F8-Iu
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: Thu, 20 Mar 2014 10:36:15 -0000
--089e011769d15bc4c104f50756e9
Content-Type: text/plain; charset=UTF-8
Encoding entire payment requests into qrcodes is definitely not the way to
go. They can already be large when signed and we're just at the start of
adding features.
Finishing off and standardising the bluetooth support is the way to go
(r=bt:mac). Andreas' app already has some support for this I believe, so
Alex you could prototype with that, but we need to:
1) Add an encryption/auth layer on top, because it runs over RFCOMM
sockets. The authentication would require proof of owning the Bitcoin key
that's in the address part of the URI (which is needed for backwards compat
anyway).
2) Write a BIP for it and make sure it's interoperable
For the auth layer we could either use SSL and then just ignore the server
certificate and require signing of the session public key with the Bitcoin
key, which should be easy to code up but is rather heavy on the air, or
roll a custom lightweight thing where we just do a basic ECDH, with the
servers key being the same as the address key. But rolling such protocols
is subtle and I guess it'd need to be reviewed by people familiar with such
things.
This feels like a good opportunity to grow the community - perhaps we can
find a volunteer in the forums who enjoys crypto.
--089e011769d15bc4c104f50756e9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">Encoding entire payment request=
s into qrcodes is definitely not the way to go. They can already be large w=
hen signed and we're just at the start of adding features.</div><div cl=
ass=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">Finishing off and standardising the bl=
uetooth support is the way to go (r=3Dbt:mac). Andreas' app already has=
some support for this I believe, so Alex you could prototype with that, bu=
t we need to:</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">1) Add an e=
ncryption/auth layer on top, because it runs over RFCOMM sockets. The authe=
ntication would require proof of owning the Bitcoin key that's in the a=
ddress part of the URI (which is needed for backwards compat anyway).</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">2) Write a =
BIP for it and make sure it's interoperable</div><div class=3D"gmail_ex=
tra"><br></div><div class=3D"gmail_extra">For the auth layer we could eithe=
r use SSL and then just ignore the server certificate and require signing o=
f the session public key with the Bitcoin key, which should be easy to code=
up but is rather heavy on the air, or roll a custom lightweight thing wher=
e we just do a basic ECDH, with the servers key being the same as the addre=
ss key. But rolling such protocols is subtle and I guess it'd need to b=
e reviewed by people familiar with such things.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">This feels =
like a good opportunity to grow the community - perhaps we can find a volun=
teer in the forums who enjoys crypto.</div></div>
--089e011769d15bc4c104f50756e9--
|
