diff options
| author | Gary Rowe <g.rowe@froot.co.uk> | 2012-01-30 18:50:03 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-01-30 18:50:09 +0000 |
| commit | 390a23275f9a39503dfaed7aad8853c26db6e971 (patch) | |
| tree | 01fdeb520a6275429e90b7cc86a8444abfd4cba1 | |
| parent | ad67c01e598d38e6ce9ff2a49bac3564385f1b28 (diff) | |
| download | pi-bitcoindev-390a23275f9a39503dfaed7aad8853c26db6e971.tar.gz pi-bitcoindev-390a23275f9a39503dfaed7aad8853c26db6e971.zip | |
[Bitcoin-development] BIP 21 (modification BIP 20)
| -rw-r--r-- | 07/60199f155a7a0af4bc0769106ad7ec33986a6b | 136 |
1 files changed, 136 insertions, 0 deletions
diff --git a/07/60199f155a7a0af4bc0769106ad7ec33986a6b b/07/60199f155a7a0af4bc0769106ad7ec33986a6b new file mode 100644 index 000000000..c19639377 --- /dev/null +++ b/07/60199f155a7a0af4bc0769106ad7ec33986a6b @@ -0,0 +1,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-- + + |