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; 
MIME-Version: 1.0
Sender: g.rowe.froot@gmail.com
Date: Mon, 30 Jan 2012 18:50:03 +0000
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
Subject: [Bitcoin-development]  BIP 21 (modification BIP 20)
Precedence: list

--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&#39;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 &quot;message&quot; or &quot;send&quot; 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 &quot;swatch&quot; would be subjected to the same attack vector and w=
e came up with the term &quot;swatch swabbing&quot;). 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 &quot;expires&quot; which would contain an ISO8601 formatted d=
ate/time in UTC (e.g. &quot;2000-01-01T23:59:59Z&quot;). 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--