summaryrefslogtreecommitdiff
path: root/78/5429b905c8183b3e12eab297769d2286e98a0d
blob: 813f37fe8dc32d4cef7b009724e6e4900cb9793f (plain)
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
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 <thomasV1@gmx.de>) id 1Rs7cC-0001vh-UE
	for bitcoin-development@lists.sourceforge.net;
	Tue, 31 Jan 2012 06:54:52 +0000
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; 
Received: from mailout-de.gmx.net ([213.165.64.22])
	by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76)
	id 1Rs7cB-0002sw-L1 for bitcoin-development@lists.sourceforge.net;
	Tue, 31 Jan 2012 06:54:52 +0000
Received: (qmail 17880 invoked by uid 0); 31 Jan 2012 06:54:46 -0000
Received: from 86.73.30.161 by www002.gmx.net with HTTP;
	Tue, 31 Jan 2012 07:54:44 +0100 (CET)
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
X-Authenticated: #19670841
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX19H9QJgo0xHFWesKpuZkrHCeMgMhYIJgYwF3Ha+Sz
	2o3+DgLs6QpAF3ddpKBXiybiMtlj7BUJsSaA== 
Content-Transfer-Encoding: 8bit
X-GMX-UID: Y/VVbztqeSEqVFhER3UhJzZ+IGRvb0AV
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [213.165.64.22 listed in list.dnswl.org]
	-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
	(thomasv1[at]gmx.de)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
	digit (thomasv1[at]gmx.de)
X-Headers-End: 1Rs7cB-0002sw-L1
Subject: Re: [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: Tue, 31 Jan 2012 06:54:53 -0000


> 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