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 ) id 1Td8LZ-0007xz-HV for bitcoin-development@lists.sourceforge.net; Mon, 26 Nov 2012 23:44:17 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Td8LY-0006mq-RF for bitcoin-development@lists.sourceforge.net; Mon, 26 Nov 2012 23:44:17 +0000 Received: from ishibashi.localnet (unknown [173.170.188.216]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id BD57A27A296F; Mon, 26 Nov 2012 23:44:10 +0000 (UTC) From: "Luke-Jr" To: Gregory Maxwell Date: Mon, 26 Nov 2012 23:44:00 +0000 User-Agent: KMail/1.13.7 (Linux/3.5.4-gentoo; KDE/4.8.5; x86_64; ; ) References: <201211262319.37533.luke@dashjr.org> In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201211262344.03385.luke@dashjr.org> X-Spam-Score: -0.4 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Td8LY-0006mq-RF Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 23:44:17 -0000 On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote: > Obviously the state of the world with browsers is not that good... but > in our own UAs we can do better and get closer to that. This effectively centralizes Bitcoin (at least in the eyes of many) and even if each competing client had their own list, you'd be back to the original "problem" of not being sure your CA is on all lists. > Would you find it acceptable if something supported a static whitelist > plus a OS provided list minus a user configured blacklist and the > ability for sophisticated users to disable the whitelist? How is this whitelist any different from the list of CAs included by default with every OS?