FAQ on the payment protocol

[callem]

Hardly. Making payments with good privacy is the whole point of Bitcoin, isn't it?

No. I believe the whole point of Bitcoin is "A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution". Privacy is just a secondary objective.

Back to the topic. Unless the salary is paid with 100 completely unrelated transactions, your friend could still figure out your salary. This will create a massive overhead and is obviously not sustainable.

In addition, it would be a stupid idea to ask your boss to pay directly to a hot wallet on your smartphone. Firstly, it's unsafe. Secondly, you boss can see all your transactions. The right way is to ask your boss to send to your salary wallet, and use some coin-mixing scheme to move the money to your spending wallet.

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.

[1714037649]

1714037649

[1714037649]

1714037649

[1714037649]

1714037649

[1714037649]

1714037649

[Mike Hearn]

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.

[jgarzik]

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

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.

[Tachikoma]

How will non-shopkeepers create payment requests?

Today the payment request system is intended for online shops and payment processors like BitPay. Gavin wrote some PHP that can be used to generate and serve the signed requests server side.

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

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

[Mike Hearn]

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

[Peter Todd]

(Mike Perry's) description of the WoT as being a "quasi-religious hacker ritual" made me laugh. That pretty much sums it up.

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.

[Mike Hearn]

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.

[Peter Todd]

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

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.

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.

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.

[jl2012]

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.

[Peter Todd]

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.

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)

[Mike Hearn]

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.

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

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

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.

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.

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.

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.

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

[Peter Todd]

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.

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

Think harder - that example is not external to 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

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.

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.

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.

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.

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.

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

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

[marcus_of_augustus]

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

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

[Mike Hearn]

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:

Code:

import unicodedata
s = u'www.google.com is not www.gooɡle.com'
for i, c in enumerate(s): print i, '%04x' % ord(c), unicodedata.category(c), unicodedata.name(c)

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.

[marcus_of_augustus]

So cosy right on up to the NSA's CA system and we'll all be just swell then?

http://security.stackexchange.com/questions/38199/can-a-nation-state-adversary-perform-a-mitm-attack-by-compelling-a-ca-to-issue-t

What's that saying about the "power of the illusion of security ..."?

[Mike Hearn]

Please do re-read the FAQ. It talks about how ways that problem is being tackled. Obviously SSL is important enough that people aren't going to just shrug and give up on it.

Also, the world would notice quickly if there were bulk MITM attacks happening. The leaked documents have mentioned MITM attacks, but they were also mentioned as being highly targeted and not a dragnet. If the NSA have managed to break SSL in bulk it's not due to the CA system but rather their rumoured 2010 cryptanalytic breakthrough.

To be honest I'm tired of this argument. If you've got something better, show us. So far 100% of the proposed alternatives have massive gaping holes in them, with no clear path to a fix.

[phelix]

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.

Wait a minute. How do people go to mtgox? They enter "mtgox.com" in their browser and trust their system to take them to the right place. From the little I know about the current CA system I guess the browser asks the CA server for a certificate fingerprint or something so I get a green lock icon or something if I am talking to a server with matching cert.

So in fact a little string is all that counts.

Probably most people even go there the first time by clicking some random link on the internets. If you fall for rntgox.com or some special character trick - bad luck. If the fake site is good and has a certificate for rntgox.com or even for "MtGox Corp. Lim. (cn)" - bad luck.

Again it's the little string that counts and the cert helps little.

If a company's main domain is betterexchange.bit with Namecoin TLS you can be more certain than with the current CA system that you are talking the server that you want to (assuming a strong implementation).

[confusion attacks]

direct Unicode entries are not supported

Not sure if this is being enforced currently in Namecoin but a string of simple characters is an ok solution imho.

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.

The identity problem can be solved with Namecoin. Trust is the hard part but I'm sure it is possible and will come.

edit: I'm not saying the payment protocol should be implemented only with Namecoin domains/ids right now. But somehow I have a dislike against the current CA system, especially in combination with Bitcoin. It is just unbitcoinish.

[jgarzik]

The identity problem can be solved with Namecoin. Trust is the hard part but I'm sure it is possible and will come.

Not namecoin alone.  Namecoin is just a storage method.

[Mike Hearn]

Wait a minute. How do people go to mtgox? They enter "mtgox.com" in their browser and trust their system to take them to the right place.

If you go to mtgox.com then you see MtGox Co. Ltd [JP] in the browser address bar (on Chrome). So if someone told you about this Japanese company called Mt Gox then you know you're at the right place and the website was verified as being owned by a real company with that name.

For newish companies that were born on the net usually their domain name IS their identity, but there are lots and lots of organisations in the world that aren't like that.

Probably most people even go there the first time by clicking some random link on the internets. If you fall for rntgox.com or some special character trick - bad luck. If the fake site is good and has a certificate for rntgox.com or even for "MtGox Corp. Lim. (cn)" - bad luck.

With the CA system that's not "Bad luck" it's a failure that would get investigated, at least in theory.

With Namecoin, sure, it's just bad luck. You lose your money. That's kind of the outcome we DON'T want, right?

If a company's main domain is betterexchange.bit with Namecoin TLS you can be more certain than with the current CA system that you are talking the server that you want to (assuming a strong implementation).

And back in reality the companies main domain is betterexchange.com and they may or may not use NameCoin, so you're back to square one - you don't know if you're talking to the real owner or not.

direct Unicode entries are not supported

Yes, brilliant, they "solve" the problem by simply not supporting any alphabet other than the English alphabet. That's not a solution, that's a cop-out.

edit: I'm not saying the payment protocol should be implemented only with Namecoin domains/ids right now. But somehow I have a dislike against the current CA system, especially in combination with Bitcoin. It is just unbitcoinish.

It's a free market for providers that are unified by common cryptographic protocols. Does that remind you of something? The market for mining blocks, perhaps?

[MPOE-PR]

I still prefer the web of trust

You shouldn't. The PKI is the result of evolving a web of trust style system over many years, as it got real usage. It looks the way it does because of its solutions to the problems the raw web of trust model has.

For instance, let's say Bob starts signing keys using GPG. His signature is worth very little unless I happen to know and trust him. In practice as a new Bitcoin user who just saw it on CNN, I don't know Bob. However, maybe I do trust the guys making the Trezor because they are a real company and they live in a country with sane laws, etc, they have lots of happy customers, so that gives me a starting point. Then if stick and slush trust Bob, and Bob has signed the key of bitcoinstore.com then I have a chain of trust to the store.

Bob has become a certificate authority!

How trustworthy is Bob, really? Does he keep his private key on a computer running a warez copy of Windows XP that is full of malware? It would be nice if we could formalise the "stick and slush trust Bob" part of the above description. Otherwise what stops Mallory turning up and demanding that Trezor trusts him too?

A good way to resolve this conundrum is to come up with a set of best practices, like keeping your private key inside a hardware security module, and setting some rules around when Bob/Mallory should sign a public key. To increase trust in the system and stop Mallory just claiming he follows the rules when really he doesn't, we might want to create a formal audit system and an auditor organisation that verifies these guys are following the rules.

We just re-invented the WebTrust Audit:

   http://www.sslshopper.com/article-what-is-webtrust-for-cas-certification-authorities.html

Eventually as Bob and Mallory get more professional and trusted, they'll discover it's sort of hard to do it in their spare time so they'll create companies and start charging fees. They'll compete in the open market. After a long time, some of them will discover that for the most basic kind of key signing (emails and domain names) it can be entirely automated and done for free.

That's StartSSL.

As the number of trusted parties goes up and they handle more and more key signings, eventually Bob or Mallory might get hacked or pressured by the government. It'd be nice if everyone knew what keys Bob and Mallory had signed, in a more scalable way than just relying on everyone to upload all their keys to the MIT key server.

That's certificate transparency.

I hope you can see now why the PGP web of trust would eventually end up being pretty similar to the regular PKI, if it got big enough.

Your take on things is chiefly informed by your marauding ignorance and otherwise well documented facetiousness.

Stick to generating forks through failing to read code rather than opining on matters you are intellectually unqualified to comprehend.

Also read the relevant Trilema articles, explaining why power does not reside with you collection of fuckwits, and what the required steps are to remedy your problems there.