Topic: FAQ on the payment protocol - page 3. (Read 47138 times)

I was talking with Timo Hanke about this at the Amsterdam conference. X.509 PKI and Namecoin solve different problems, so I don't think the question makes much sense.

There's nothing inherently centralised about the PKI, it's just that for convenience we all tend to agree up front on a list of organisations that we think will do a reasonable job of verifying various kinds of identity (email addresses, business details etc).

But nothing stops you deciding you're going to rely on a totally different set instead. If you can convince other people to use one of the signers you trust, you could abandon the existing CA's entirely and switch to some new ones. You could have thousands or tens of thousands if you wanted. The current payment protocol doesn't let you sign with multiple cert chains so it'd be a bit awkward to do a smooth migration (you'd have to jump all at once), but that could be fixed in a future extension if someone was serious about establishing a different PKI.

Using Namecoin as a form of identity would be possible (with an extension to the payment protocol), but is problematic for a lot of different reasons.

Firstly, Namecoin is just a way to own a string. There's nothing meaningful about those strings because it's first come first serve. If someone turns up and claims they work for Mt Gox, and they give you a payment request that is signed by the owner of the namecoin string "mtgox.bit" then it's possible they really do work for Mark, or, they could be random stranger who just grabbed the name first. There's no way to tell, which renders the signature useless.

Secondly, even if you learn about the validity of this namecoin name out-of-band somehow (like MtGox announced they registered the name on their blog), it's tricky to make arbitrary pieces of text meaningful identities. This is going to sound a bit Matrix, but .... what is a string? A sequence of Unicode code points? A set of pixels on a screen? The sound it makes when pronounced? To a computer it's the first one. To a human reading about stuff on the web it's the second, and to a human who learned about your company from an excited conference attendee it's the third.

This matters because the mismatch can cause security holes. The DNS system and cert authorities have been battling this problem for years. The simplest hack is this: the following two domain names are NOT equal to a naively written computer program:

www.google.com is not www.gooɡle.com

Whether you can see this easily or not depends on your font. I can't see it here on my Ubuntu machine except for the fact that the autolinker stopped at the 4th G. But in the code sample below it's more obvious:


This is just one of many such confusion attacks that are possible. Part of the reason certificate authorities get audited and checked is to ensure they're watching out for things like this. As far as I know, Namecoin has no protections against this sort of thing and if it became popular then you'd see scammers descend on it extremely fast, just like they did for SSL.

In short, identity is a hard problem. It's not as simple as "centralised vs decentralised"  - the CA infrastructure has hundreds of players competing in a free market, and you can choose which ones you trust to do a good job. If you aren't happy with the existing set, make a new set, but just be aware that it's a way harder problem than keeping a database of strings to keys.

... since we are having an extended discussion on merits of different authentication approaches I'm going to bump this seemingly simple query

Think harder - that example is not external to the WoT.


A random person doesn't have too: verifying that Bob is the right Bob is much easier when I know Bob. That's after all the strength of the web-of-trust model: used well it's based on human relationships, which makes so many of the audits and other procedures less important, and greatly increases the difficulty and expense of attacking any given target. Obviously this has a cost because verification is also more manual, but that's just an engineering trade-off.

Of course, certificate authorities don't have magic abilities to verify IDs either: if a CA signs a cert saying "Peter Todd", how do you know it's the Peter Todd known in the Bitcoin world anyway? Web-of-trust on the other hand naturally makes that distinction.


That would be terrible; I mean, it certainly wouldn't be possible to somehow distribute that data in a peer-to-peer fashion...

Yes, for the journalist case you can establish trust in a key external to the WoT indeed.


All you need to do is convince yourself that Chrome/Firefox/etc will only add a CA if it passes audits, and you can do that by sampling their bug databases to find the original inclusion requests (I think, at least I've seen one or two of those in the past). Once you establish that root of trust and you look at what the audits involve, you can then go ahead and convince yourself all the CAs passed those audits.


Certainly not, you can revoke any CA you want at any time. You would then have to validate any certs signed by it out of band some how, no different to a WoT model. Most people don't do that because they prefer to outsource all this complexity.

I find it easier to reason about the trustworthyness of a CA actually, because of the auditing. A random person might or might not treat their private key well or have robust ID verification procedures in place.


Only for as long as that community isn't interesting. Otherwise, bye bye keyservers ...

Unfortunately this doesn't work due to downgrading attacks: where do you store the fact that the site is certified by 2 certificates, given that the vast majority only have one?

If you do have a place to store that information, that place itself can be compromised; if it can't be compromised then why not just store the digest of the certificate there? (certificate pinning) It could be usefully used as a way to have certificate pinning with a way to change later though. (and in general it's reasonable for certificates to internally have n-of-m private key schemes)

How about requesting the 2 or more certificates from different CAs? That makes a random hacker much more difficult to MITM attack

To prevent MITM attack from the government, we could require CAs from different countries. We could further divide countries into groups: US allies, Russian allies, tax havens, etc.

My point is that while mass keysigning parties and magic trust in the "strong set" are in fact quasi-religious, using WoT however isn't. Mike Perry's evaluation of WoT as a stand-alone system, and complaining that you can't authenticate it in its entirety completely, throws the baby out with the bathwater. My example of an Edward using the WoT to help him determine if journalist Glenn's key is valid based on evidence like many different PGP signed articles by him and other journalists who have signed Glenn's key makes great use of the WoT.


CA revocation is a good point, but if anything it shows even more clearly why the WoT is valuable: how do you authenticate the CA's key and reputation? With dozens or hundreds of CAs you pretty much can't, especially because they're all indistinguishable to you, and furthermore the very act of revocation is out of your control - the power is really in the hands of the likes of Google and Mozilla. On the other hand, if your "CA" is a person you can easily reason about their reputation and stake in it and who they might reasonably be able to in turn authenticate.

In addition while a government trying to attack CA's can use any compromised CA to attack many different targets at once, attacking individuals may be successful, but any one attack only compromises WoT in a small domain - the cost and effort expended per target is vastly higher.

In any case if the global infrastructure is subverted there's little guarantee those efforts will actually be stopped ("We need to MITM the internet connections of terrorists and child pornorgraphers!") leaving us with WoT; having a community that knows and uses WoT with even marginal effectiveness makes those kinds of subversion attempts less attractive.

I think Mike's point is that any key in the WoT that became widely known enough and that signed enough keys is basically a CA, and that guy could be legally pressured in the same way as a PKI CA could (or even easier because they are unlikely to have a team of lawyers).

There is indeed value in establishing continuity across a long term key, although key management is hard (and revocation of bogus keys is even harder). I think one of the aspects of the PKI that is often overlooked is that although people love to complain about how there are so many CAs, the fact that there are lots does make a global revocation actually achievable. If there were only 5 then revocation would be much harder or even infeasible. CAs know that being revoked means immediate death of the business, so they put a lot of effort into guarding against accidental screwups.

The other thing is that with cert transparency, it forces the hand of governments - either you subvert the entire global infrastructure publicly, atomically and noisily, or a CA you abuse will end up getting quickly revoked, making it a rather expensive proposition.

Ritual bathing is a common religious practice, yet no-one uses its existence to disparage people who take showers.

WoT is a tool, and like every other tool it has strengths and weaknesses. It's main strength is that it's heavily decentralized, and attacking it on a broad scale is hard and always will be hard; with CA infrastructure attacking it is quite possible with the current legal environment, (witness the occasional commercial availability of MITM boxes with trusted CA certs in them) and could be made trivial with the stroke of a legislatures' pen. (it's well within the power of government to change the laws to force CA's to create bogus certs on demand) Absolutists like Mike Perry like to wank about scenarios with high-powered attackers, but forget that the human nature of WoT makes those attacks expensive and risky to pull off, and downright impractical to pull off in an automated fashion.

Privacy concerns are a genuine weakness of WoT, but they shouldn't be overstated either: in the case of "Edward" trying to find journalist "Glenn's" genuine PGP key while Edward may have good reasons not to PGP sign Glenn's key, the fact that 10 other well known journalists/writers/etc. signed Glenn's key makes it easier for Edward to validate Glenn's key. At the same time those signatures pose no particular threat to Glenn: he's a public figure anyway. In the scenario where both parties need to maintain their privacy ask yourself, how did those two parties find out about each other in the first place?

The real weakness of WoT is more metaphysical: by being imperfect enough to invite hyperbole about it's insecurities it discourages people from using cryptography at all. In particular people discount the value of PGP signing their public work, like emails to mailing lists, publications and source code, and because people don't see the value in doing so systems are frequently designed in ways that make doing so inconvenient or impossible. (like this forum) Perry appears to have some grasp of this point: "Every time I verify a signature from a key sent to an email address that is not mine ... add a tiny amount of trust to that key" but unfortunately goes on to talk about downloading keys from keyservers, somehow, without describing exactly what the keyserver is supposed to be validating. (Is this a PGP Corporation style email ownership verification? Timestamping/oldest key? Keyservers currently do absolutely no verification at all.)

Of course, if you're unable or unwilling to comprehend how PGP works you probably should just stick with central certificate authorities and hope that efforts like Google's CA transparency keep them honest, but keep in mind that you're outsourcing your security to someone else. If you are willing and able, don't let geeks wanking about how broken WoT is discourage you.

It's already implemented and merged. Gavin's original pull req has a link to an example generator:

https://github.com/bitcoin/bitcoin/pull/2539
https://bitcoincore.org/~gavin/createpaymentrequest.php

Could anybody point me in the general direction of this (or other) examples?

Also is there an official PR where the BIP is implemented?

It is.  That is why I am so unenthusiastic about key signing.  Beyond a single, direct connection, it's just geek wanking.

That is also why I do not think cjdns, with its WoT-like model of "only connect to your friends" will ever scale to any useful size.  cjdns is otherwise quite nice.

In a stroke of good timing, Mike Perry of the Tor project just posted a critique of the web of trust:

  https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html

He raises a lot of other issues that I hadn't discussed.

His description of the WoT as being a "quasi-religious hacker ritual" made me laugh. That pretty much sums it up.

Employers with more than just few employees are likely use a payroll service anyway so some type of bitcoin service with an audit trail and dispute recourse like Coinbase, BitPay etc., where they can just send it to a user account or email address is a more likely scenario.

They're no more likely to participate in complex, personalized bitcoin transaction protocols than the Dread Pirate Roberts is likely to get an SSL cerificate.

Could it be extensible to SSL certificate fingerprints stored in Namecoin blockchain, instead of X.509 (centralised) option?

Damn, it's truly a shame that it's impossible to buy bitcoins with fiat or vice-versa, because then the employer could just convert the paycheck to whatever the employee wants it as at the time of payment, regardless of what the merchant keeps their money as. /sarcasm

If you would like to learn more about deflation and bitcoin, read the many topics linked here:
https://www.google.com/cse?cx=016660200577587308545%3Aesf40ml9aag&ie=UTF-8&q=deflation&sa=Google+search#gsc.tab=0&gsc.q=deflation&gsc.page=1

Further discussion about deflation in this thread will be considered off-topic, so please refrain from replying to this post.

this should be a sticky thread, no doubt.

Thanks for this FAQ Mike!

I also think that salary example is not that convincing

You will never get your salary paid in bitcoin if its price continuously rise, your boss will not be so stupid to pay you a deflative currency, he will pay you fiat money as long as he can get them, unless fiat money disappear from the world, bitcoin will not be used for purchasing at large scale. Employers will mortgage the bitcoin and get fiat loans to pay their employee  

And I just did two polls, it seems most of the people's action is save the coin instead of spend it, or only spend a very small part of it in a much later time, and this ensured bitcoin's exchange rate will rise forever
https://bitcointalksearch.org/topic/poll-your-trading-style-295753

Anyway, I can see the purpose of this payment protocol is to extend the functionality in payment. But people might just ignore it like before, using that 34 character address makes people feel much more secure so that they might accept the inconvenience comes with that. And it is so cool   A web address? The first reaction is a phishing site

Currently they are unrelated. You could at some point extend the payment protocol to be a starting point for the micropayment channels protocol, and that way you'd get the benefits of the authentication, but it isn't supported today.

Doing a network of payment channels is rather complicated. I'm still beating the bugs out of the existing micropayments code and working on an example app and other important APIs for it. So we didn't even nail down the "A pays B" case yet.

That said I'm actually very close to having a nice, easy to use GUI for micropayment based file downloads/servers.  I think it will be the first truly end-user oriented contracts based app, which will be a great milestone. There are some bugs and some other things that need fixing, but I'm almost done. Perhaps if I can work at the same time as listening to the talks I'll even get it finished by the end of the Amsterdam conference. If you're here you could see it

I'm not sure paid-for file downloads are really that big a deal, but the code is really simple so I'm hoping that someone will think it's cool and run with it, like by adding file upload capability, a simple P2P discovery network and so on. A few more features like that and we have the very beginnings of Gregory Maxwells StorJ vision. More importantly I want to turn it into a tutorial app, so everyone can see how we went from a protocol writeup on a wiki page to an actual working, reasonably attractive and professional looking GUI app usable (and programmable!) by mere mortals.

Once people see how we did it and that it's not really so hard, my dream is that we'll see real growth in slick, usable contract-based pure P2P applications. But Peter might be right - perhaps it won't work out like that. Only one way to find out! Up up and away! :-)

It doesn't work like that. You don't know any of the other customers, most likely, so being presented with 100 signatures that are claimed to be 100 random people doesn't help. What if they are all fake?

So then you say, OK, customers can sign other customers! We'll make a web of trust!

Well, see the last question in the FAQ for why that sort of scheme eventually turns into the regular PKI.

I'll say it again - these are fundamentally difficult problems. If you think you've found a magic quick fix, then you are saying you found something lots of very bright cryptographers didn't. Probably you're wrong.