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; 
From: Andy Parkins <andyparkins@gmail.com>
To: Mike Hearn <mike@plan99.net>
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: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
	<201211271703.39282.andyparkins@gmail.com>
	<CANEZrP0NZykzrvC1=YZv4czbu+EPaR3qpjQ2WZDsA8DhroR2_g@mail.gmail.com>
In-Reply-To: <CANEZrP0NZykzrvC1=YZv4czbu+EPaR3qpjQ2WZDsA8DhroR2_g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201211271726.56370.andyparkins@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
	Invoices/Payments/Receipts
Precedence: list

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