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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <g.rowe.froot@gmail.com>) id 1RrwIr-0001IJ-Ry
for bitcoin-development@lists.sourceforge.net;
Mon, 30 Jan 2012 18:50:09 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.175 as permitted sender)
client-ip=209.85.160.175; envelope-from=g.rowe.froot@gmail.com;
helo=mail-gy0-f175.google.com;
Received: from mail-gy0-f175.google.com ([209.85.160.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RrwIq-0007Sy-TW
for bitcoin-development@lists.sourceforge.net;
Mon, 30 Jan 2012 18:50:09 +0000
Received: by ghrr13 with SMTP id r13so395857ghr.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 30 Jan 2012 10:50:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.236.115.231 with SMTP id e67mr27893310yhh.16.1327949403511;
Mon, 30 Jan 2012 10:50:03 -0800 (PST)
Sender: g.rowe.froot@gmail.com
Received: by 10.236.195.99 with HTTP; Mon, 30 Jan 2012 10:50:03 -0800 (PST)
Date: Mon, 30 Jan 2012 18:50:03 +0000
X-Google-Sender-Auth: mVInyQgOOza0HSIuTcHaFx4NhFw
Message-ID: <CAKm8k+1VFYSt7115KKGy5C7orFoU-N=8vfkQ_sc8onfQq96_Ww@mail.gmail.com>
From: Gary Rowe <g.rowe@froot.co.uk>
To: Bitcoin Development List <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=20cf303b434f79dccd04b7c35040
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
(g.rowe.froot[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: 1RrwIq-0007Sy-TW
Subject: [Bitcoin-development] BIP 21 (modification BIP 20)
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, 30 Jan 2012 18:50:09 -0000
--20cf303b434f79dccd04b7c35040
Content-Type: text/plain; charset=UTF-8
Hi all,
Speaking on behalf of the MultiBit team (Jim's currently on holiday), we
will not be supporting Tonal Bitcoins anytime soon. Therefore we back the
BIP 21 proposal.
At present MultiBit does not support the "message" or "send" fields but we
would be happy to add this functionality as required.
Regarding the idea of a signed URI, it is appealing, however, it may not
work. If I understand it correctly, the main idea appears to be to protect
a URI from malicious replacement (at MultiBit we were concerned that a
Bitcoin "swatch" would be subjected to the same attack vector and we came
up with the term "swatch swabbing"). If a Bitcoin URI is served up from a
trusted source (e.g. a merchant site over HTTPS) then there is no need for
signing. It should be assumed that the merchant will offer a clean room
payment area so that no untrusted JavaScript will creep into the final page
and wreak havoc.
It would seem that in any situation where the attacker has complete control
over the content of the URI they will be able to successfully swab it to
match their own fraudulent address. Imagine attempting to protect a QR code
posted against a pole attempting to get BTC donations for a charity. How
long before that was replaced by a different version operated by the
thieves with good signatures all round?
Of course, I may have misunderstood so I would welcome further discussion.
One field that the MultiBit team would like to add to the BIP 21 proposal
is "expires" which would contain an ISO8601 formatted date/time in UTC
(e.g. "2000-01-01T23:59:59Z"). This would allow merchants to issue Bitcoin
URIs that would expose them to a currency/inventory risk for a defined
period of time.
Kind regards,
Gary Rowe
PS First post to this list
--20cf303b434f79dccd04b7c35040
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi all,<br><br>Speaking on behalf of the MultiBit team (Jim's currently=
on holiday), we will not be supporting Tonal Bitcoins anytime soon. Theref=
ore we back the BIP 21 proposal.<br><br>At present MultiBit does not suppor=
t the "message" or "send" fields but we would be happy =
to add this functionality as required. <br>
<br>Regarding the idea of a signed URI, it is appealing, however, it may no=
t work. If I understand it correctly, the main idea appears to be to protec=
t a URI from malicious replacement (at MultiBit we were concerned that a Bi=
tcoin "swatch" would be subjected to the same attack vector and w=
e came up with the term "swatch swabbing"). If a Bitcoin URI is s=
erved up from a trusted source (e.g. a merchant site over HTTPS) then there=
is no need for signing. It should be assumed that the merchant will offer =
a clean room payment area so that no untrusted JavaScript will creep into t=
he final page and wreak havoc. <br>
<br>It would seem that in any situation where the attacker has complete con=
trol over the content of the URI they will be able to successfully swab it =
to match their own fraudulent address. Imagine attempting to protect a QR c=
ode posted against a pole attempting to get BTC donations for a charity. Ho=
w long before that was replaced by a different version operated by the thie=
ves with good signatures all round?<br>
<br>Of course, I may have misunderstood so I would welcome further discussi=
on.<br><br>One field that the MultiBit team would like to add to the BIP 21=
proposal is "expires" which would contain an ISO8601 formatted d=
ate/time in UTC (e.g. "2000-01-01T23:59:59Z"). This would allow m=
erchants to issue Bitcoin URIs that would expose them to a currency/invento=
ry risk for a defined period of time.<br>
<br>Kind regards,<br><br>Gary Rowe<br><br><br>PS First post to this list<br=
><br><br>
--20cf303b434f79dccd04b7c35040--
|
