Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

[Andy Parkins <andyparkins@gmail.com>]

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