Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmx.de
	designates 213.165.64.22 as permitted sender)
	client-ip=213.165.64.22; envelope-from=thomasV1@gmx.de;
	helo=mailout-de.gmx.net; 
Content-Type: text/plain; charset="utf-8"
Date: Tue, 31 Jan 2012 07:54:44 +0100
From: thomasV1@gmx.de
In-Reply-To: <CAKm8k+1VFYSt7115KKGy5C7orFoU-N=8vfkQ_sc8onfQq96_Ww@mail.gmail.com>
Message-ID: <20120131065444.29110@gmx.net>
MIME-Version: 1.0
References: <CAKm8k+1VFYSt7115KKGy5C7orFoU-N=8vfkQ_sc8onfQq96_Ww@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Transfer-Encoding: 8bit
Subject: Re: [Bitcoin-development] BIP 21 (modification BIP 20)
Precedence: list


> 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 

No. The main idea is to protect the consumer against a malicious seller pretending that he has not been paid. Please read the forum.

> 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.

The bitcoin address that is used to sign URIs will establish the online reputation of the merchant. If a merchant has received a payment and pretends not to have received it, the signed URI will prove him wrong. 

In principle it would be possible to use HTTPS signatures for that purpose, but this is not really the way HTTPS is supposed to work, and it has disadvantages:
- HTTPS is not always available; there are other communication channels.
- A website, even a single page, may contain URIs posted by various merchants; we need to distinguish the identity of the merchant from the identity of the website.
- with signed URIs, a Bitcoin client can easily keep track of the signatures for all the payments it made. if we used the HTTPS signature of the webpage as receipts, then users would need to save them manually. To my knowledge, nobody does that.


> 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.

yes, that too. see my proposal here: https://bitcointalk.org/index.php?topic=60828.0;topicseen

-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de