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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TdOw6-0006VF-Qe for bitcoin-development@lists.sourceforge.net; Tue, 27 Nov 2012 17:27:06 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.175 as permitted sender) client-ip=74.125.82.175; envelope-from=andyparkins@gmail.com; helo=mail-we0-f175.google.com; Received: from mail-we0-f175.google.com ([74.125.82.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TdOw5-0008BC-VO for bitcoin-development@lists.sourceforge.net; Tue, 27 Nov 2012 17:27:06 +0000 Received: by mail-we0-f175.google.com with SMTP id z53so3491533wey.34 for ; Tue, 27 Nov 2012 09:26:59 -0800 (PST) Received: by 10.180.7.199 with SMTP id l7mr24786101wia.15.1354037219892; Tue, 27 Nov 2012 09:26:59 -0800 (PST) Received: from momentum.localnet ([91.84.15.31]) by mx.google.com with ESMTPS id gz3sm3389414wib.2.2012.11.27.09.26.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 09:26:58 -0800 (PST) From: Andy Parkins To: Mike Hearn Date: Tue, 27 Nov 2012 17:26:56 +0000 User-Agent: KMail/1.13.7 (Linux/3.2.0-3-686-pae; KDE/4.8.4; i686; ; ) References: <201211271703.39282.andyparkins@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201211271726.56370.andyparkins@gmail.com> X-Spam-Score: -1.6 (-) 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 (andyparkins[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1TdOw5-0008BC-VO 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: Tue, 27 Nov 2012 17:27:07 -0000 On Tuesday 27 November 2012 17:14:19 Mike Hearn wrote: > That's pretty much what we have today - in future other schemes can be > proposed as extensions. Protocol buffers are easily extended, they > ignore unknown fields. Then you'd wait and see what the invoice > request looked like and produce an invoice with the right security > bits. That's good; I've not done anything with protocol buffers, so wasn't aware it was that simple. > > In particular two additional identification types: > > - GnuPG (obviously) > > It's not obvious to me, incidentally. The web of trust has been > dead-on-arrival since it was first proposed, and for good reasons. > SSL/X.509, for better or worse, has significant usage. Sorry, I meant "obviously" in the sense that "obviously that's the other one that everyone will want". The web-of-trust as a universal identity mechanism is, I agree, not useful. However, as a localised, smaller-scale identity verification system it's used by every GnuPG user. You become your own certificate authority. For example, I've set up my whole family with GnuPG; I've set them up to trust me to authenticate (and I doubt any of them has ever added anyone else). Then I take on the responsibility of signing all my family/friends keys and they don't need to worry about it. There's no reason that a small group of companies wouldn't do exactly the same sort of thing. > Your case of a small business is a perfect example of people who won't > be using GPG. If they don't want to buy an SSL cert, they can just as Bear in mind, I was using that example as an example of a hash protected in a GPG envelope, not a GPG-signed invoice. People who've already got their GPG system in place will appreciate being able to leverage it. > well put a reference number in the memo field or a "Hey Bob, here is > the bill we discussed". The payer does not get the multi-factor auth How can they put a hash of an invoice inside the invoice? In my "hash mode" invoices, it would be a random number (or possibly specifying the hash algorithm) then the SignedInvoice would simply be the original invoice + hash. That hash would then be reported via some secure channel outside of bitcoin's domain. > protection so if their computer has a virus, they may be hosed. But > that's good incentive for sellers to get verified. Some CA authorities > do it for free these days. I don't understand what the relevance of multi-factor is to invoices? The payment is performed via normal bitcoin mechanisms isn't it -- multi-factor or not? This invoice system has one primary job: to ensure that the target of the payment is who the payer thinks it is -- that's not affected by multi- factor methods of protecting my wallet. Andy -- Dr Andy Parkins andyparkins@gmail.com