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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <201211271703.39282.andyparkins@gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
	<201211271703.39282.andyparkins@gmail.com>
Date: Tue, 27 Nov 2012 18:14:19 +0100
Message-ID: <CANEZrP0NZykzrvC1=YZv4czbu+EPaR3qpjQ2WZDsA8DhroR2_g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
	Invoices/Payments/Receipts
Precedence: list

> Personally, I'd like to see fewer implicit ties to X509.  With X509 as one
> option.

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.

> 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.

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
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
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.