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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <hozer@grid.coop>) id 1WKAy3-0000mG-Lh
for bitcoin-development@lists.sourceforge.net;
Sun, 02 Mar 2014 18:18:27 +0000
X-ACL-Warn:
Received: from nl.grid.coop ([50.7.166.116])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WKAy1-0006bC-Ih for bitcoin-development@lists.sourceforge.net;
Sun, 02 Mar 2014 18:18:27 +0000
Received: from localhost (localhost [127.0.0.1]) (uid 1000)
by nl.grid.coop with local; Sun, 02 Mar 2014 12:18:18 -0600
id 000000000006A341.00000000531375EA.00003AF7
Date: Sun, 2 Mar 2014 12:18:18 -0600
From: Troy Benjegerdes <hozer@hozed.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20140302181818.GR3180@nl.grid.coop>
References: <op.xb05iptvyldrnw@laptop-air>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <op.xb05iptvyldrnw@laptop-air>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WKAy1-0006bC-Ih
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Positive and negative feedback on
certificate validation errors
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: Sun, 02 Mar 2014 18:18:27 -0000
On Fri, Feb 28, 2014 at 10:26:39PM -0800, Jeremy Spilman wrote:
> We currently have subtle positive feedback of a signed payment request in
> the form of the green background. Unsigned requests simply show up without
> the green background, as well as requests which provide a certificate but
> have a missing or invalid signature.
Are we talking a third-party 'root certificate'?
I don't quite see why a cryptographic currency that has the most widely
deployed ECDSA public/private key infrastructure ever needs to use external
certificates. That seems like a significant reduction in security to pretend
that a 'signed' certificate is any good when it's pretty easy to buy a
compromised cert, or just hack the server its on.
If it's 'signed' by the ECDSA private key that you are sending the payment
to, by all means, make it bright green.
I mean if you want to make it expensive for small businesses to take secure
payments, why don't you add a native 'signing fee' extension and have a
(more) transparent market for the price of perceived security, or at least
a compile time option so i can turn this nonsense off for my customers.
--
----------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer@hozed.org
7 elements earth::water::air::fire::mind::spirit::soul grid.coop
Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
|
