From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Th0m5-0002I9-R8 for bitcoin-development@lists.sourceforge.net; Fri, 07 Dec 2012 16:27:42 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.47 as permitted sender) client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f47.google.com; Received: from mail-oa0-f47.google.com ([209.85.219.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Th0m0-0003g7-GQ for bitcoin-development@lists.sourceforge.net; Fri, 07 Dec 2012 16:27:41 +0000 Received: by mail-oa0-f47.google.com with SMTP id h1so615977oag.34 for ; Fri, 07 Dec 2012 08:27:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.171.141 with SMTP id au13mr3425727oec.124.1354897656359; Fri, 07 Dec 2012 08:27:36 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.128.139 with HTTP; Fri, 7 Dec 2012 08:27:36 -0800 (PST) In-Reply-To: References: <20121128233619.GA6368@giles.gnomon.org.uk> <20121129170713.GD6368@giles.gnomon.org.uk> <20121129185330.GE6368@giles.gnomon.org.uk> <50C03BDA.6010600@petersson.at> Date: Fri, 7 Dec 2012 17:27:36 +0100 X-Google-Sender-Auth: HQRWHP1SI2p10aIA9mYRlCGLjFc Message-ID: From: Mike Hearn To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1Th0m0-0003g7-GQ 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: Fri, 07 Dec 2012 16:27:42 -0000 > yeah... I had similar thoughts on what to do if some Outputs specify an > amount and others don't. I'm still waffling on whether or not I like > allowing repeated Outputs; a single Output would make the spec a fair bit > simpler Yes, but at the cost of privacy. Generators of payment requests always have the option of just adding a single output and being done with it. But in future they'll probably want to keep their income in unlinkable chunks of a size that's up to them, and multi-outputs are needed for this (the idea being, the users wallet tries to keep a close-as-possible match between the requested outputs and their own). OK, let's punt on tipping for now. > If a bitcoin client accepts unsigned payment requests (a couple of people > have asked if that would be possible so I think that is desired), then it > doesn't have the payer's identity-- all it has is the Outputs that will be > paid. I see. If I were to implement a wallet I'd just display nothing (except the size of the request). Showing an address doesn't really help the user in any way. > I still like the idea of only including the root CAs who have jumped through > the hoops needed to get the "allowed to issue EV certs" blessing. The hoops only actually apply for EV certs though, they aren't required to do that verification for DV certs. The main reason to use the browser root CAs is that merchants are guaranteed to be able to re-use their existing certs. Otherwise they might have to buy new ones, which would be annoying.