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 andypark...@gmail.com ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
