Invoices/Payments/Receipts proposal discussion

[Gavin Andresen]

For those of you not subscribed to bitcoin-development@lists.sourceforge.net :

We've been having a productive discussion of a proposal for a simple payment protocol to get a much better user experience than is given by bitcoin addresses:
  http://sourceforge.net/mailarchive/message.php?msg_id=30147926

This is the next big "lets all agree to do things the same way" thing I think we should tackle. Latest pseudo-spec is: https://gist.github.com/4120476

I'd prefer to keep the discussion on the mailing list (I think this forum is a great place for brainstorming, but I think the mailing list is a little better for getting consensus on all the nitty-gritty details of a proposal).

[1714047020]

1714047020

[1714047020]

1714047020

[1714047020]

1714047020

[justusranvier]

If I have an ongoing business relationship with a company and we are both using HD wallets I'd like the ability to exchange key parameters exactly once so that each one of us can generate an arbitrary number of unique addresses as needed for each future transaction.

[blueadept]

One of my pet use cases is a group of friends splitting a restaurant check, with support for tips. I know the restaurants and bars that accept or want to accept Bitcoin would agree.

[J-Norm]

I have always been interested in the idea of form based contracts being filled in and cryptographically signed and even for such contracts to be able to control the movement of money when requirements are met.

I think one day such simple contracts will be used from point of sale to real estate escrow.

[ShireSilver]

Don't know nothin about any mailing list, but this scares me: "Requests for payment (Invoices) are tied to authenticated identities using the only widely-deployed identity authentication system we have right now (X.509 certificates signed by root certificate authorities)"

I'm certainly no expert on bitcoin's protocol or code, but it sounds like a bad idea to add any sort of centralization. I've never really trusted 'root certificate authorities' and I have heard of exploits being successful against them.

Why does anyone need identities when invoicing? Or more accurately, why must every invoice have an identity attached?

[Gavin Andresen]

Why does anyone need identities when invoicing? Or more accurately, why must every invoice have an identity attached?

You will be able to generate and send unsigned invoices that has no identity attached.

But they are much less secure than signed invoices, because a "man in the middle" attacker could rewrite the Invoice so the bitcoins go to him.

Or if you have a dispute with the merchant and all you have is an unsigned Invoice, the merchant can claim that "your machine must have been hacked, you sent the bitcoins to an address that isn't mine!"

[etotheipi]

Don't know nothin about any mailing list, but this scares me: "Requests for payment (Invoices) are tied to authenticated identities using the only widely-deployed identity authentication system we have right now (X.509 certificates signed by root certificate authorities)"

I'm certainly no expert on bitcoin's protocol or code, but it sounds like a bad idea to add any sort of centralization. I've never really trusted 'root certificate authorities' and I have heard of exploits being successful against them.

Why does anyone need identities when invoicing? Or more accurately, why must every invoice have an identity attached?

I too, felt uncomfortable about using the CA system.  It feels like a psuedo-centralized, corporate-privileged system that milks little guys for high profits.  I feel like it's not "in the spirit" of Bitcoin...

But then reality set in -- which is that the CA system does provide quite a bit of value.  Regardless of how much you get pay to get a signed a certificate to run your website from some "corporate overlord," you are getting security against MitM attacks.  And that is important, especially for invoices and payment requests with irreversible Bitcoin transactions.  This protocol can slide right into the existing CA infrastructure, and instantly provide on the protections that the system already gives to most other security-sensitive internet services.

In that sense, it is a massive boon to be able to piggyback off the existing infrastructure, since Bitcoin already has enough hurdles to get wider acceptance.  This won't be one of those hurdles.

[justusranvier]

Regardless of how much you get pay to get a signed a certificate to run your website from some "corporate overlord," you are getting security against MitM attacks.

Really? That's news to me.

http://tech.slashdot.org/story/11/10/28/1954201/four-cas-have-been-compromised-since-june
https://www.net-security.org/secworld.php?id=11537
http://threatpost.com/en_us/blogs/mozilla-warn-cas-about-issuing-mitm-certificates-021412

It looks more like the CA system is a bad joke that provides the illusion of protection only.

[etotheipi]

Regardless of how much you get pay to get a signed a certificate to run your website from some "corporate overlord," you are getting security against MitM attacks.

Really? That's news to me.

http://tech.slashdot.org/story/11/10/28/1954201/four-cas-have-been-compromised-since-june
https://www.net-security.org/secworld.php?id=11537
http://threatpost.com/en_us/blogs/mozilla-warn-cas-about-issuing-mitm-certificates-021412

It looks more like the CA system is a bad joke.

Just because there have been security breaches, doesn't mean that the system is useless.  While the system could be improved, the alternatives are terrible.  If you don't use an established system, then you need to build up a whole new "web of trust", and users and merchants will be doing a lot of work, outside an established system, just to accommodate this use case (Bitcoin payments).

If what you suggest is true, then credit card payments on the internet are a joke, too.  Really, it's not quite black and white like that...

[justusranvier]

Just because there have been security breaches, doesn't mean that the system is useless.

Of course it does. If you can't rely on it you don't have security.

"This fire extinguisher doesn't always fail, it only has problems when I try to use it. It's fine most of the time."

[etotheipi]

Just because there have been security breaches, doesn't mean that the system is useless.

Of course it does. If you can't rely on it you don't have security.

"This fire extinguisher doesn't always fail, only when I try to use it. It's fine most of the time."

Then, I guess we might as well start using http:// for credit cards transactions and email now.  Since there's no value added by the CA system...

If you are doing things that require ultimate security, at the risk of millions of dollars, I agree with you.  But for sending $23 over the internet to pay for your water bill, it does exactly what it is supposed to do.

[justusranvier]

Then, I guess we might as well start using http:// for credit cards transactions and email now.  Since there's no value added by the CA system...

That's a false dichotomy and dishonest.

The relevant question is how much value the CA system adds compared self-signed certificates, not compared to unencrypted traffic.

What percentage of attackers who want to perform a MITM attack are actually prevented from doing so by CAs?

[etotheipi]

Then, I guess we might as well start using http:// for credit cards transactions and email now.  Since there's no value added by the CA system...

That's a false dichotomy and dishonest.

The relevant question is how much value the CA system adds compared self-signed certificates, not compared to unencrypted traffic.

The answer is:  it makes MitM attacks dramatically more difficult to execute by an arbitrary attacker.  Self-signed certificates are useless against MitM attacks.  I consider that a huge benefit for an irreversible payment system, even if it's not 100%.

[justusranvier]

The answer is:  it makes MitM attacks dramatically more difficult to execute by an arbitrary attacker.

That's the theory, where's the proof?

How difficult is it really to get a fake certificate?

If every Tom, Dick and Harry can get one basically on demand, the illusion of protection extremely harmful.

[justusranvier]

Has anything fundamentally changed since February of this year?

http://www.schneier.com/blog/archives/2012/02/verisign_hacked.html

VeriSign Hacked, Successfully and Repeatedly, in 2010

Reuters discovered the information:

    The VeriSign attacks were revealed in a quarterly U.S. Securities and Exchange Commission filing in October that followed new guidelines on reporting security breaches to investors. It was the most striking disclosure to emerge in a review by Reuters of more than 2,000 documents mentioning breach risks since the SEC guidance was published.

The company, unsurprisingly, is saying nothing.

    VeriSign declined multiple interview requests, and senior employees said privately that they had not been given any more details than were in the filing. One said it was impossible to tell if the breach was the result of a concerted effort by a national power, though that was a possibility. "It's an ugly, slim sliver of facts. It's not enough," he said.

The problem for all of us, naturally, is if the certificate system was hacked, allowing the bad guys to forge certificates. (This has, of course, happened before.)

Are we finally ready to accept that the certificate system is completely broken?

[someone42]

How will signed invoices work with offline wallets? I ask this in the context of dedicated hardware wallets, but this issue also applies to cold-storage wallets on computers intentionally disconnected from the Internet.

Theoretically, basic verification of a signature is feasible. As long as an offline device is seeded with a sufficient set of root certificates, it can verify a valid chain of certificates. However, there are problems with certificate revocation. Ideally, certificate verification should be accompanied by revocation checks. For an offline device, checks are very difficult.

I am aware that even with no revocation checking, the security of offline devices is significantly enhanced by signed invoices. But is it possible to do better than this?

[Mike Hearn]

I think there are a few things that need to be cleared up here.

Firstly, self signed certificates. These can be more secure than the CA infrastructure if and only if you get the certificate out of band from the merchant in a trustworthy way - like by meeting them in person. Otherwise they are useless. If you don't understand why browsers now universally reject self-signed certs without any easy override, then you don't understand cryptography.

Consider the dispute case: you present a self-signed invoice and accepted Bitcoin transaction as proof you paid. Merchant says "I didn't sign that". It's your word vs his, there's no way to mediate the dispute. Now consider with a valid chain to a root CA. Merchant says "I didn't sign that", you say "somebody with a certificate issued under your identity did!" and now it's not just your word vs his, there's some evidence in your favor. No, it's not bulletproof. Maybe they got hacked, or their CA did. But, probably not - CA hacks are rare and seem to usually be linked some kind of government or corporate espionage.

Secondly, yes, X.509 cert chains are flawed in many ways. They're being used in this spec for one reason and one reason only - lots and lots and lots of people already have them, they're easy to get, and they assert to an identity (normally a domain name). Also, the code to do the signing and verification is simple (I sent Gavin an example) and can be implemented with OpenSSL in about a page of code. Implementations in other languages would probably also be easy.

So, we use X.509 here for practical reasons. It's a version 1, nothing more.

Where would we go from here? There are a few obvious improvements we could make in version 2. Protocol buffers are easily extendable so it's trivial to come up with protocol extensions later.

• We could introduce our own cert type that allows delegation for the purposes of signing Bitcoin invoices, but isn't accepted by normal SSL stacks. This solves the problem of "I have an SSL cert for foobar.net but I want BitPay to handle payments for me, and I don't want my payment processor to be able to MITM my secure connections". Another scenario - you have a bunch of salesmen or waiters wandering around your shops and you want them to be able to quickly issue invoices on behalf of the business, but you don't want to give them all your SSL keys. The way this would work is, we create a new ChainedPaymentCert protocol message that contains a signature calculated using the X.509 CA issued private key, and another public key, so it effectively chains onto the bottom of the X.509 chain (but it isn't an actual X.509 cert). Bitcoin clients would recognize and parse this new cert type and allow it to assert the authority of the domain name in the X.509 parent cert, but SSL stacks wouldn't.
• We could also use DNSSEC. This is a relatively new system so there's less shared experience around how to use it for something like Bitcoin invoices. But it's sort of similar to SSL, except instead of the CA heirarchy it uses the DNS heirarchy. It's attractive in that everyone should be getting DNSSEC keys for free, from what I understand (if you have a domain name). It seems like Chrome will happily accept self-signed SSL certs that have DNSSEC data embedded in them, probably, it's easiest for us to go with the flow and do the same.
• We could introduce another type of custom Bitcoin cert chain for other purposes, with roots that you might trust more. For instance, MtGox could be a root authority and issue certs derived from your government issued ID that is submitted as part of the "Know your customer" checks. A portable digital cert that you can use to sign things with could be very useful, and it'd mean you can sign invoices with a personal identity instead of a website/business identity.

Integrating a web of trust that doesn't have any roots at all isn't quite so easy. Unless you have access to the full trust graph, you can't build a chain between yourself and the counterparty to prove you own the identity/nym which you are asserting. So the question is how do you build a protocol that lets two parties who don't know each other find enough common connections and then how do you calculate the trustworthyness of those connections. When you have a short chain back to an organization that you axiomatically accept is competent and trustworthy it's easy (until your assumptions are violated, of course). If you don't have that, you need new protocols and bootstrapping mechanisms.

[ShireSilver]

Why does anyone need identities when invoicing? Or more accurately, why must every invoice have an identity attached?

You will be able to generate and send unsigned invoices that has no identity attached.

I'm cool with that, especially if this part of the proposal is implemented as a sort of plugin, where in the future a more secure and decentralized system can also be used.

[Jouke]

I think it is great for the multi person wallet part. I don't get the use case of satoshdice though. What does it solve?

edit: I got convinced of the usefullness of this proposal by the post of Mike Hearn explaining that it may be used to let merchants broadcast the transaction as well.

[MatthewLM]

I support this idea and I have thought about this myself previously. This will especially become handy with Extended Validation certificates as you can show proof of identity for a business.

script: a "TxOut" script to which the customer should direct payment.
This will normally be one of the standard Bitcoin transaction script
(e.g. pubkey OP_CHECKSIG).

Why not use a P2SH as the output, instead of the entire script? Makes it very simple.

And why not just accept an invoice as paid when the funds have been received? You can use a unique address for this. The proof of payment is then stored in the block-chain. That would be simple and I do not see the reason for complicating it with this Payment and Receipt message.

So you just pay to the address on the invoice. If the merchant says "We have not received the funds" you can give evidence that you sent the funds by showing the transaction in the block-chain which conforms to the amount requested and P2SH given in the Invoice.

[Mike Hearn]

P2SH is itself a script so you can already do that.

A signed invoice and accepted transaction together are indeed proof of payment. The SignedReceipt message was deleted in a later version of the proposal.

[MatthewLM]

P2SH is itself a script so you can already do that.

I mean it would be easy to just provide the 20 byte bitcoin address in the invoice rather than an entire script. P2SH addresses would allow for any script to be used, but only an address would be needed in the invoice.

A signed invoice and accepted transaction together are indeed proof of payment. The SignedReceipt message was deleted in a later version of the proposal.

That makes much more sense.

And one should think about how a merchant provides these invoices. It could be a downloadable file or it could be a QR code with a URL to download a file.

[Pieter Wuille]

And one should think about how a merchant provides these invoices. It could be a downloadable file or it could be a QR code with a URL to download a file.

Or a QR code that contains the file.

[MatthewLM]

Or a QR code that contains the file.

Wouldn't the certificates, plus the invoice memo field (which could include long contract terms) be too large for a QR code?

[commonancestor]

I think Receipt is only a "soft" receipt. It signifies only a receipt of valid payment message, not the funds. Hence evil customer may still try a double spend after getting the receipt. The "hard" receipt should be provided only after N confirmations. On the other hand, a real world merchant usually provides receipt when receiving banknotes that appear genuine, even if they may later turn out counterfeit. So maybe some reasonable trust level should be found. But now I prefer that N confirmations option.

Also I think the specification should cater for real world shops and QR and NFC communication. In particular I like idea of some offline spending wallets, communicating only with POS terminals, and getting power and updates (blockchain info, root certificates) from USB occasionally. So Invoice.receiptURI should cover also QR and NFC. Not sure if an offline device could still verify certificates, but if it has got root certificates and merchants provide the rest, then it seems possible.

[Carlton Banks]

Integrating a web of trust that doesn't have any roots at all isn't quite so easy. Unless you have access to the full trust graph, you can't build a chain between yourself and the counterparty to prove you own the identity/nym which you are asserting. So the question is how do you build a protocol that lets two parties who don't know each other find enough common connections and then how do you calculate the trustworthyness of those connections. When you have a short chain back to an organization that you axiomatically accept is competent and trustworthy it's easy (until your assumptions are violated, of course). If you don't have that, you need new protocols and bootstrapping mechanisms.

It's a problem easily solved: forget centralized certification and commoditize the actual trust itself. Like eBay feedback points. Every transaction completed to the satisfaction of both parties then credits each party with a new unit of "trust". You would make a public record of it, to establish a picture of how trust in major transaction hubs changes over time. At least then the relative trustworthyness of actors in the system is given an actual value, instead of the current situation of a qualitative notion of trust in the certificate authorities.

Edit: and yes, I know that doesn't help out with implementing an integrated signed Invoices and Receipts system. I'm saying it's a solution searching for a problem. I don't need to prove my receipt of purchase from a website using the Bitcoin client, the merchant website can record that in my account already. Ditto the invoices. Why does Bitcoin need to provide this when merchant websites can (and already successfully do)?

[killerstorm]

Unless you have access to the full trust graph, you can't build a chain between yourself and the counterparty to prove you own the identity/nym which you are asserting.

Doesn't namecoin solve this problem?

[etotheipi]

Integrating a web of trust that doesn't have any roots at all isn't quite so easy. Unless you have access to the full trust graph, you can't build a chain between yourself and the counterparty to prove you own the identity/nym which you are asserting. So the question is how do you build a protocol that lets two parties who don't know each other find enough common connections and then how do you calculate the trustworthyness of those connections. When you have a short chain back to an organization that you axiomatically accept is competent and trustworthy it's easy (until your assumptions are violated, of course). If you don't have that, you need new protocols and bootstrapping mechanisms.

It's a problem easily solved: forget centralized certification and commoditize the actual trust itself. Like eBay feedback points. Every transaction completed to the satisfaction of both parties then credits each party with a new unit of "trust". You would make a public record of it, to establish a picture of how trust in major transaction hubs changes over time. At least then the relative trustworthyness of actors in the system is given an actual value, instead of the current situation of a qualitative notion of trust in the certificate authorities.

...and then people set up fake merchant identities and countless fake customer identities, and bump up their own trust ratings as high as they want before each scam.  The best way to prevent this from happening is to elect third parties that are trusted by lots of people, to check identities before letting them into the system... oh wait, I just described the CA system...

The CA system isn't perfect, but those who succeed in breaking it are usually high profile (like Mike Hearn was saying: state-sponsored, etc), and they're not going to waste their time stealing the $42 I paid BitBrew for some coffee.  But using self-signed certificates, anyone in the coffee shop with me can MitM me if they, perhaps, set up their system with the same SSID and I mistakenly connect through them when making my purchase.

Anything that is big enough to be worth stealing on a massive scale is usually done through direct merchant-customer interaction -- you don't usually buy a $17,000 car on the internet with your credit card... such large transactions usually use a second-level (or more-reliable) form of authentication beyond CAs.  For "regular"-sized purchases, it makes complete sense to piggyback off of a "complete" system that is already in place, for which everyone who's ever bought anything on the internet is already capable of using.

One good thing about Bitcoin is that there is not something like a credit card number to steal.  The worst someone can do is redirect a given transaction, but nothing like getting your CC number and draining your available credit, leaving you to spend hours on the phone with credit agencies trying to restore your "trust."  Therefore, a passive eavesdropper who is able to decrypt the payment stream cannot directly benefit like they would with credit card transactions:  with CC, they decrypt and steal databases of CC numbers and sell them on the black market (probably with BTC).  But getting a database of past transactions executed in this way (via BTC) does not offer the attacker anything.  

[MatthewLM]

If it wasn't for PKI, e-commerce would be very dangerous, so thank goodness for it. It means I can buy a DVD off the internet and know I'm paying to the right person and not a man-in-the-middle.

If another system worked better, we'd be using that, but since there is none we do not. And if you do not trust a particular CA, then you can remove it from web browsers: http://techfleece.com/2011/09/09/how-to-delete-the-diginotar-ca-certificate-in-chrome-firefox-and-ie/

A bitcoin system should also allow users to configure trusted CAs.

[Carlton Banks]

Integrating a web of trust that doesn't have any roots at all isn't quite so easy. Unless you have access to the full trust graph, you can't build a chain between yourself and the counterparty to prove you own the identity/nym which you are asserting. So the question is how do you build a protocol that lets two parties who don't know each other find enough common connections and then how do you calculate the trustworthyness of those connections. When you have a short chain back to an organization that you axiomatically accept is competent and trustworthy it's easy (until your assumptions are violated, of course). If you don't have that, you need new protocols and bootstrapping mechanisms.

It's a problem easily solved: forget centralized certification and commoditize the actual trust itself. Like eBay feedback points. Every transaction completed to the satisfaction of both parties then credits each party with a new unit of "trust". You would make a public record of it, to establish a picture of how trust in major transaction hubs changes over time. At least then the relative trustworthyness of actors in the system is given an actual value, instead of the current situation of a qualitative notion of trust in the certificate authorities.

...and then people set up fake merchant identities and countless fake customer identities, and bump up their own trust ratings as high as they want before each scam.  The only way to prevent this from happening is to elect third parties that are trusted by lots of people, to check identities before letting them into the system... oh wait, I just described the CA system...

I agree with this analysis under circumstances where the system isn't near-ubiquitous, but in real life, when a multiple fake identity scammer themself becomes identified (with their actual real world identity), then their own personal trust capital will become appropriately diminished (people that know them will revoke the trust they have invested in them, so not quite a traditional commodity by any stretch). And so with a given amount of critical mass, the system would self-regulate. And imagine how "wealthy" eccentric old widowers suddenly become? Everyone's encountered the people you can trust the most in life, and these people would get direct, quantifiable recognition for it. How about that?

[Carlton Banks]

If it wasn't for PKI, e-commerce would be very dangerous, so thank goodness for it. It means I can buy a DVD off the internet and know I'm paying to the right person and not a man-in-the-middle.

If another system worked better, we'd be using that, but since there is none we do not. And if you do not trust a particular CA, then you can remove it from web browsers: http://techfleece.com/2011/09/09/how-to-delete-the-diginotar-ca-certificate-in-chrome-firefox-and-ie/

A bitcoin system should also allow users to configure trusted CAs.

Not talking about encrypting transactions, I'm referring to the specific case of identities verified by CA's. Agree entirely to what you said above, it's kind of self evident

[Carlton Banks]

Integrating a web of trust that doesn't have any roots at all isn't quite so easy. Unless you have access to the full trust graph, you can't build a chain between yourself and the counterparty to prove you own the identity/nym which you are asserting. So the question is how do you build a protocol that lets two parties who don't know each other find enough common connections and then how do you calculate the trustworthyness of those connections. When you have a short chain back to an organization that you axiomatically accept is competent and trustworthy it's easy (until your assumptions are violated, of course). If you don't have that, you need new protocols and bootstrapping mechanisms.

It's a problem easily solved: forget centralized certification and commoditize the actual trust itself. Like eBay feedback points. Every transaction completed to the satisfaction of both parties then credits each party with a new unit of "trust". You would make a public record of it, to establish a picture of how trust in major transaction hubs changes over time. At least then the relative trustworthyness of actors in the system is given an actual value, instead of the current situation of a qualitative notion of trust in the certificate authorities.

...and then people set up fake merchant identities and countless fake customer identities, and bump up their own trust ratings as high as they want before each scam.  The best way to prevent this from happening is to elect third parties that are trusted by lots of people, to check identities before letting them into the system... oh wait, I just described the CA system...

And if you allow me to abstract what you're describing here: a system of trusted authorities that check the veracity of identities.... What are electronic and paper payments if not "identities", or at least having an identifier to distinguish between individual instances is fundamental to a working system. And so, you've also just described (abstractly) the fiat money system.

And here we are again back at the beginning of the argument... except I think the critical mass argument has merit. With enough people using the system, and enough time/resources to reliably discover people abusing it, it can only become stronger as adoption and use increase. The critical mass required is a problem.... unless you can piggy back on the userbase of an existing, growing system that could make good use of a trust credit system (can't seem to think of any obvious candidates myself )

[casascius]

I thought I might point out that I have successfully made deals for Bitcoins using signed payment addresses and existing PKI infrastructure as long ago as early 2011, using a methodology that is not only mind-numbingly simple for even average users, but using a contract form that is arguably admissible in today's courts: digitally signed PDF files.

https://bitcointalk.org/index.php?topic=3170.0

A significant drawback is cost, but the subject proposal already contemplates the purchase of keys from a CA so it's a non-issue, especially for any serious business endeavor, we're talking a few hundred bucks.  This one uses a more secure approach than the hodge podge of SSL CA's: the policy enforced on the Adobe Acrobat document-signing PKI is that all keys must be contained in HSM's (hardware security modules), user's aren't even allowed to know their own private keys.  The price of an Acrobat signing cert includes a keychain sized USB HSM with no private key.  The module generates its own private key, after the user has received it, and the setup process makes web calls to the provider to generate and install a corresponding certificate into the module.

By bringing this up, I wish to be seen as suggesting that a suitable solution to many such problems might already exist, and not in any way to suggest "stop what you're doing, this problem is solved".  Clearly this solution only works when a PDF file is the means in which an invoice is presented to the customer, and only when it's generated in an environment where the required HSM can be used.

My key happens to be a Rainbow iKey 2032 - something already generically available on the market and not proprietary to Adobe.  In fact, I would be willing to bet that it could be coaxed into signing anything interacting with the proper API given the user's passphrase to unlock the module, and on pretty much any platform.  The way it is seen by the computer, it amounts to a smart card reader with a smart card effectively soldered in it.

It's also pretty apparent that it would be desirable for the Bitcoin client to know you're really paying the right person, which isn't feasible in any clean manner from a PDF file (though not impossible - especially if there were such thing as a payment address meta tag inside the PDF file that a bitcoin client could easily pick out after hashing the file and confirming it's properly signed).

[kjj]

SSL is allowed to suck because it tends to protect nothing important.  In the real world, there is no such thing as an irreversible transaction.  A credit card number that gets intercepted these days pretty much means you are going to spend a very annoying 3 minutes on the phone with the fraud department of your bank.  Do you still look for the padlock icon before typing in your credit card number?  I sure don't.  Online stores use SSL because Visa and Mastercard make them use SSL, and the processors insist on SSL because it reduces fraud claims.  You (the user) are never a factor.

My complaints with the SSL system are:
 1.  There are tools that can mitigate the security/fraud problems, but no one takes them seriously.  Turn on strict OCSP checking in your browser if you want to see for your self.
 2.  The CAs actively participate in industrial MITM snooping operations.  Your corporate IT department probably has a box that uses a wildcard cert issued by a legitimate CA to inspect all of your SSL traffic.
 3.  Race to the bottom!  The whole point of having CAs is that they verify things, which is what you pay them for.  Over the years, they've all decided to stop doing their job and just take your money for nothing.  It got so bad that marketing had to step in and invent a whole new class of SSL certs (EV) where the CA actually does what it was supposed to have been doing all along.

That said, SSL is here and everywhere, and as badly as it sucks, every other option sucks worse.  It really is the logical choice for this.  Just remember, there is no chargeback in bitcoin.  If you have a payment request for more money than you can afford to lose, think real hard about how much you really trust that cert.  Odds are very good that no human has ever looked at any part of it before.

[someone42]

It might be worth supporting (or perhaps even demanding) an OCSP stapling-like mechanism for certificate revocation checks. This would place the burden of OCSP querying on the merchant, who is typically better equipped to perform such queries. It also scales better, is potentially more reliable and does not leak information to a 3rd party.

[Rudd-O]

Let's not stab this baby through the heart by using X.509.  This would make it impossible to do pseudonymous invoicing and it's also, well, thoroughly broken (DigiNotar anyone?).

[Mike Hearn]

As Gavin already mentioned, the X.509 support is optional. You can create unsigned invoices. And in future, signed invoices that don't use X.509 if we can find some reasonable system.

[Jouke]

The CA system isn't perfect, but those who succeed in breaking it are usually high profile (like Mike Hearn was saying: state-sponsored, etc), and they're not going to waste their time stealing the $42 I paid BitBrew for some coffee.  

afaik diginotar hack was nothing high profile.

[commonancestor]

Receipt has got a flaw. As a merchant I won't be sending receipts of funds without any confirmations. FYI

[Gavin Andresen]

Receipt has got a flaw. As a merchant I won't be sending receipts of funds without any confirmations. FYI

I would urge you to return a receipt with a memo that says:

"your order will be shipped as soon as your payment has three confirmations."

Explicitly telling your customers what they can expect to happen next is a great feature of the proposal, I think.

[commonancestor]

I would urge you to return a receipt with a memo that says:

"your order will be shipped as soon as your payment has three confirmations."

Explicitly telling your customers what they can expect to happen next is a great feature of the proposal, I think.

I agree this little communication with customer is great, but maybe call it Acknowledgement ...

[Rudd-O]

As Gavin already mentioned, the X.509 support is optional. You can create unsigned invoices. And in future, signed invoices that don't use X.509 if we can find some reasonable system.

Can GPG support be written in the standard, also as an optional feature?

[ripper234]

+1 for this thread, it finally nudged me to purchase a membership in the Bitcoin Foundation (I was just taking my sweet time till now).

Stuff like this is why Bitcoin will remain more relevant than any other alt chain, and why Gavin deserves a paycheck.

While other alt chains are exploring interesting yet esoteric concepts, we've seen little true innovation there (not to dismiss Namecoin & Proof of Stake, both of which might turn out to be real players later on).

Gavin and others in Bitcoin are working on the gray little details that are essential to building a successful payment system, not just building cool toys.

[Mike Hearn]

I agree this little communication with customer is great, but maybe call it Acknowledgement ...

Yeah, that's reasonable. Remember that a receipt is a signed invoice + a confirmed transaction (proof of payment). That is, you cannot have a receipt without blocks. Having a message in the protocol also called Receipt when it's actually an acknowledgement could be confusing indeed.

Can GPG support be written in the standard, also as an optional feature?

Not at the moment, for the reasons that should be apparent from the previous posts. Just saying "GPG support" is way too vague to be actionable. Figuring out how a web of trust can be used in a payment protocol is what I'd call a research level problem - somebody needs to go away and figure out all the messy details, maybe build a proof of concept (as I did for X.509 support), and then write a BIP to show how to extend the payment protocol.

[etotheipi]

I agree this little communication with customer is great, but maybe call it Acknowledgement ...

Yeah, that's reasonable. Remember that a receipt is a signed invoice + a confirmed transaction (proof of payment). That is, you cannot have a receipt without blocks. Having a message in the protocol also called Receipt when it's actually an acknowledgement could be confusing indeed.

Can GPG support be written in the standard, also as an optional feature?

Not at the moment, for the reasons that should be apparent from the previous posts. Just saying "GPG support" is way too vague to be actionable. Figuring out how a web of trust can be used in a payment protocol is what I'd call a research level problem - somebody needs to go away and figure out all the messy details, maybe build a proof of concept (as I did for X.509 support), and then write a BIP to show how to extend the payment protocol.

Even if there's not a developed web-of-trust system for GPG available, technically-savvy people still use GPG successfully.  I agree that such users should have the option to exchange/verify public keys out of band, to their own comfort level, and rely on that for signing invoices.  As long as all parties agree.

[mikegogulski]

In my opinion:

The PKI issue under discussion here is absolutely critical. I understand that the effort aims to provide X.509/CA certificates as one option for securing  the messages under discussion as a modular plugin to an API which would, at the outset, also support "unsigned plain" types. The work embodied in Gavin's "pseudo-spec" looks to me like a big chunk of solid research that will contribute to Bitcoin's flourishing.

But the thinking that leads to comments like this one from Mike worries me deeply:

X.509 cert chains are flawed in many ways. They're being used in this spec for one reason and one reason only - lots and lots and lots of people already have them, they're easy to get, and they assert to an identity (normally a domain name). Also, the code to do the signing and verification is simple (I sent Gavin an example) and can be implemented with OpenSSL in about a page of code.

The facts regarding the existing CA infrastructure, as pointed out by justusranvier above, are irrefutable, and his comment regarding fire extinguishers needs to be taken very seriously by anyone implementing crypto-centric software in the year 2013 and beyond. The CAs are broken beyond repair (if not by design, /tinfoil) and they are not going to be fixed. Implementing new "secured" payments messaging on top of a foundation that includes the public CAs is like building a castle out of counterfeit bricks: no matter the skill of the masons, the castle will fall.

At the moment, the core dev team, in considering this proposal, are acting as architects, engineers and masons. That's great: the puissance they've shown to date makes them masters of all three crafts. But to do the job to the fullest, the castle must protect the people who dwell inside it. And no matter the vision of the architect, the precision of the engineer or the skill of the mason, their work means worse than nothing if they elect to build the castle out of the same faulty bricks being used in That Other Kingdom of which We are All Well Aware. If the barbarian horde which breaches the ramparts does not slay them, surely the survivors of the short-lived siege will, in retribution for their criminal negligence.

Lots of people have and use shitty bricks. Building out of shitty bricks is easy. The road to perdition is easy, too.

[Mike Hearn]

That may well all be true, but it's unclear what the better alternative is. The next best PKI would seem to be DNSSEC which is basically "SSL PKI but with one CA per country or TLD" .... it solves the problem of incompetent CA's by having fewer of them. Hardly an excellent solution. Recall the world started out with just one SSL CA and people complained there wasn't enough competition.

We need something where I can walk into a room holding a beer, sit down and tell my buddy "hey check out bitcoinmagazine.com". Then they go there and make a payment and it says "bitcoinmagazine.com" or "Bitcoin Publishing Inc" or whatever on the screen of their Trezor or other device. We know how to do that with the SSL PKI, we can sort of see how to do that with DNSSEC (though it's a lot more work) and I'm not sure how to do it with anything else. It's a research problem. Perhaps my phone could remember the keys that were used when I visited bitcoinmagazine.com and ambiently broadcast them to the room when I walk in. Then my buddys phone can learn the certs/keys from me at the same time as we're conversing. Anyway it's a hard problem.

[Peter Todd]

This whole PKI discussion misses the bigger issue: the first users of the payment protocol are highly likely to be websites, which means you already depend on SSL security and thus the SSL PKI system. In that circumstance putting all your eggs in one (flawed) basket is perfectly reasonable - better PKI's can be developed later.

Anyway the payment protocol has support for adding additional PKI systems in the future.

[justusranvier]

It seems like it should be possible to use SMS messages as an out of band method for verifying key fingerprints, although since even caller ID can be spoofed I'm not sure how to make it work in the presence of an adversary who can modify web traffic between the customer and the merchant (to give one or the other an incorrect phone number).

Perhaps merchants could publish verification phone numbers in dead tree publications. Prospective customer could text that number to get a code and then verify that code matches what they get through the web site.

It means that a potential attacker must be able to intercept and modify SMS traffic as well as Internet traffic in order to mount a successful attack.

Going through all that trouble might be worth it if it only had to be done once, such as the initial exchange of BIP32 public keys, especially if there was some way to automate the process using a smartphone app.

[Mike Hearn]

You could have a merchant phone you and verify the payment address verbally, yes, but that assumes the criminals can't impersonate the merchant.

The root problem here is really hard - two parties who don't know each other and have never met want to communicate securely. The only thing the buyer knows is some fragment of an identity they {heard from a friend, found in a link, saw on a subway poster, etc}. Nobody knows a way to do this which doesn't involve some trusted third party issuing compact, unique, human readable identities.

[justusranvier]

I had an idea last fall for reforming the PGP web of trust into a general distributed identity system that would actually be easy and enjoyable for the average person to participate in, but I dropped it to focus on bitcoin...

Edit: http://bitcoinism.blogspot.com/2013/09/building-pgp-web-of-trust-that-people.html

[phelix]

Is my understanding correct that using the "payment protocol" will give away my IP address to the merchant?

[Gavin Andresen]

Is my understanding correct that using the "payment protocol" will give away my IP address to the merchant?

No, not if you use Tor.

Tor (or i2p or some other anonymizing proxy solution) is the only way to keep online merchants from figuring out your IP. After all, if you browse to their website without Tor, then your IP is sitting right there in their web server logs.

[phelix]

Is my understanding correct that using the "payment protocol" will give away my IP address to the merchant?

No, not if you use Tor.

Tor (or i2p or some other anonymizing proxy solution) is the only way to keep online merchants from figuring out your IP. After all, if you browse to their website without Tor, then your IP is sitting right there in their web server logs.

Thanks for explaining. Agreed, it's not an issue.

[wtfvanity]

Is anyone concerned about root authority, now that it is being discussed that NSA may have access to them with sealed orders like the Verizon records?

[kjj]

Is anyone concerned about root authority, now that it is being discussed that NSA may have access to them with sealed orders like the Verizon records?

That has been a concern since before day 1.

The problem is that despite SSL's many, many, many flaws, it is still vastly superior to everything else.

[Peter Todd]

Is anyone concerned about root authority, now that it is being discussed that NSA may have access to them with sealed orders like the Verizon records?

While no guarantee, the entire process by which the DNSSEC root authority was signed was filmed and is publicly available: http://www.youtube.com/watch?v=b9j-sfP9GUU

There's reams of documentation and video publicly available on ICANN's site, although that's still only the root keys, not the registrar keys.

[Mike Hearn]

In fact I cover this in my new payment protocol FAQ:

https://bitcointalk.org/index.php?topic=300809.0

[wtfvanity]

In fact I cover this in my new payment protocol FAQ:

https://bitcointalk.org/index.php?topic=300809.0

Thanks Mike. You posted that shortly after I raised my question. Good read though. I guess the part that I think you could go into more, is if, NSA has access to the root key, how does that effect Bitcoin's implementation of invoicing? Would that give them enough authority to spoof an invoice request? They wouldn't have access to any keys to make a transaction, but they could potentially be that MITM attack, no?

[Mike Hearn]

There isn't any root key in the X.509 PKI.

Each CA has a private key that can be used to create certificates. If a government were to steal that key they could currently make bogus certs as if they were that CA, but that's being fixed via the certificate transparency effort. Although the government could still make bogus certs, they'd have to do so in a visible and public way which eliminates the value of doing so tremendously.

CT is a lot of work and a big upgrade, but it's being funded by Google and will be implemented in Chrome. At least one CA already signed up, even though the code isn't even finished yet.

[CIYAM]

I think anything that Google (MS or any other such company) suggests would not be acceptable by anyone (apart from those that of course work for Google, MS, etc.).

We need a system that has *no ties* to any large corporation or we have nothing that can be trusted at all.

[Peter Todd]

I think anything that Google (MS or any other such company) suggests would not be acceptable by anyone (apart from those that of course work for Google, MS, etc.).

We need a system that has *no ties* to any large corporation or we have nothing that can be trusted at all.

Meh, you already trust SSL whenever you copy a Bitcoin address off of a SSL-protected website, so the payment protocol is a strict improvement on that situation.

The enemy of better is perfect.

[CIYAM]

Meh, you already trust SSL whenever you copy a Bitcoin address off of a SSL-protected website, so the payment protocol is a strict improvement on that situation.

The enemy of better is perfect.

Sure but I would not use SSL for anything I really cared about (if it really mattered I would trust GPG).

I think the payment protocol idea itself is fine but we do need to have our eyes wide open when it comes to SSL.

[Peter Todd]

Meh, you already trust SSL whenever you copy a Bitcoin address off of a SSL-protected website, so the payment protocol is a strict improvement on that situation.

The enemy of better is perfect.

Sure but I would not use SSL for anything I really cared about (if it really mattered I would trust GPG).

I think the payment protocol idea itself is fine but we do need to have our eyes wide open when it comes to SSL.

Yes, and if you are using something else, then use it - other ways of making Bitcoin transactions aren't going away. (although some poorly-written wallet software and Bitcoin libraries still haven't implemented P2SH addresses, which makes those other ways a bit inconvenient at times)

[Mike Hearn]

Certificate transparency is not a "suggestion", it's actual working code with an open specification that real CA's have started signing up to.

If you think it's somehow inherently untrustworthy because a bunch of rich guys decided to fund its development, then I wonder if you're going to stop using Bitcoin as the number of developers working for a salary goes up?

[CIYAM]

If you think it's somehow inherently untrustworthy because a bunch of rich guys decided to fund its development, then I wonder if you're going to stop using Bitcoin as the number of developers working for a salary goes up?

I think Google, Microsoft and others have *proven* themselves to be inherently untrustworthy and yes I do think it will be a concern for the future of Bitcoin if say the NSA starts making decisions about future security aspects.

[User705]

Doesn't this introduce liability issues?  I mean if there is a central authority claiming to authenticate one entity to another and someone fakes a certificate as is certainly possible since its just ssl overlay and gets away with coins wouldn't they become liable?

[Boussac]

If a webshop using a deterministic wallet makes its master public key public (as it should), then a shopper's wallet app can verify that the payment address associated with her invoice belongs to the merchant's wallet.
E.g a merchant could publish its master public key on its web site and on social networks: a bitcoin wallet app could double check or triple check the master public key against the payment address before making any payment.
No need for a CA.
I dvelopped two apps to demonstrate this use case (those are RoR apps that I intend to open source when I fidn the time to do so):
the webshop is deployed on microbitcoin.net and the address verification app (still in beta) is on bitcoinrad.io.
You can try out bitcoinrad.io with your own electrum master public key and addresses.
The bitcoinrad.io type service should be duplicated so that multiple (decentralized) verification sources are available to merchants using deterministic wallets.
Multiple verification sources, possibly exposing a unified API, would greatly reduce the risks of a MITM attack.

[Mike Hearn]

Re: liability - maybe. That's why CA's try their hardest to prevent people from faking their certs, and charge money for issuing one (helps pay for liability insurance and lawyers).

"Faking" here really means getting them to issue a cert incorrectly or stealing their private key, as you can't fake a digital signature. If you can perform identity theft then you might be able to get a cert issued incorrectly though, and cert transparency is meant to help address that.

[callem]

Are there any restrictions on a payment request (signed or unsigned) being modified by the payor before submitting the transaction?

A couple of obvious instances would be:
1. "Here's the transaction for the restaurant meal, your request plus a 20% tip" 
2. "Here's the payment for invoice #12345, minus the credit note #34567 from 2 months ago"

(sorry if the answer is obvious, just want to make sure).

[Peter Todd]

Are there any restrictions on a payment request (signed or unsigned) being modified by the payor before submitting the transaction?

A couple of obvious instances would be:
1. "Here's the transaction for the restaurant meal, your request plus a 20% tip" 
2. "Here's the payment for invoice #12345, minus the credit note #34567 from 2 months ago"

(sorry if the answer is obvious, just want to make sure).

There's no mechanism in the protocol for those modifications to be communicated back to the payee.

[callem]

Are there any restrictions on a payment request (signed or unsigned) being modified by the payor before submitting the transaction?

A couple of obvious instances would be:
1. "Here's the transaction for the restaurant meal, your request plus a 20% tip"  
2. "Here's the payment for invoice #12345, minus the credit note #34567 from 2 months ago"

(sorry if the answer is obvious, just want to make sure).

There's no mechanism in the protocol for those modifications to be communicated back to the payee.

Really? It seems like a significant limitation/oversight if this is intended to be widely adopted in the real world.

Some mechanism for including a (non blockchain-embedded) message would be very useful. In fact, it's difficult to imagine a payment service or protocol (Paypal, etc.) being without that functionality. It would also make multiple payments to the same address much less ambiguous if that was desired for any reason: i.e. a supplier may choose to have each customer send funds to an address assigned to them specifically, or for ongoing subscription payments, etc.... in addition to the examples above.

[Peter Todd]

Really? It seems like a significant limitation/oversight if this is intended to be widely adopted in the real world.

Some mechanism for including a (non blockchain-embedded) message would be very useful. In fact, it's difficult to imagine a payment service or protocol (Paypal, etc.) being without that functionality. It would also make multiple payments to the same address much less ambiguous if that was desired for any reason: i.e. a supplier may choose to have each customer send funds to an address assigned to them specifically, or for ongoing subscription payments, etc.... in addition to the examples above.

The payment protocol is extensible; this is just version 1.0 (edit: though as mike points out if all you want is an informational message, you can do that - it's renegotiating the payment as the op asked that can't be done. also don't reuse addresses)

The reason we need the payment protocol is for security for multi-signature wallets first and foremost; getting a reasonable first version implemented without bloating it with lots of non-essential features is what's most important right now.

[Mike Hearn]

You can actually put a message into the payment submission:

https://en.bitcoin.it/wiki/BIP_0070#PaymentACK

Please read the spec before asking questions about what it can do - this will help us find out if the spec is clear enough.

[callem]

You can actually put a message into the payment submission:

https://en.bitcoin.it/wiki/BIP_0070#PaymentACK

Please read the spec before asking questions about what it can do - this will help us find out if the spec is clear enough.

Thanks Mike for clarifying this. That's what I gathered from Gavin's comments about sending a 'memo'. My initial inquiry was more about changing the output value than adding a memo .. and YES, it is obvious from the spec. My bad:

 

message Payment {
        optional bytes merchant_data = 1;
        repeated bytes transactions = 2;
        repeated Output refund_to = 3;
        optional string memo = 4;
    }

[callem]

Now that we have the memo thing out of the way, I'm still a little unclear on my initial question about the ability to modify the tx output amount(s) of a payment (my examples were the common practices of adding a tip at a restaurant, and deducting a credit note amount from an invoice payment request).

The spec refers to "fully pay", "pay in full", "satisfy conditions of payment" etc. It seems that the client and/or merchant server will be assumed(?)/expected(?) to enforce this somehow. The spec. could be made more clear as to if/when exceptions may be optionally allowed by either the client (wallet) or the server.

...
transactions   One or more valid, signed Bitcoin transactions that fully pay the PaymentRequest
...
If the customer authorizes payment, then the Bitcoin client:
Creates and signs one or more transactions that satisfy (pay in full) PaymentDetails.outputs
...
When the merchant's server receives the Payment message, it must determine whether or not the transactions satisfy conditions of payment. If and only if they do, if should broadcast the transaction(s) on the Bitcoin p2p network.

[Mike Hearn]

I believe most implementations will just wait until the balance of the requested scripts is higher than an amount, but rejecting a transaction that isn't formatted according to what was requested isn't unreasonable.

I did suggest some language around how zero-valued outputs are handled that had tipping in mind, but I think for v1 we punted on it (don't recall exactly). We need to ship this thing, everything else is secondary.

[dillpicklechips]

Is there plans for adding colored coins support? As a merchant I could ask the customer if they support colored coins and ask for an address where to send them. I could then send the colored coins with along with label for what they are. This could allow the merchant to do a rewards or points system that the customer could redeem later as a reward for using BTC.

[Cryddit]

There are good ways to secure a protocol from MITM attacks without resorting to a Central Authority for certificates.

For example, Rivest's Interlock Protocol can prevent a man in the middle from altering your communications while allowing you to communicate at all.  At most, he is then reduced to an eavesdropper or able to engage a denial-of-service attack.  Diffie & Hellman's key exchange protocol, if you are able to communicate with each other at all, allows you to generate a session key impenetrable to an eavesdropper.  The two can be combined, resulting in cutting out MITM attacks very effectively.  It reduces MITM to, at most, DoS.  And DoS can be done by people who aren't even in a position to eavesdrop.

Actually key agreement protocol is unnecessary; Bitcoin already has a solid public key infrastructure in that each and every coin is controlled by a public/private key pair.  If you know who owns a coin, you can compose a message to them and encrypt it using that coin's public key.

The Central Authority for HTTPS certificates was never necessary except that certain powers-that-be needed central points of control where keys could be taken, enabling covert eavesdropping, and securely linked to physical-world identities, enabling prosecution.  And also because some people needed to make the system work in such a way that they could make a profit off it, and if it were implemented as protocol, it would be free of charge. 

The functionality of protection from MITM attacks could be far more effectively and securely implemented simply by using protocol between browsers.  For Free.  Essentially, the CA system is still open to insider attacks.  It depends on keys held by people whose secrets the keys are not protecting.  Worse, those key holders have identities known to the public, and are therefore  subject to theft, bribery, extortion, blackmail, court orders, security letters, gag orders, etc. 

[callem]

Recent revelations have shown (Snowden, et al.) that any SSL communication should be considered a three way conversation. As in you, me and the [three letter agency of your choice].

Do we really want CA support hard coded into the client? Worth some thought.

[piotr_n]

Do we really want CA support hard coded into the client? Worth some thought.

No we don't, but the core dev team obviously does, since they have paralyzed the bitcoin-qt development for almost a year already, just to give the bitcoin community this great new feature, that no sane person is going to use anyway because of the reasons that are obvious to everyone with a working brain.

Good job, guys!
How much longer are you going to be busy with this useless crap?

[jgarzik]

It is difficult to take this complaint seriously, lacking similar protests for people to stop using SSL + existing CAs when visiting bitcoin websites.

A certain user class is already using certificates and digital signatures.

[piotr_n]

I just don't understand what this SSL based payment processing has to do with bitcoin itself.
For me, and I am an active bitcoin user who uses bitcoins on daily basis, it is a waste of time at best.
Only big corporations will be using such a payment protocol, and since when we care about them?
Big corporations have enough money to invent their own payment protocols, on top of the already existing bitcoin client - which IMHO is exactly the place where a payment protocols should be, definitely not in the core where you are putting it now.

Mike - it is at least clear that he works for Google and his employer has a vast interest in putting hands on any new emerging IT, preferably driving its development into a direction that will make them lots of money in the future. That's BTW also a reason why they found Ripple interesting - because it is something that is supposed to be for bitcoin what fractional reserve system once was for gold; a great money maker.

Gavin - quite similar; he gets paid by "Bitcoin Foundation" - a cartel of a well known companies, that obviously want to comply with all possible NSA "standards and requirements". They don't want US gov to shut them down, so they will do everything to drive the development towards features that will make bitcoin payments "more transparent" and "NSA friendly". It's only logical.

But the rest of you, guys. If nobody pays you for doing this, then I can only ask, what is wrong with you?
Why aren't you working on increasing anonymity, performance, splitting wallet from the blockchain parser, making the core smaller and less dependent on other libs, thus more easy to audit?
Why the hell are you doing the opposite?

Do you really think Satoshi is proud of you today, seeing how you are handling further his great invention?
I don't think so, sirs.

[Cryddit]

It is also possible to use an SSL channel at the lowest level but then layer protocol security on top of it, so that even someone with the SSL keys and a priveleged position on the backbone still won't have an opportunity to eavesdrop or modify messages.   

This buys you everything SSL buys you (linkable identities / CA-level authentication) and yet, can still be a secure protocol even if SSL is compromised (in which case SSL wouldn't buy you anything, so no loss).  Also, protocol security can be used over TCP/IP or even UDP, without loss of anything else.  Note that UDP is enabled by default because any protocol that detects and corrects for MITM message modifications will also detect and correct for line noise; we don't actually need the TCP layer, let alone the SSL layer built on top of it, unless we want linkability to SSL-authenticated identities.

You'd need to ignore all the insecure payment processing crap and protocols that have been built up assuming that SSL is itself a secure channel, and build better ones.  No security model works if the assumptions it's built on aren't true.  But now that we know what we know about SSL, EVERYBODY needs better protocols to use over those channels, not just Bitcoin users.

[StarfishPrime]

I tend to agree with the general concensus on the other thread running here somewhere: That this sort of functionality should be added as a vendor-neutral API interface, rather than being hard-coded into bitcoinQT, which should remain free of third party dependencies/support.

With full respect to the coredev team, this "upgrade" to bitcoinQT seems mostly like a solution without a problem, and not a really great one at that.

BIP38 is an example of a useful proposal that's already well tested and providing real security for many users today (off line storage, etc) why not implement that?

[Carlton Banks]

With full respect to the coredev team, this "upgrade" to bitcoinQT seems mostly like a solution without a problem, and not a really great one at that.plement that?

Indeed, the premise of this feature was that newbie or average users wouldn't want to handle the weird geekiness of the public key format, but what happens when these same users want to use the network to send money to each other? We're not all going to get issued with CA certificates any time soon, and probably a good thing too considering the flaws in the present system that everybody acknowledges.

I'm just glad that the Payments Protocol has been designed with modularity in mind, and that not all core development members have been working on it, as it seems that X. 509 part will croak eventually anyway.

I would prefer to pay with fiat than to sacrifice the privacy of my public keys, in all honesty. The trade off just isn't worth it.

[piotr_n]

I would prefer to pay with fiat than to sacrifice the privacy of my public keys, in all honesty. The trade off just isn't worth it.

Of course - who wouldn't?
What good would bitcoin be for, if you had to register yourself at a CA, before receiving any payment.
It totally contradicts the very principle behind bitcoin's existence.

Let's be realistic; already today, when we do any payment to a webshop, or whatever other commerce, we get a SSL signed payment address anyway, because every single one of these web services uses SSL.
And when we pay to an individual? Well, that's something that is definitely worth addressing, but not by "send your ID to CA and they will tell me that it's you". And definitely it is not so high priority to lock core devs in it for a year - are you out of your mind?

[Carlton Banks]

I would prefer to pay with fiat than to sacrifice the privacy of my public keys, in all honesty. The trade off just isn't worth it.

Of course - who wouldn't?
What good would bitcoin be for, if you had to register yourself at a CA, before receiving any payment.
It totally contradicts the very principle behind bitcoin's existence.

Let's be realistic; already today, when we do any payment to a webshop, or whatever other commerce, we get a SSL signed payment address anyway, because every single one of these web services uses SSL.
And when we pay to an individual? Well, that's something that is definitely worth addressing, but not by "send your ID to CA and they will tell me that it's you..." - are you out of your mind?

Well, there will always be a free market for cryptocurrencies under the Satoshi model, not to mention a free market for Bitcoin clients. And if people ever feel like Bitcoin development isn't sharing their ideals any more, the friction of dumping BTC for TrueSatoshi, or whatever it may be, will be way lower. As long as the catalyst isn't the removal of the ability to pay directly with a public key.

The mining pool operators will be the ones to watch, as they in fact run the most decisive nodes on the network, and there are less than a dozen.

[piotr_n]

Well, there will always be a free market for cryptocurrencies under the Satoshi model, not to mention a free market for Bitcoin clients. And if people ever feel like Bitcoin development isn't sharing their ideals any more, the friction of dumping BTC for TrueSatoshi, or whatever it may be, will be way lower. As long as the catalyst isn't the removal of the ability to pay directly with a public key.

The mining pool operators will be the ones to watch, as they in fact run the most decisive nodes on the network, and there are less than a dozen.

Of course - luckily for us.

Nevertheless this topic is about "Invoices/Payments/Receipts proposal discussion" - and we are just providing our feedback..

[metacoin]

Personally I wouldn't use a client that had anything to do with a Certificate Authority.

I believe that Bitcoin should not be in any way reliant on a 3rd party "authority". The advantages of Bitcoin are enough that it isn't worth sacrificing independence for the sake of those who refuse to adapt.

[Carlton Banks]

So, who's going to strip the Payment Protocol out of the release it gets into and distribute the binary? Until I see how this plays out longer term, I'm buying dl'ing.

[justusranvier]

So, who's going to strip the Payment Protocol out of the release it gets into and distribute the binary? Until I see how this plays out longer term, I'm buying dl'ing.

Just don't use Bitcoin-Qt. Armory is a better wallet client anyway.

[Carlton Banks]

So, who's going to strip the Payment Protocol out of the release it gets into and distribute the binary? Until I see how this plays out longer term, I'm buying dl'ing.

Just don't use Bitcoin-Qt. Armory is a better wallet client anyway.

Except that (as I'm sure you know), Armory interfaces with the network via RPC calls to the Satoshi client. And I know it's not going to be utilising any aspect of the Satoshi client that the PP affects, how could it possibly do so when it's not yet functional in Satoshi itself? The mining nodes are never going to need the payments protocol code anyway, so there is actually a good reason from a technical standpoint for two editions to exist (as well as the holdings privacy standpoint I'm advocating).


MultiBit? I can't trust a Java based client with my mining reserves. I'd actually prefer that etotheipi re-writes the python based parts of Armory in C++, but I understand the python run-time isn't as vulnerable as that of Java, so it's not too uncomfortable. And I also understand that at least some of the time saving algorithmic expression that python has over C++ has been added to the newer standard of C++, so it's more possible than it once was, given that Armory is now a full-time project. Maybe not though, I don't claim to have anything like an insiders understanding of this sort of thing.

[ShadowOfHarbringer]

I would prefer to pay with fiat than to sacrifice the privacy of my public keys, in all honesty. The trade off just isn't worth it.

Of course - who wouldn't?
What good would bitcoin be for, if you had to register yourself at a CA, before receiving any payment.
It totally contradicts the very principle behind bitcoin's existence.

+1000

Well, i never thought i would agree with you on something, but it just happened.

Adding any kind of "trusted" "root" servers to Bitcoin core totally negates the decentralized nature of the currency. What if in some time, everybody starts to build their buisness solutions of top of this OBVIOUSLY BROKEN centralized scheme and 20 years in the future Bitcoin will turn into another shit like central banks because certificate authorities will control who can and who can't do Bitcoin-related buisness ?

I tend to agree with the general concensus on the other thread running here somewhere: That this sort of functionality should be added as a vendor-neutral API interface, rather than being hard-coded into bitcoinQT, which should remain free of third party dependencies/support.
With full respect to the coredev team, this "upgrade" to bitcoinQT seems mostly like a solution without a problem, and not a really great one at that.

+ 1000

Adding "trusted" certificates of CENTRALIZED entities into Bitcoin code ? I mean *WTF* ?

[justusranvier]

Except that (as I'm sure you know), Armory interfaces with the network via RPC calls to the Satoshi client.

Armory won't need the Satoshi client forever. If it's not already possible to make Armory worth with btcd it will be soon.

[ShadowOfHarbringer]

SERIOUSLY, GUYS.

One question:

Devs, did you anticipate that in the future their new CA-Based centralized protocol may become the standard of doing Bitcoin payments ?
And then NSA/USA Govt/World govt/whatever can actually seize the CA and decide who can do business with whom ?

I guess that by the time I'm writing this, governments of the world already figured out that Bitcoin cannot be stopped using the easy "conventional" methods. So they may(or rather WILL) try to embrace, extend and extinguish Bitcoin. 1. First by making it centralized, 2. second by promoting the centralized way of doing transactions, 3. third attacking the single point of failure, thus ending it.

You are just in the process of helping them with the step 2.

[piotr_n]

Devs, did you anticipate that in the future their new CA-Based centralized protocol may become the standard of doing Bitcoin payments ?

nee - I would not worry about this; it won't happen, because people (bitcoin community) won't buy it.
still it's a shame that the precious dev resources are being so much wasted.
IMHO if someone had an intention to sabotage the actual useful development of the bitcoin software, he could not have done a better job.

[Carlton Banks]

SERIOUSLY, GUYS.

One question:

Devs, did you anticipate that in the future their new CA-Based centralized protocol may become the standard of doing Bitcoin payments ?
And then NSA/USA Govt/World govt/whatever can actually seize the CA and decide who can do business with whom ?

I guess that by the time I'm writing this, governments of the world already figured out that Bitcoin cannot be stopped using the easy "conventional" methods. So they may(or rather WILL) try to embrace, extend and extinguish Bitcoin. First by making it centralized, second by promoting the centralized way of doing transactions, third attacking the single point of failure, thus ending it.

You are just in the process of helping them with the step 2).

Create another subset Satoshi distribution sans Payment Protocol, you're already doing it with your no forced Tx fee distro. Then everybody will have an off the shelf alternative, instead of the lazy route that they could potentially take. If enough objection develops towards the Payments Protocol, it will be dead in the water before potential arguments in favour of removing direct public key payments can even begin.

[Gavin Andresen]

SERIOUSLY, SHADOWOFHARBINGER:

I LOVE IT WHEN PEOPLE SHOUT AT ME! IT IS A GREAT WAY OF MAKING ME REALIZE THE FOLLY OF MY WAYS, GIVES ME WARM FUZZIES, AND MAKES ME WANT TO COME BACK TO THESE WONDERFUL FORUMS AGAIN AND AGAIN!

[Carlton Banks]

SERIOUSLY, SHADOWOFHARBINGER:

I LOVE IT WHEN PEOPLE SHOUT AT ME! IT IS A GREAT WAY OF MAKING ME REALIZE THE FOLLY OF MY WAYS, GIVES ME WARM FUZZIES, AND MAKES ME WANT TO COME BACK TO THESE WONDERFUL FORUMS AGAIN AND AGAIN!

Payment Protocol could be good, I do understand it helps with MITM attacks. We're just not too keen on the MITM we're in turn volunteering information to being able to identify how much other BTC we have and where else we spend it. A legitimate concern.

[ShadowOfHarbringer]

SERIOUSLY, SHADOWOFHARBINGER:

I LOVE IT WHEN PEOPLE SHOUT AT ME! IT IS A GREAT WAY OF MAKING ME REALIZE THE FOLLY OF MY WAYS, GIVES ME WARM FUZZIES, AND MAKES ME WANT TO COME BACK TO THESE WONDERFUL FORUMS AGAIN AND AGAIN!

I'M GLAD YOU LOVE IT, I WORKED SO HARD ON IT !!!!!1111111oneone

----
But seriously, i do love to emphase important parts of my posts.

[Carlton Banks]

Sorry for butting in, I don't know enough about the inner workings of Bitcoin to contribute to this thread but the questions asked by ShadowOfHarbringer are what's worrying me too. Is this introducing a single point of faliure?

Not a failure point, but an authority point. And it's not a point of absolute authority, it's conditional (conditional on whether or not you're using the Payment Protocol).

The concern is that conditional gently gets transformed into absolute. I think we'd all prefer a trustless 2 party solution to MITM attacks to this proposed trust-based 3 party solution.

[StarfishPrime]

From what I've seen there's no requirement to use the new protocol, and even when using them the use of CA certificates for signing is optional anyway, so some of the concerns being discussed here might not be a real problem.

Some of us do however have an issue with introducing third-party support/reliance of any kind into a system that was explicitly designed to be free of any centralized dependencies.

Only time will tell if anyone outside of a few payment providers, etc. actually use the protocol, but it could eventually evolve into something useful, with or without CA support. The core devs deserve credit for at least attempting to add this functionality, there's always bound to be some push back regarding feature implementation.

[Carlton Banks]

From what I've seen there's no requirement to use the new protocol, and even when using them the use of CA certificates for signing is optional anyway, so some of the concerns being discussed here might not be a real problem.

Yes, but how many of this target audience of newcomers are actually going to understand the implications of sending a CA signed payment request? Perhaps more than previously would considering the current political debates around privacy, but the whole cryptocurrency concept has more than enough obstacles to comprehension as it is, and that's despite the current clients being pretty simplistic in their layout and operational dialogs. Doesn't stop the rabbit in the headlights look on the face of the uneasy, I have seen this IRL.

[...]but it could eventually evolve into something useful, with or without CA support. The core devs deserve credit for at least attempting to add this functionality, [...]

This I can wholeheartedly agree with. The messaging aspect of the Payments Protocol is vital, we should be accepting any feature that reduces people using the blockchain to store anything other than BTC transactions. I can't help thinking that the MITM problem should be dealt with differently, especially considering:

1) It's not a widespread problem right now (or even at all? are there any recorded cases of public keys being transposed to the key of an interloper?)

2) There are low tech solutions that webmerchants could use that would be non-standard. A standard is a single point of failure in a way, as it provides a uniform way to exploit it, no matter the software the sender and receiver are using. Attacks on bespoke methods of transmitting public keys to the sender are less likely, there'd have to be consistently attractive tx sums to be worthwhile.

[ShadowOfHarbringer]

@Gavin Andresen

Several questions:

1. In the post-NSA-snowden era, are you sure it is wise to participate in creation of a centralized mechanism, which governments can easily control ? Why would we trust *any* CA ?
2. What would Satoshi think of this ? Isn't adding a centralized stuff to a decentralized-by-design system kind of senseless ?
3. How do you think will the tinfoil-hatted-extremely-paranoid Bitcoin community react, when they realize you added a broken by design schema to the most important Bitcoin app ?
4. What problem exactly  are you trying to solve with this solution ? I don't see Bitpay, Inpay, Coinbase or others complain that they cannot do business using Bitcoin without this feature ?
Isn't the invoicing possible to do through third party app or in-browser using SSL ?
5. Why add such a non-critical feature to the core client ? Isn't it supposed to be as clean, fast and efficient as possible without unnecessary bloat ?

[Carlton Banks]

...
The concern is that conditional gently gets transformed into absolute. I think we'd all prefer a trustless 2 party solution to MITM attacks to this proposed trust-based 3 party solution.

Thanks. The chance of an extra becoming a requirement is worrying, it sounds a lot like MS's embrace, extend, destroy practices. Iirc SSL was just a currently working solution and that layer could be replaced or other solutions added to it at any stage later, is that right and if so does it still work that way? I don't know what 2 party trustless system is proposed but it sounds like the obvious answer, guess I have some reading to do

There are no documented plans to make the Payment Protocol a required way to pay, it would require significant additional changes to the design. It does introduce a foundation into which such a change could be made, though.

There is no formal proposal for a trustless public key transmittance that I'm aware of, but it could be done in a variety of simple ways without the need for CA verification of the message. I see no good reason why (on balance) self signed messages couldn't work, for instance. It's not such a bad trade off to having your public keys matched to your real world identity, I'd live with that.

In fact, if (more like when) we do end up increasing the 1Mb block size limit (something I can agree is ultimately necessary), why not use the storage of merchant certificates on the chain a part of the justification for it? It's the single exception I would consider to wanting to prevent the blockchain being used for non-transaction information.

[ShadowOfHarbringer]

@Gavin Andresen

I'm not shouting anymore, but I am still humbly awaiting for your answers to my questions, please.

I am not in a hurry, however I am also afraid I won't receive them at all.

[Quetzalcoatl_]

@Gavin Andresen

Several questions:

1. In the post-NSA-snowden era, are you sure it is wise to participate in creation of a centralized mechanism, which governments can easily control ? Why would we trust *any* CA ?

This is not just a hypothetical concern. It is a known fact that not only the NSA, but hacker groups have copies of CA certs, which they use to perform MITM attacks against HTTPS. The CA model is insecure.

[Carlton Banks]

it sounds like its adding a messaging system that will need information other than transfers of funds to be passed.

Not necessarily a bad thing, it depends what the message is!

SatoshiDice is the classic example. They were using lots of single Satoshi transactions as a way of proving the validity of their bets. Blockchain space got gobbled, Bitcoin devs had to contemplate how to dissuade them from doing this. They weren't sending money for the purpose of someone else receiving that money, they were doing it as a way to send a message that had the effect of providing evidence of the trustworthiness of their betting system.  

Payments Protocol solves this problem, but also gives the person who draws up the payments request the option to have the message authenticated by a CA. This is where your own personal details might get associated with the public key you use to pay that person. In a webshop -> customer transaction, the webshop might include the product, and a confirmation of the Name & Address to deliver to. The information in the message is all under their control, and we now know this can be slurped by the CA, and in turn by our friends at the NSA.

There's no reason to assume the payment requester to disclose details that identify either you or your purchase items in the Payments Protocol message, this is not mandatory to the protocol (I hope!). Although, the merchant requesting payment should choose something useful to the user, and relevant to the transaction. Imagine buying from a webshop, confirming the order, being presented with a payment request message triggered in your Bitcoin client, and the message being completely or nearly blank! It would seem a little strange, you'd wonder if the Payment had been successfully attacked and you were sending your money to an attackers address (the attacker's method maybe didn't or couldn't copy the message into their spoof message).

And so there lies the rub, you can kind of assume that the more correct information about the transaction that the merchant includes, the more convinced the end user will be that they're accepting a request to pay from who it's supposed to be from. And hence the more information for the NSA to slurp.

[Cryddit]

Gweedo, I think you're being rude.

Until you're willing to put up time and effort developing code, don't harsh on someone who does.

That said, I don't think Bitcoin needs SSL for any security purpose, and should not rely on it for any security purpose.  If we need it at all, it's for purposes of making it easy for websites to accept bitcoin payments using a system they already know how to use and already have set up.  But I don't see how we can do that unless the communications are otherwise unsecured (ie, insecure), so I don't really think it's a good idea.

Short answer; I don't think you'll be able to order things directly from Amazon.com using Bitcoin until this is done.  But if we have it at all, I don't think you'll be able to order things from Amazon.com with any security greater than it provides now.  And, in fact, even less, because if you use it with a bank, credit card, etc, you can always reverse bogus charges.  With Bitcoin that isn't, and won't, be possible.  

Because Bitcoin has a higher security requirement in the first case, due to its non-repudiability, I don't think that SSL is adequate to secure Bitcoin payments.  It's okay for payments you can challenge or reverse, but it's not okay for Bitcoin.  The right answer is that Amazon.com and company need to man up and accept some genuinely secure protocols to process payments.

Bear

[al.matic]

For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you. I don't see the problem with this in restaurant/bar scenario.

[gweedo]

Gweedo, I think you're being rude.
Until you're willing to put up time and effort developing code, don't harsh on someone who does.

Wait so you agree Gavin should be rude to people that make him rich because they use bitcoins. Also since I working on startups and helping people get started in bitcoin I guess that isn't as good as people who write the reference client right? I work harder on bitcoin in a way to get more people involved instead of writing code, and just making myself rich. I am making the community richer.

[Carlton Banks]

For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you. I don't see the problem with this in restaurant/bar scenario.

Sounds like what I'd prefer.

Why not implement ZRTP as 2 party "trustless", then make a clear distinction between the two payment methods? I already trust Bitpay not to scam me, I have no problem with continuing to accept that risk at my end of the deal as a way to protect association of my public keys with my identity.

[al.matic]

For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you. I don't see the problem with this in restaurant/bar scenario.

Sounds like what I'd prefer.

Why not implement ZRTP as 2 party "trustless", then make a clear distinction between the two payment methods? I already trust Bitpay not to scam me, I have no problem with continuing to accept that risk at my end of the deal as a way to protect association of my public keys with my identity.

It is only useful if you have separate channel to verify the PIN/SAS (similar to Bluetooth pairing), like in the restaurant where you can visually verify it.

[Carlton Banks]

For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you. I don't see the problem with this in restaurant/bar scenario.

Sounds like what I'd prefer.

Why not implement ZRTP as 2 party "trustless", then make a clear distinction between the two payment methods? I already trust Bitpay not to scam me, I have no problem with continuing to accept that risk at my end of the deal as a way to protect association of my public keys with my identity.

It is only useful if you have separate channel to verify the PIN/SAS (similar to Bluetooth pairing), like in the restaurant where you can visually verify it.

I see. Well, the bricks and mortar businesses can at least prove that you're not subject to attacks that target key exchange as it happens (as in web transactions), but I guess we're trusting that said business hasn't had their wallet software compromised before the transaction is initiated.

[charleshoskinson]

Gavin you ok?

[super3]

SERIOUSLY, SHADOWOFHARBINGER:

I LOVE IT WHEN PEOPLE SHOUT AT ME! IT IS A GREAT WAY OF MAKING ME REALIZE THE FOLLY OF MY WAYS, GIVES ME WARM FUZZIES, AND MAKES ME WANT TO COME BACK TO THESE WONDERFUL FORUMS AGAIN AND AGAIN!

Go back to the foundation forums where everyone pays to kiss your feet. It is sad you can't address concerns of user of the client, that make the price $171 which makes you rich. Greedy Dev core members that is all they are, they do nothing to advance bitcoin.

This guy needs to be banned from the forums. Agree with Gavin or not he deserves your respect for the work he has put into the Bitcoin source. If you don't agree then write an alternate protocol spec yourself.

Can you show me where in the Bitcoin TOS were it says that Gavin must provide support for you?

[gmaxwell]

Why should I be banned cause I posted my opinions and they aren't what you want to hear?

Your incivility is going to scare off the actual technical people from responding on this forum. Already several of them don't, which I think is sad... relatively to the rest of the forum the technical sub-forum is mostly low rubbish.

Treating other people poorly has the effect of silencing their opinions here. It's possible to state just about any opinion without being excessively rude about it, but it seems is nearly impossible there to continue a conversation with some forum members while retaining a bit of human dignity.

Greedy Dev core members that is all they are, they do nothing to advance bitcoin.

Most of us are unpaid volunteers. Nothing I do with development makes me rich. This kind of ignorance just multiplies the offensiveness of your misplaced attacks.

FWIW, I didn't notice the attacks in this thread until someone reported-to-mod them because I had both Gweedo and ShadowOfHarbringer on ignore (though I've been considering removing the latter one lately). I strongly recommend everyone else use ignore aggressively, it can actually be pretty effective.  Even though I do ultimately end up clicking on much of what I've ignored, I find the extra clickthrough to be a good reminder that I've already written that poster's opinions off, and that I expect them to say some hurtful uninformed nonsense. It's less shocking when I find what I expect.

[super3]

Why should I be banned cause I posted my opinions and they aren't what you want to hear?

Your incivility is going to scare off the actual technical people from responding on this forum. Already several of them don't, which I think is sad... relatively to the rest of the forum the technical sub-forum is mostly low rubbish.

Treating other people poorly has the effect of silencing their opinions here. It's possible to state just about any opinion without being excessively rude about it, but it seems is nearly impossible there to continue a conversation with some forum members while retaining a bit of human dignity.

Greedy Dev core members that is all they are, they do nothing to advance bitcoin.

Most of us are unpaid volunteers. Nothing I do with development makes me rich. This kind of ignorance just multiplies the offensiveness of your misplaced attacks.

FWIW, I didn't notice the attacks in this thread until someone reported-to-mod them because I had both Gweedo and ShadowOfHarbringer on ignore (though I've been considering removing the latter one lately). I strongly recommend everyone else use ignore aggressively, it can actually be pretty effective.  Even though I do ultimately end up clicking on much of what I've ignored, I find the extra clickthrough to be a good reminder that I've already written that poster's opinions off, and that I expect them to say some hurtful uninformed nonsense. It's less shocking when I find what I expect.

Ignore seems like a good idea.  . Ha ha. I wish the open-source life was rich and glamorous. This is pretty accurate:

[super3]

Perhaps something good come of this. It might be worth bringing somebody on via the Foundation to help demystify some of the protocol spec, and the new developments. Demystifying some of the core stuff will lead to better discussion, and perhaps avoid misconceptions like these.

[gmaxwell]

I was clearly the one being rude in this thread [...] cause I don't bow down to Gavin and his almighty coding power does make me rude

Case in point.

I never really reply on this sub-forum

Yes, as I said, this subforum is generally lower in nonsense than the rest of the forum.

Again, please feel free to state concerns, but if you regularly cannot manage to do so in a polite, adult manner I'm going to have to ask you to leave.

Back to the thread subject, the limitations of the CA infrastructure have been extensively discussed both in this very thread and in the older bitcoin-development thread. I agree that the CA infrastructure is lame, but the world doesn't really have any good PKIs.

Fortunately, the way the payment protocol is designed the CA infrastructure being potentially weak isn't all that critical, as payment messages can be sent directly between buyers and sellers over whatever secure channel they already have. An evil CA cannot do as ShadowOfHarbringer suggests, it cannot prevent people from transacting with each other even inside the payment protocol (of course, the option of just not using it would work too), nor can it produce completely undetectable forgeries, nor could it impersonate anyone _at all_ unless it could already impersonate your secure communications channel. As far as I know the x.509 support does in the payment protocol is create a non-reputable signature for invoices for messages which you would be sending over a secure channel anyways.

If a community of users (now or in the future) prefers to send their payment messages with external PGP signing— because they don't even trust the CA infrastructure for non-repudiation—, they can do that instead of or in addition to the x.509 key signing.

[phelix]

There should have been a poll or something about the payment protocol and other features to go into the satoshi client much earlier. Now it is too late and we will vote the hard way.

In my opinion the CA system is bad and there are many things more important than the payment system. On the other hand side this is a great opportunity for Bitcoin to diversify into several independent client versions.

[gmaxwell]

There should have been a poll or something about the payment protocol.

Do you even have any idea what you're talking about here? What do you think the payment protocol does? Or, stated another way why the histrionics. If you don't like it, just don't use it. It doesn't do anything if you don't use it.

[ShadowOfHarbringer]

@Gavin

I tried to be as constructive & reasonable as possible (and no shouting/emphasing/whatever).
I am getting any of my questions answered ?

Once again, the questions were:

1. In the post-NSA-snowden era, are you sure it is wise to participate in creation of a centralized mechanism, which governments can easily control ? Why would we trust *any* CA ?
2. What would Satoshi think of this ? Isn't adding a centralized stuff to a decentralized-by-design system kind of senseless ?
3. How do you think will the tinfoil-hatted-extremely-paranoid Bitcoin community react, when they realize you added a broken by design schema to the most important Bitcoin app ?
4. What problem exactly  are you trying to solve with this solution ? I don't see Bitpay, Inpay, Coinbase or others complain that they cannot do business using Bitcoin without this feature ?
Isn't the invoicing possible to do through third party app or in-browser using SSL ?
5. Why add such a non-critical feature to the core client ? Isn't it supposed to be as clean, fast and efficient as possible without unnecessary bloat ?

[ShadowOfHarbringer]

Can somebody quote my questions, please ?

Gavin probably has me on his ignore list again. And i really want my questions answered.

[phelix]

There should have been a poll or something about the payment protocol.

Do you even have any idea what you're talking about here? What do you think the payment protocol does? Or, stated another way why the histrionics. If you don't like it, just don't use it. It doesn't do anything if you don't use it.

"express strong emotions with an impressionistic style" - hehe. I think Bitcoin has the potential to improve the world. That's why I sometimes become emotional about it.

The shouting was just to stay in the style of the thread My strong emotions against the payment protocol with CA system have somewhat faded as I also see the opportunity of diversification.

From what I understand the payment protocol is by far the largest single addition to the Bitcoin client ever (provocation or truth?). So it is a good idea to think about it twice.

It is very intransparent to me how the decision was made to include it. Is there some decision process? "For a BIP to become Active requires the mutual consent of the community." (https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals)  -  hmmmm.

From an engineering perspective imho the core client should be separated from the GUI and be kept as minimalistic as possible. Hopefully libcoin or libbitcoin will take this role.

Can somebody quote my questions, please ?

Gavin probably has me on his ignore list again. And i really want my questions answered.

@Gavin

I tried to be as constructive & reasonable as possible (and no shouting/emphasing/whatever).
I am getting any of my questions answered ?

I'll go for it  

1. In the post-NSA-snowden era, are you sure it is wise to participate in creation of a centralized mechanism, which governments can easily control ? Why would we trust *any* CA ?

No, but there is nothing better. (Namecoin is not ready yet )

2. What would Satoshi think of this ? Isn't adding a centralized stuff to a decentralized-by-design system kind of senseless ?

Payment protocol is similar to the original IP paying that Satoshi had in mind. If you don't want your IP to be known you have to use Tor anyway.

3. How do you think will the tinfoil-hatted-extremely-paranoid Bitcoin community react, when they realize you added a broken by design schema to the most important Bitcoin app ?

You don't have to use it. Though it complicates the main client even more! Also: Most people will probably swallow everything.

4. What problem exactly  are you trying to solve with this solution ? I don't see Bitpay, Inpay, Coinbase or others complain that they cannot do business using Bitcoin without this feature ?

Can't really answer this one... maybe we don't know what we are missing? I think GM wrote: Big merchants are longing for it.
edit: Address privacy
edit2: refunds, memos

Isn't the invoicing possible to do through third party app or in-browser using SSL ?
5. Why add such a non-critical feature to the core client ? Isn't it supposed to be as clean, fast and efficient as possible without unnecessary bloat ?

So everybody can use it and it will penetrate the system ? I tried but I can not find a proper argument.
edit: The Satoshi client is the reference client. It needs to include every important feature so it can be tested.

[Mike Hearn]

These questions come up repeatedly, which is why I wrote an FAQ:

    https://bitcointalk.org/index.php?topic=300809.0

Please do read it. I really think by now that a lot of you will never stop discussing this or going round in circles, but ONE LAST TIME

1. In the post-NSA-snowden era, are you sure it is wise to participate in creation of a centralized mechanism, which governments can easily control ? Why would we trust *any* CA ?

As I have pointed out multiple times now, what we learned from the Snowden leaks is that the PKI works. The NSA and friends are not engaged in mass forgery of SSL certificates or any other kind of bulk attack on the certificate system, because they are unable to. Instead they are building large databases of whatever private keys they can obtain, via whatever mechanisms can be found.

There was one documented case where a forged certificate appeared to have been used. It was deployed in highly targeted attacks of the kind of that can take out basically any real-world software system. If an entire team of professional hackers goes after you, the chances of them failing are pretty low. The CA targeted could easily have been hacked and never even knew.

But even with that caveat, the certificate transparency upgrade is designed to expose hacked or malicious CA's publicly.

What's more, after Lavabit were forced to give up their SSL private key to the FBI, GoDadddy (the epitome of corporatism) revoked the SSL cert because industry policies required them to. I don't see how the existing set of CA's could have done a better job really, given the enormous scale on which the entire system operates.

But ultimately X.509 does not dictate any particular set of root certs. If you don't like the current set, feel free to go ahead and set up the ShadowOfHarbringer wallet that trusts the ShadowOfHarbringer CA, then start handing out certificates yourself. You can adopt whatever policies you want, including running your CA over Tor and being entirely anonymous.

2. What would Satoshi think of this ? Isn't adding a centralized stuff to a decentralized-by-design system kind of senseless ?

Given that Bitcoin 0.1 had a payment protocol in it, and he ended up disabling it due to the lack of authentication allowing MITM attacks, I can only assume he'd be fine with bringing it back in a fixed form.

But at any rate, calling the PKI "centralised" vs Bitcoin "decentralised" is kind of amusing, given that there are more root CA's than mining pools.

3. How do you think will the tinfoil-hatted-extremely-paranoid Bitcoin community react, when they realize you added a broken by design schema to the most important Bitcoin app ?

We know already. A few people on bitcointalk will get upset because they have a kneejerk reaction that says "companies == bad". The fact that there's a free market with hundreds of competitors to choose from will be ignored, the fact that they have not proposed anything better will cause them to be ignored. Also calling it "broken by design" is a way to get an insta-ignore because it simply isn't "broken by design", it's exactly the same system used to encrypt the internet connections of over a billion people daily. Rage that it isn't perfect if you like, but it's what we've got.

4. What problem exactly  are you trying to solve with this solution ? I don't see Bitpay, Inpay, Coinbase or others complain that they cannot do business using Bitcoin without this feature ?

Go read my FAQ, it's covered very thoroughly there.

Isn't the invoicing possible to do through third party app or in-browser using SSL ?

You do realize that SSL is exactly the same system supported by the payment protocol, right? You can't use SSL without getting a certificate from this so-called "centralized" system. Realistically all online web shops are expected to use SSL already, as Jeff has pointed out many times. So it doesn't make much difference in the end.

5. Why add such a non-critical feature to the core client ? Isn't it supposed to be as clean, fast and efficient as possible without unnecessary bloat ?

You mean the core client that has a complete cross-platform GUI? It's a reference implementation. Even if not many people choose to use it, it gives developers something to test against and it allows us to verify that what we've designed actually works in the real world. Plus, there are plenty of users who may choose to run a full node wallet, anyone who has a computer switched on 24/7 is a good candidate for using Bitcoin-Qt. With this question, you're really asking "why does anyone bother to maintain the Bitcoin-Qt GUI at all?" which is a topic for another time.

[phelix]

Updated my answers above. I was close for 1. to 3. 

[gmaxwell]

But at any rate, calling the PKI "centralised" vs Bitcoin "decentralised" is kind of amusing, given that there are more root CA's than mining pools.

Do take care there, it's not the right comparison.  _Generally_ more CAs == more vulnerable because any CA can author a cert for any domain.

The greater point is that the payment protocol, while it can use x.509 doesn't have security that turns totally brittle even if the CA infrastructure misbehaves.

I'd like to see better support for non-SSL CA stuff, but the options are pretty limited. Doing other things, however, is not mutually exclusive with also supporting x.509.

[ShadowOfHarbringer]

Given that Bitcoin 0.1 had a payment protocol in it, and he ended up disabling it due to the lack of authentication allowing MITM attacks, I can only assume he'd be fine with bringing it back in a fixed form.

But there were several mentions of alternative ways to mitigate MITM problem in this very thread. Is none of them valid ? (I will cite the previous mentions from this thread):

- "Rivest's Interlock Protocol can prevent a man in the middle from altering your communications while allowing you to communicate at all.  At most, he is then reduced to an eavesdropper or able to engage a denial-of-service attack".
- "Bitcoin already has a solid public key infrastructure in that each and every coin is controlled by a public/private key pair.  If you know who owns a coin, you can compose a message to them and encrypt it using that coin's public key".
- "ZRTP: For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you".

But at any rate, calling the PKI "centralised" vs Bitcoin "decentralised" is kind of amusing, given that there are more root CA's than mining pools.

1. This is not an excuse. Just because some part of Bitcoin is already centralized, should we make it even more centralized thus breaking it even more ? Where's the logic in that ?

2. There are decentralized pools (p2pool and such), just not many people are currently using it.
So mining is or at least *can be* decentralized.

----
Other than above, no more questions for now.

[piotr_n]

You mean the core client that has a complete cross-platform GUI? It's a reference implementation. Even if not many people choose to use it, it gives developers something to test against and it allows us to verify that what we've designed actually works in the real world. Plus, there are plenty of users who may choose to run a full node wallet, anyone who has a computer switched on 24/7 is a good candidate for using Bitcoin-Qt. With this question, you're really asking "why does anyone bother to maintain the Bitcoin-Qt GUI at all?" which is a topic for another time.

Sure, that's a great point!
Since Bitcoin-Qt is already one big mess, with like almost 10 dependency libs, why not to turn it into even a bigger one, right?

You know what, you guys keep doing what you do and in the meantime I will just go to buy some popcorn...
It's gonna be useful when one day I finally get to watch the show, after the great "let's mess it all up even more" approach to the bitcoin development blows right up into your face.

[gmaxwell]

However, you would have to trust the merchant not to scam you".

None of that list of things actually do anything to address whats the payment protocol is doing.  x.509 is used to provide non-repudiation. The merchant tells you to pay 5 BTC to scriptpubkey X and they'll send you 10 widgets.  If the merchant scams you, you can show other people the signed invoice to convince them that the merchant really did make that agreement.  This means that none of the authentication for ephemeral keying things are actually useful (e.g. every one of your bulleted "alternatives"), nor is "have to trust the merchant not to scam you".

Since Bitcoin-Qt is already one big mess, with like almost 10 dependency libs, why not to turn it into even a bigger one, right?

Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.

[piotr_n]

Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.

It ties the implementation to openssl lib even more, making it harder (if not impossible) to remove openssl dependency in the future.
And openssl is a much bigger mess than the bitcoin at the current stage.

As we have learned recently NSA is probably actively trying to put backdoors wherever they can.
There are reasons to suspect that they had Google to put one into Android's RNG - also an open source code.
I would say that openssl would be one of their targets as well.
But it does not even need to be NSA - it can be just a bug.
All it takes is one bug that would allow to inject an exploit via a stack overflow (e.g. via a "broken" certificate) - and there goes all your money...

[ShadowOfHarbringer]

Since Bitcoin-Qt is already one big mess, with like almost 10 dependency libs, why not to turn it into even a bigger one, right?

Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.

Point taken, however this makes the possible ramifications even worse.
Because the implementation is so efficient and bloat-free, the risk of it becoming "standard" way of doing transactions in the future is even bigger.

So as I already wrote, 15 years from now it may not be possible to buy something using Bitcoin without trusting some CA, which are controlled by government.

But well, if using PKI stays optional, then I think I can live with that. Still, I hope most people will not be using this broken (as of today) functionality.

[ShadowOfHarbringer]

Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.

It ties the implementation to openssl lib even more, making it harder (if not impossible) to remove openssl dependency in the future.
And openssl is a much bigger mess the bitcoin at the current stage.

Actually there is an easy solution for it.
There is a minimal version of openssl targetted specifically for low-power embedded devices: cyassl

You are obviously a low-level programmer, so stop wasting time on the forums and perhaps make Bitcoin compatibile with it.

[piotr_n]

Linking a blockchain parser and (even worse) a wallet with any SSL lib is totally unnecessary and hugely irresponsible.

[Carlton Banks]

Benign interpretations of NSA's ability to abuse technology companies do not inspire confidence, it assumes we have all of the facts. You can't even assume that Edward Snowden has all the facts, and not all his revelations have been published yet.

It makes more sense to me to be prudent, given the above. We have no control over what content gets delivered in payment request messages; a merchant that didn't disclose personal details one week might suddenly change that the following week, and equally, a merchant that self signs messages might suddenly start using CA signed messages subsequently. The first awareness we end users of these merchants can discover their changing use of the Payments Protocol will be once the potential identity leak has already taken place, when it's too late to choose against it.

I won't be using this protocol until I can somehow be certain that I know what type of information will be in the Payments Protocol message and how the message will be delivered. I want to wear my all-body faraday-cage suit, thankyouverymuch.

[gmaxwell]

So as I already wrote, 15 years from now it may not be possible to buy something using Bitcoin without trusting some CA, which are controlled by government.

This just isn't how it works. You keep repeating this, but it's nonsensical.

You can transmit a payment request via whatever channel you want. If the x.509 non-repudiation signature in it is not secure you're still secured by whatever channel you're transmitting the data over.  If you have no secure channel at all, your problem is ... kinda out of scope for the payment requests.

What would you have the payment protocol do instead? All you've done so far is list completely inapplicable things that demonstrate that you don't understand what it does at all.

[Carlton Banks]

So as I already wrote, 15 years from now it may not be possible to buy something using Bitcoin without trusting some CA, which are controlled by government.

This just isn't how it works. You keep repeating this, but it's nonsensical.

You can transmit a payment request via whatever channel you want. If the x.509 non-repudiation signature in it is not secure you're still secured by whatever channel you're transmitting the data over.  If you have no secure channel at all, your problem is ... kinda out of scope for the payment requests.

All these "you"s are the person sending the payments request, are they not?

[gmaxwell]

All these "you"s are the person sending the payments request, are they not?

Yes, but if you're going to make the argument that you're being harmed by bitcoin-qt not restricting the freedom of others (an argument I've used here and there at times) I don't think it applies here.

The payment protocol doesn't provide its own secure channel. Thats not what x.509 for is used for in the payment protocol. The use of x.509 in the payment protocol is for non-repudiation (which many secure communications channels don't provide, including SSL).  Without a secure communications channel your privacy/security is hosed, and with one your usage of the payment protocol is secure from privacy or theft attacks even if the x.509 certs aren't secure.

In particular: It's primarily the sender the payment request which cares about the integrity of non-repudiation since if their non-repudiation is compromised customers will be able to convince others that the sender ripped them off.

If someone were making an argument about non-repudiation there might be something to discuss here, but no one appears to be talking about it.

[metacoin]

I think non-repudiation and other technical side-effects of integrating this protocol with CA signed messages are secondary to the issue at hand.

It is clear that some users of this forum are uncomfortable with the implementation of any solution introducing "centralized" or "trusted" 3rd parties into the Satoshi client. Even though there exists the option to never use this feature, the precedent that's being set is worrisome.

[piotr_n]

Isn't there something like a certificate revocation mechanism, that basically makes your PC to connect to the CA each time you want to use a cert?

[Carlton Banks]

All these "you"s are the person sending the payments request, are they not?

The use of x.509 in the payment protocol is for non-repudiation (which many secure communications channels don't provide, including SSL).

The repudiation issue highlights my concerns, not because websites can send unsolicited payment requests as you allude to, but because the requester is in control of what and how it is sent, not just the circumstances under which they send. You addressed this with an unqualified assertion that:

with one [a secure communications channel] your usage of the payment protocol is secure from privacy or theft attacks even if the x.509 certs aren't secure.

The qualitative security of this secure communications channel is not established my mere virtue of your description of it being suggestively absolute. This is just not a way to establish confidence that such statements are correct.

[Mike Hearn]

But there were several mentions of alternative ways to mitigate MITM problem in this very thread. Is none of them valid ? (I will cite the previous mentions from this thread):

- "Rivest's Interlock Protocol can prevent a man in the middle from altering your communications while allowing you to communicate at all.  At most, he is then reduced to an eavesdropper or able to engage a denial-of-service attack".
- "Bitcoin already has a solid public key infrastructure in that each and every coin is controlled by a public/private key pair.  If you know who owns a coin, you can compose a message to them and encrypt it using that coin's public key".
- "ZRTP: For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you".

Correct. None of them are valid. The interlock protocol does not do what the proposer thinks it does. Read the wikipedia page on it. It's a neat idea but it does not provide authentication. If there's a MITM sitting between you and the merchant, that MITM can rewrite traffic at will.

Bitcoin does not have a public key infrastructure. Using public keys does not mean the same thing as being a PKI. The "infrastructure" part means, how do you know the public key you have corresponds to the entity you think you're communicating with? The last part is tricky because "who you think you're communicating with" is a human, language-based concept, but cryptography works in terms of long random numbers. That's why we need certificates, to join those two worlds.

ZRTP is a method of triggering a Diffie-Hellman key exchange over a VoIP connection. It also isn't any form of authentication mechanism. If you use RedPhone or similar then the assumption is you read out the words you see on your screen, and that the other side checks that the words are the same. It's a neat idea based on the assumption is that a man-in-the-middle like the NSA can't forge your voice. It obviously doesn't work if the two parties don't already know what the other persons voice sounds like, so it's useless for securing a call to (say) a merchant, where you never talked to the salesperson before.

Like Gregory says, authentication and identity are just really hard problems. If you think you found a neat way to avoid all that overhead and hassle by browsing around on Wikipedia, you're probably wrong. Otherwise browser makers would be all over it by now.

[Mike Hearn]

Isn't there something like a certificate revocation mechanism, that basically makes your PC to connect to the CA each time you want to use a cert?

There's a standard protocol for that but AFAIK most systems don't use it, because it would make the revocation servers a central point of failure for the entire web. Typically certs that get revoked (it's rare) end up in a hard-coded list in the browser source code, so they can be checked locally.

Anyway, all the revocation server does is look up the cert in a list and say "yep! it's revoked!". Your browser is free to ignore this and some of them will let you do so. Revocation is really a non issue, CA's don't have any real power to take back a cert they issued beyond issuing a new statement saying, "whoops our bad". And normally this is not controversial (i.e. the SSL keys were stolen).

[piotr_n]

Anyway, all the revocation server does is look up the cert in a list and say "yep! it's revoked!". Your browser is free to ignore this and some of them will let you do so. Revocation is really a non issue, CA's don't have any real power to take back a cert they issued beyond issuing a new statement saying, "whoops our bad". And normally this is not controversial (i.e. the SSL keys were stolen).

Well, the issue is that when I ask the relocation server for a validity of a certain cert, it gets my IP.

[gmaxwell]

I think non-repudiation and other technical side-effects of integrating this protocol with CA signed messages are secondary to the issue at hand.

It's not a "technical side effect" it's what it does. If you don't care about non-repudiation then you don't need to care x.509 certificates in the payment protocol at all.

I'm struggling at trying to figure out your understanding of the payment protocol world. Are you under the impression that CAs would sign payment requests or control private keys? Thats not the case.  Only the requester and the requestee will see the payment requests.  If x.509 is used its used so that when you receive a payment request signed by a particular party your client (and anyone you show the payment request to) can use their certificate to validate that the request was signed by the right party.

The repudiation issue highlights my concerns, not because websites can send unsolicited payment requests as you allude to, but because the requester is in control of what and how it is sent, not just the circumstances under which they send. You addressed this with an unqualified assertion that:

I'm afraid I'm not following you here.

I addressed your concern by saying that it's the requester who controls how non-repudiation is provided and it's the requester who suffers if the non-repudiation is insecure. (Because the consequence of insecure non-repudiation is that a customer can produce cryptographic evidence that vendor ripped them off when they didn't really)

with one [a secure communications channel] your usage of the payment protocol is secure from privacy or theft attacks even if the x.509 certs aren't secure.

The qualitative security of this secure communications channel is not established my mere virtue of your description of it being suggestively absolute. This is just not a way to establish confidence that such statements are correct.

I have no comment on the "qualitative security" of the channel. It's entirely outside of the payment protocol, and you must have it even before a payment request can exist since you'll need to use it to negotiate the request (e.g. to do your shopping). The payment protocol doesn't provide it. Obvious readily available options today include: SSL (with its various limitations), http+tor onion URLs (though how you know you have the right site is another question), or exchanging gpg signed and encrypted payment requests.

Well, the issue is that when I ask the relocation server for a validity of a certain cert, it gets my IP.

AFAIK the payment protocol stuff does not support OCSP. I suspect that it probably shouldn't.

[Mike Hearn]

Well, the issue is that when I ask the relocation server for a validity of a certain cert, it gets my IP.

Yes, back when OCSP was designed, that didn't seem to be a big deal. Wallets don't use it anyway.

You could theoretically design a new version of OCSP that used oblivious set intersection, so although the server would see your IP, it would not see what your query was and thus would learn nothing beyond "someone behind this IP wanted to know the status of some certificate", which isn't a very useful piece of information to have. Or you could query via Tor, etc.

But as I said, revocation is rare. Browsers just have a hard-coded list, and wallets would probably end up the same, if they ever needed to revoke a cert for some reason. Then there's no server at all. Nice and simple.

[metacoin]

It's not a "technical side effect" it's what it does. If you don't care about non-repudiation then you don't need to care x.509 certificates in the payment protocol at all.

I'm struggling at trying to figure out your understanding of the payment protocol world. Are you under the impression that CAs would sign payment requests or control private keys? Thats not the case.  Only the requester and the requestee will see the payment requests.  If x.509 is used its used so that when you receive a payment request signed by a particular party your client (and anyone you show the payment request to) can use their certificate to validate that the request was signed by the right party.

It's a shame my first sentence didn't make any sense, because now I can't edit it. Damn. That's what I get for having 3 hours of sleep and coming in to work early...

I understand what the CA's role is and how the payment protocol works.

I was simply outlining the fact that despite there being a good use-case for this update as well as very small or no technical side-effects, people here are against setting the precedent of implementing code into Bitcoin which necessarily relies on a "trusted" 3rd party, even if that feature is optional.

[Mike Hearn]

It would be great if we could be purists about everything Bitcoin-related being totally zero trust, always, but there often isn't any technical way to do that. That's why we've ended up with centralised exchanges and so on. Some people even use third party wallets or payment processors.

If you believe you found a way to provide the features the PKI provides, except with no third parties, then go right ahead and show us how (in a new thread please). In the absence of such a breakthrough, we roll with the best we've got, which is a protocol in which anyone can sign keys for anyone else, along with a bunch of companies who do a professional job of it "out of the box".

[Carlton Banks]

The repudiation issue highlights my concerns, not because websites can send unsolicited payment requests as you allude to, but because the requester is in control of what and how it is sent, not just the circumstances under which they send. You addressed this with an unqualified assertion that:

I'm afraid I'm not following you here.

I addressed your concern by saying that it's the requester who controls how non-repudiation is provided and it's the requester who suffers if the non-repudiation is insecure. (Because the consequence of insecure non-repudiation is that a customer can produce cryptographic evidence that vendor ripped them off when they didn't really)

Well, you in fact addressed a different concern, one that I do not share. The notional concern that you are talking about is that of generating a proof that a given payment request was instantiated at the users end, such that a webmerchant cannot be accused of sending unsolicited requests to pay.


I will be agonisingly clear. The recipient of a payments request has no way of knowing that a request will be initiated, unless they analyse the code behind every event triggering piece of interface on every payments form on every website they use, every time they use it. The website can choose various ways of utilising the Payments Protocol, for instance using the CA or self-signing. This is all a consequence of the directionality of the request itself. Logically, it can only ever come from the requester. Payee will never request payment from themselves using the Payments Protocol.

Therefore I cannot know whether my personal details are to be signed by a CA until after the event has taken place. This is a concern. If you are saying that this is not a correct description, and that the message is communicated directly between user and merchant using SSL, then please be more explicit in confirming this.

If you're saying that the non-repudiative proof is the only information signed by the CA, then please be more explicit in confirming this.

with one [a secure communications channel] your usage of the payment protocol is secure from privacy or theft attacks even if the x.509 certs aren't secure.

The qualitative security of this secure communications channel is not established my mere virtue of your description of it being suggestively absolute. This is just not a way to establish confidence that such statements are correct.

I have no comment on the "qualitative security" of the channel.

Your own text (bolded) does not constitute such a comment?

[piotr_n]

Well, the issue is that when I ask the relocation server for a validity of a certain cert, it gets my IP.

Yes, back when OCSP was designed, that didn't seem to be a big deal. Wallets don't use it anyway.

Wallets don't use it, but isn't it like: wallets use OpenSSL that uses parent certificates installed in the OS, and it is the OpenSSL+OS that eventually asks the revocation server, without leaving the wallet any control over the actual process?

Sorry - it might be a stupid question, I don't know how it works, so just asking.

[ShadowOfHarbringer]

@gmaxwell, @Gavin Andresen, @Mike Hearn

I have run out of time and Brain-CPU cycles that can be used for this particular discussion, but judging by preliminary analysis of the topic I will (logically) assume you are right.

However i will be closely watching the run of events - If you were wrong, the truth will come out eventually.

[gmaxwell]

I will be agonisingly clear.

Your agonizing clarity is failing me. Sorry.

Therefore I cannot know whether my personal details are to be signed by a CA until after the event has taken place.

Huh. This appears to be word salad. There is no CA signing of any part of a payment request itself. None at all.

Why don't you try to explain to me step by step how you think it works and I'll point out where we are occupying alternative universes.

The only signed data is the request to pay, which is signed by the merchant (when used, it's optional), and the merchants own credentials which are part of a certificate he sends (if he is doing the optional signing).

The notional concern that you are talking about is that of generating a proof that a given payment request was instantiated at the users end, such that a webmerchant cannot be accused of sending unsolicited requests to pay.

No. I'm not talking about that at all.

Nothing stops you from sending unsolicited requests to pay.

A payment request is like an invoice, it forms an agreement "I'll send you the things listed on the payment request, if you pay this amount to these scriptpubkeys." the request can be signed so that you known who its from, and the signature is non-reputable so that if they don't make good on the deal you can show someone the payment request (and the transactions in the blockchain) as evidence that an agreement existed and you kept up your side of the deal.

[Peter Todd]

@gmaxwell, @Gavin Andresen, @Mike Hearn

I have run out of time and Brain-CPU cycles that can be used for this particular discussion, but judging by preliminary analysis of the topic I will (logically) assume you are right.

However i will be closely watching the run of events - If you were wrong, the truth will come out eventually.

Indeed, why bits of the truth will come out every time those sneaky devs do a git push! 

[Carlton Banks]

Therefore I cannot know whether my personal details are to be signed by a CA until after the event has taken place. This is a concern. If you are saying that this is not a correct description, and that the message is communicated directly between user and merchant using SSL, then please be more explicit in confirming this.

If you're saying that the non-repudiative proof is the only information signed by the CA, then please be more explicit in confirming this.

The only signed data is the request to pay, which is signed by the merchant (when used, it's optional), and the merchants own credentials which are part of a certificate he sends (if he is doing the optional signing).

There we are, that's better! If you want to answer the questions I have asked you, but in the form of a response to some other part of the dialog, then I can add the clarity myself by bringing the two together via cut and paste. It makes the conversation appear less intransigent to those that are following it. Why don't you want to answer the question directly? Why is it necessary to use personal sleights in your indirect answer?

The notional concern that you are talking about is that of generating a proof that a given payment request was instantiated at the users end, such that a webmerchant cannot be accused of sending unsolicited requests to pay.

No. I'm not talking about that at all.

Nothing stops you from sending unsolicited requests to pay.

A payment request is like an invoice, it forms an agreement "I'll send you the things listed on the payment request, if you pay this amount to these scriptpubkeys." the request can be signed so that you known who its from, and the signature is non-reputable so that if they don't make good on the deal you can show someone the payment request (and the transactions in the blockchain) as evidence that an agreement existed and you kept up your side of the deal.

My apologies, but you were incomplete in the way that you described your non-repudiative case, the subject of the repudiation was ambiguous. The above more than satisfys a complete description.

"Word salad" is an expression that's used to describe sentences that are logically and/or grammatically obtuse. My sentence made sense, but didn't describe a situation accurately. A little less haughty, please, you are being impolite.

[gmaxwell]

"Word salad" is an expression that's used to describe sentences that are logically and/or grammatically obtuse. My sentence made sense, but didn't describe a situation accurately. A little less haughty, please, you are being impolite.

I'm earnestly confused here— honest to god derpy look on my face confused—, I'm not trying to be snippy or anything at all like that. What you were saying made so little sense to me that I am concerned that I am mis-parsing your english. Your sentenced was, indeed, grammatically sound but ducks inverted my rutabaga.

Talking to someone confused about something, who is loudly angry as a result of the confusion, and is not following a clarification in part because of their anger can be a little frustrating to deal with... but in this case I'm not even frustrated because I can't actually figure out what y'all are thinking.  It's just mystifying to me.

I suspect that you have a very incorrect model in your head of how this stuff works, what the goal is, and what the consequences are... but I can't quite figure out how.  CAs seeing payment requests is basically a martian comment, as it has no semblance to how CAs work (much less how payment requests work), so I know something is wrong. I think I'm reasonably skilled with helping people through misunderstandings, but to do so I first need the start of an idea about what the confused person is thinking.

What I've found works when people have unclear complaints about Bitcoin is I suggest we roleplay.  You are the attacker out to harm people. Tell me what you'll do and what you'll get out of it, and I'll "defend" by telling you why your attack fails (or ask for clarifications for 'attacks' that are too non-specific).

[Carlton Banks]

I see. Your content seems rather concentrated around the way I'm saying something, or the internal workings of my mind, projecting emotional states onto me, or simply diverting from a coherent direction of discourse. I think we'll leave it there, you're appearing to be manipulative as well as impolite.

[Carlton Banks]

Sry for butting in again, how much will the affect the size of the block chain?

It won't. The messages are sent directly between the user and the merchant/service that is sending the payment requests, then stored locally, presumably by both the user and the merchant/service.

[johnyj]

Most of the devs I know have a habit: They must do something every day 

But I tends to believe, upon certain maturity level, the more you try to improve it, the worse it gets. Raised level of complexity will reduce the robustness and flexibility of the system and result in more compatibility problem and customer confusion. A good approach is to be always prepared, but do NOTHING when it is not necessary

Although nothing is done, this wait and prepare action is high valuable and worth getting paid

[gmaxwell]

Most of the devs I know have a habit: They must do something every day  

Payment protocol stuff was a business demanded feature, intended to address some of the problems that have cropped up with Bitcoin URLs. Its certainly not something sexy or exciting to work on.

[Diapolo]

Most of the devs I know have a habit: They must do something every day  

Payment protocol stuff was a business demanded feature, intended to address some of the problems that have cropped up with Bitcoin URLs. Its certainly not something sexy or exciting to work on.

Well, to me it's sexy to improve and work on the UI at least .

Dia

[gmaxwell]

Well, to me it's sexy to improve and work on the UI at least .

Okay sure, but it's well established that you're a weirdo: You use windows.

[Cryddit]

The interlock protocol does not do what the proposer thinks it does. Read the wikipedia page on it. It's a neat idea but it does not provide authentication. If there's a MITM sitting between you and the merchant, that MITM can rewrite traffic at will.

I'm the "proposer" and I know exactly what the interlock protocol does.  It flatly prevents a MITM from altering your communications with someone else while allowing you to communicate at all.  That is what I said, and that is what it does.

The MITM has to make an immediate choice when faced with Diffie-Hellman over Interlock Protocol.  He can either try to impersonate one or both sides of the conversation completely (refusing to allow you to communicate at all) or he can allow you to communicate, whereby he immediately loses the ability to eavesdrop on or interfere with your communication at all except by cutting it off.

Good protocol for secured channels works like this: 

1) All Protocol negotiation via Interlock protocol to ensure that you are talking to exactly one endpoint  (which may be an MITM, but if so will definitely *not* be communications from your intended endpoint as altered by an MITM).

2) Diffie-Hellman Key exchange via Interlock Protocol to establish a private key (thereby cutting out potential eavesdroppers).

3) Authentication via shared secret to make sure that the endpoint you are talking to is in fact the endpoint you want to be talking to, ie, not the MITM. 

Protocol security (steps one and two) secures the channel.  Authentication (step 3) is not addressed by securing the channel; it is addressed by a shared secret.  It might also be addressed by 509 certificates to the extent that people trust them. 

What I said about SSL is that we ought not rely solely on the keys in those certs for securing the channel.  SSL is a hybrid monster that conflates securing the channel with authentication, and they are two separate jobs. 

SSL, trusted third parties and all, is a better method than any zero-trust protocol for authentication between strangers.   Knowledge of the private key corresponding to the public key in an SSL certificate is not quite as good as a shared secret due to CA trust issues, but by definition you can't have a shared secret with a stranger, and it's a pretty good proxy for knowledge of a shared secret.  We can use it for that, and I'll have no objections.

But using SSL to secure the channel (ie, trusting the keys in those certs _and_nothing_else_ to prevent eavesdropping or alteration of messages in flight) is a method inferior to zero-trust protocols, and I *will* be upset if using SSL authentication reduces us to using SSL to secure the channel.

[johnyj]

Most of the devs I know have a habit: They must do something every day  

Payment protocol stuff was a business demanded feature, intended to address some of the problems that have cropped up with Bitcoin URLs. Its certainly not something sexy or exciting to work on.

IMO, bitcoin is mainly a monetary system with secure transaction function. As a monetary system designer, business oriented practice is a too low level of concern. FED will never care about what paypal or VISA is doing, that is many levels lower down the importance chain

The monetary policy of bitcoin has already been written into stone by Satoshi, but there are still many area to improve regarding the performance and reliability. Only the security part will bring a normal user lots of headache. I just heard that someone lost 150 coins in an offline wallet with a 20 character strong password and he doesn't understand at all what went wrong

[gmaxwell]

I'm the "proposer" and I know exactly what the interlock protocol does.  It flatly prevents a MITM from altering your communications with someone else while allowing you to communicate at all.  That is what I said, and that is what it does.

There is no need to use the interlock protocol when you have an authentication method. You can just use your authentication method to authenticate the DH ephemeral exchange (or some resulting derived session ID) and then you know there is no MITM. If you do not have an authentication method the interlock protocol generally does you no good.

Do you have any idea what the payment protocol is or has the name confused you?  It's format for (optionally cryptographically signed) invoices and receipts. It's not necessarily used interactively, e.g. you can send payment requests as email attachments.

I *will* be upset if using SSL authentication reduces us to using SSL to secure the channel.

The discussion in this thread is about the fact that the payment requests can x.509 certificates to cryptographically sign their content. "SSL authentication" is completely out of left field here.

I *will* be upset if you continue to use that tone in this discussion.

I just heard that someone lost 150 coins in an offline wallet with a 20 character strong password and he doesn't understand at all what went wrong

It so obvious to you when you get to gloat over other people's losses, but I've yet to see you speak up in a thread where people are advancing "brainwallets" and say "no! don't do it!".

[ShadowOfHarbringer]

@gmaxwell, @Gavin Andresen, @Mike Hearn

I have run out of time and Brain-CPU cycles that can be used for this particular discussion, but judging by preliminary analysis of the topic I will (logically) assume you are right.

However i will be closely watching the run of events - If you were wrong, the truth will come out eventually.

Indeed, why bits of the truth will come out every time those sneaky devs do a git push! 

This is why i said "IF you were wrong".

FYI, I am only moderately paranoid. But in the light of recent NSA-snowden stuff, I think that is completely justified...

[johnyj]

I just heard that someone lost 150 coins in an offline wallet with a 20 character strong password and he doesn't understand at all what went wrong

It so obvious to you when you get to gloat over other people's losses, but I've yet to see you speak up in a thread where people are advancing "brainwallets" and say "no! don't do it!".

I don't trust my memory very well. And I know that some one is using a dictionary attacking method to search for all possible brainwallets

BTW, I did not laugh at his loss, but at the fact of lacking of easy way to secure the wallet for normal user. And there is another potential risk of losing bitcoins when a wallet has made more than 100 payment thus the old backup does not contain the newly generated address

Anyway, current solutions are either cumbersome or risky. Armory is the right direction, but in order to use it you have to understand the technical details of each transaction, not for average Joe either

Just came over this poll:
https://bitcointalk.org/index.php?topic=313029.0

[Cryddit]

Authentication that is based solely on secrets which can be compromised is better than you can otherwise do with strangers.  But it is still subject to eavesdropping by anyone else who shares that secret. 

Using DH over a channel secured only by a cert key means that an MITM in possession of that cert key can impersonate each side to the other, negotiating (separate) DH keys with each side.  Then he can see any message someone sends, modify it if he wants to, and send it on.  IOW, in the presence of a leaked cert, it does not secure the channel from a MITM attack.  It secures the channel from passive eavesdroppers, even those who have a copy of the cert; but anyone capable of a MITM attack is not inconvenienced by it in the slightest. 

Securing the channel using DH over interlock guarantees that even if more than one person has that cert key, your conversation will *not* be with more than one person.  IE no one can eavesdrop or selectively modify messages; any interference by an MITM has to take the form of all-or-nothing impersonation with no "help" or ability to pass your requests for information on to your intended correspondent and see the results. 

Authentication is a separate problem.  Using the cert key to authenticate and doing DH via Interlock is unconditionally better than just using the cert to authenticate.  Although any MITM who has the cert key can still impersonate the intended correspondent, he cannot eavesdrop on a conversation between you and your correspondent nor modify your communications with your correspondent.  That is a guarantee that is strictly better than you can do by using the cert key alone to secure the channel. 

A cert key, although not trust-free, is the best you can do for authentication, but a cert key alone only secures the channel from active attackers or passive eavesdroppers who don't have the key; DH over a channel secured with a cert key additionally secures the channel against passive eavesdroppers who do have the key.  DH over interlock on a channel secured with a cert key additionally prevents eavesdropping or modification of messages in flight by active attackers who have the cert key.

When dealing with a centralized authority, you have to deal with the threat model that says centralized authority has been compromised.  I recommend a protocol that gives you more guarantees in the presence of a compromised central authority than you could otherwise have.

[grau]

Most of the devs I know have a habit: They must do something every day  

Payment protocol stuff was a business demanded feature, intended to address some of the problems that have cropped up with Bitcoin URLs. Its certainly not something sexy or exciting to work on.

If it were business demand then there would be a business case and a solution for it.

[Peter Todd]

Most of the devs I know have a habit: They must do something every day  

Payment protocol stuff was a business demanded feature, intended to address some of the problems that have cropped up with Bitcoin URLs. Its certainly not something sexy or exciting to work on.

If it were business demand then there would be a business case and a solution for it.

Where do you think Gavin's salary comes from?

There is a strong business case, he's coming up with a decent solution for it, and because his paycheck comes from the foundation rather than a specific company he can come up with a solution that can be used by everyone in the community and doesn't privilege any particular player. (except certificate authorities, initially, but the payment protocol is pluggable and more decentralized PKI systems can be easily added later as they are developed)

[Carlton Banks]

Authentication that is based solely on secrets which can be compromised is better than you can otherwise do with strangers.  But it is still subject to eavesdropping by anyone else who shares that secret. 

Using DH over a channel secured only by a cert key means that an MITM in possession of that cert key can impersonate each side to the other, negotiating (separate) DH keys with each side.  Then he can see any message someone sends, modify it if he wants to, and send it on.  IOW, in the presence of a leaked cert, it does not secure the channel from a MITM attack.  It secures the channel from passive eavesdroppers, even those who have a copy of the cert; but anyone capable of a MITM attack is not inconvenienced by it in the slightest. 

Securing the channel using DH over interlock guarantees that even if more than one person has that cert key, your conversation will *not* be with more than one person.  IE no one can eavesdrop or selectively modify messages; any interference by an MITM has to take the form of all-or-nothing impersonation with no "help" or ability to pass your requests for information on to your intended correspondent and see the results. 

Authentication is a separate problem.  Using the cert key to authenticate and doing DH via Interlock is unconditionally better than just using the cert to authenticate.  Although any MITM who has the cert key can still impersonate the intended correspondent, he cannot eavesdrop on a conversation between you and your correspondent nor modify your communications with your correspondent.  That is a guarantee that is strictly better than you can do by using the cert key alone to secure the channel. 

A cert key, although not trust-free, is the best you can do for authentication, but a cert key alone only secures the channel from active attackers or passive eavesdroppers who don't have the key; DH over a channel secured with a cert key additionally secures the channel against passive eavesdroppers who do have the key.  DH over interlock on a channel secured with a cert key additionally prevents eavesdropping or modification of messages in flight by active attackers who have the cert key.

When dealing with a centralized authority, you have to deal with the threat model that says centralized authority has been compromised.  I recommend a protocol that gives you more guarantees in the presence of a compromised central authority than you could otherwise have.

Given all of this, what possible threat do we face when a compromised certificate is used to sign a Payments Protocol request as they are currently composed? It seems that the only certificate signed information is a simple confirmation that the Request to Pay was satisfied by the payee, and so presumably the public key used and the sum of the payment would also be disclosed to anyone who has a copy of the certificate used (and so the only additional information the illegitimate certificate holder can glean is the IP/identity of the receiver of the funds). It seems improbable from what I understand about the model, but could this pose any risk to the sanctity of the contents of the message?

[grau]

Most of the devs I know have a habit: They must do something every day  

Payment protocol stuff was a business demanded feature, intended to address some of the problems that have cropped up with Bitcoin URLs. Its certainly not something sexy or exciting to work on.

If it were business demand then there would be a business case and a solution for it.

Where do you think Gavin's salary comes from?

There is a strong business case, he's coming up with a decent solution for it, and because his paycheck comes from the foundation rather than a specific company he can come up with a solution that can be used by everyone in the community and doesn't privilege any particular player. (except certificate authorities, initially, but the payment protocol is pluggable and more decentralized PKI systems can be easily added later as they are developed)

The payment protocol is a pet project of Gavin, that will be useful just like everything he makes, but has not much to do with the core of Bitcoin that should rather be hardened and standardized as it was originally postulated to be the purpose of the foundation, that pays his salary

[ShadowOfHarbringer]

Most of the devs I know have a habit: They must do something every day  

Payment protocol stuff was a business demanded feature, intended to address some of the problems that have cropped up with Bitcoin URLs. Its certainly not something sexy or exciting to work on.

If it were business demand then there would be a business case and a solution for it.

Where do you think Gavin's salary comes from?

There is a strong business case, he's coming up with a decent solution for it, and because his paycheck comes from the foundation rather than a specific company he can come up with a solution that can be used by everyone in the community and doesn't privilege any particular player. (except certificate authorities, initially, but the payment protocol is pluggable and more decentralized PKI systems can be easily added later as they are developed)

The payment protocol is a pet project of Gavin, that will be useful just like everything he makes, but has not much to do with the core of Bitcoin that should rather be hardened and standardized as it was originally postulated to be the purpose of the foundation, that pays his salary

Future will tell if that protocol will be useful, however I am afraid you are right (for now i have completely no idea what I could use it for).

[Mike Hearn]

Gavin is also working on a fee rework, p2p protocol upgrades and various other things to do with the core system. But I think you underestimate the importance of the payment protocol work for future features. There's a reason Bitcoin 0.1 had a payment protocol - it's just as important a core feature as the p2p floodfill mechanic.

[piotr_n]

But I think you underestimate the importance of the payment protocol work for future features.

But as you see, we at least don't underestimate the importance of the payment protocol work for Google and the rest of the cartel driving development of the satoshi client today.
The guy must be very proud seeing how quickly the steering wheel of his open source project got captured by such a fine set of corporations

There's a reason Bitcoin 0.1 had a payment protocol - it's just as important a core feature as the p2p floodfill mechanic.

Right. And one can only wonder how BTC got to $200 price, without a working payment protocol.
It was in Bitcoin 0.1 - how could we have lived without it ever since? We obviously don't know what we were loosing...

[Peter Todd]

Where do you think Gavin's salary comes from?

There is a strong business case, he's coming up with a decent solution for it, and because his paycheck comes from the foundation rather than a specific company he can come up with a solution that can be used by everyone in the community and doesn't privilege any particular player. (except certificate authorities, initially, but the payment protocol is pluggable and more decentralized PKI systems can be easily added later as they are developed)

The payment protocol is a pet project of Gavin, that will be useful just like everything he makes, but has not much to do with the core of Bitcoin that should rather be hardened and standardized as it was originally postulated to be the purpose of the foundation, that pays his salary

There's plenty of very intelligent people working on understanding and improving Bitcoin's core technologies and resistance to attack. What we're lacking most is people doing the ugly and boring work, and the payment protocol definitely fits that description. Heck for me personally even testing and auditing, at least for cool stuff like security and consensus threatening bugs, is way more interesting than the payment protocol.

Anyway, Bitcoin is brand new computer science and cryptography and you really don't want a single person being "assigned" to hardening it and refining the design of it. No one person is smart enough or has the breadth of experience to do that, but from the sounds of it the Foundation doesn't have the money to hire the teams of researchers that you'd really need. So they're doing a good job focusing their efforts on what they can do, and letting the community handle the rest.

[piotr_n]

There's plenty of very intelligent people working on understanding and improving Bitcoin's core technologies and resistance to attack.

Really?
Not to undermine anyone's useful input into the project, but to be honest, from this perspective it looks more like for the last two years or so, these "very intelligent people" have mostly been busy with "working on understanding".

What we're lacking most is people doing the ugly and boring work, and the payment protocol definitely fits that description.

I totally understand you. I also find boring almost every work that I do only because I get paid for it.
And it is especially boring when I know that what I am working on is going to be useless after all.

[wumpus]

So they're doing a good job focusing their efforts on what they can do, and letting the community handle the rest.

Yes, that is the take-away from everything. The community needs to be involved. Bitcoin is not a traditional top-down organization with a customer support division but an open source project. If you (or your organization) cares enough about something there is no use complaining on some forum that other devs are doing the things they are interested in, you need to step up yourself to make sure it happens.

[grau]

Where do you think Gavin's salary comes from?

There is a strong business case, he's coming up with a decent solution for it, and because his paycheck comes from the foundation rather than a specific company he can come up with a solution that can be used by everyone in the community and doesn't privilege any particular player. (except certificate authorities, initially, but the payment protocol is pluggable and more decentralized PKI systems can be easily added later as they are developed)

The payment protocol is a pet project of Gavin, that will be useful just like everything he makes, but has not much to do with the core of Bitcoin that should rather be hardened and standardized as it was originally postulated to be the purpose of the foundation, that pays his salary

There's plenty of very intelligent people working on understanding and improving Bitcoin's core technologies and resistance to attack. What we're lacking most is people doing the ugly and boring work, and the payment protocol definitely fits that description. Heck for me personally even testing and auditing, at least for cool stuff like security and consensus threatening bugs, is way more interesting than the payment protocol.

Anyway, Bitcoin is brand new computer science and cryptography and you really don't want a single person being "assigned" to hardening it and refining the design of it. No one person is smart enough or has the breadth of experience to do that, but from the sounds of it the Foundation doesn't have the money to hire the teams of researchers that you'd really need. So they're doing a good job focusing their efforts on what they can do, and letting the community handle the rest.

Gavin works on whatever he likes, just like all other core devs in my observation.

I believe that the criticality of payment protocol is way below of other issues and if it was business critical there would be funds for it other than the foundation's.

[dillpicklechips]

Gavin did you catch my question about colored coin support?

Is there plans for adding colored coins support? As a merchant I could ask the customer if they support colored coins and ask for an address where to send them. I could then send the colored coins with along with label for what they are. This could allow the merchant to do a rewards or points system that the customer could redeem later as a reward for using BTC.

[CIYAM]

With the amount of hostility (often accompanied by as much ignorance) being posted it's perhaps not surprising that Gavin isn't responding (although his shouting really didn't do him much credit either - guess he just found it a bit much and exploded a little).

As the Foundation pays his salary one would expect that it's at their behest that one of his major recent focuses has been the "payment" system (more than him deciding himself that it is the most interesting thing to be working on - especially after other devs have pointed out that it really isn't a hugely exciting part of Bitcoin).

Perhaps if this topic could "get back on topic" it might serve more purpose.

[piotr_n]

With the amount of hostility (often accompanied by as much ignorance) being posted it's perhaps not surprising that Gavin isn't responding

Hostility can have many faces.

There can surely be an open active hostility; e.g. when the bitcoin community accuses core devs of corruption (or at least a conflict of interest) and they demand an explanation. (which never comes, which makes them even more openly hostile)

But there can also be a hidden passive hostility; e.g. core devs intentionally sabotaging development of the project's original principles, by developing it in the opposite directions.

I totally get it, that Gavin and others perceive us as a bunch of assholes who don't even deserve an explanation - they are obviously too important piece of the bitcoin elite to explain anything to us, an average users from some bitcointalk forum. But since we have already established this position, and it's pretty clear who we are for them, we (just like them) still do the best we can to help the community in building a prosperous future of this project. And that (among other things that we do, which the bitcoin elite also doesn't give a shit about) is today, unfortunately warning people to be careful with trusting the cartel that took over the development of the satoshi client and to be careful with using the new incoming features.
You call it hostility - I call it sincerity.

[Carlton Banks]

Having now scrutinised BIP 70 (the written proposal for the Payments Protocol), it appears that a hash of the message data contained in the Payment Request is signed by the CA. Depending on which information the merchant chooses to include in that message, an obfuscated form of data you may prefer not to share with the holders of a merchants certificate, both legitimate and illegitimate, is in fact shared.

Can anyone make a clear statement as to whether the hashed data in the merchant's message can be read by the certificate holder(s)? (I do realise I might be asking a question akin to "is SHA broken?", I understand this not to be the case, but I also don't know the cryptographic relationship between the merchants PKI key, the corresponding certificate and the signature created used to authenticate the payments request as a whole)

[piotr_n]

Can anyone make a clear statement as to whether the hashed data in the merchant's message can be read by the certificate holder(s)?

I would not expect it.
Some posts ago I asked another silly question: can anyone make a clear statement as to whether my PC will connect to the CA server to check if a certificate has not been revoked?
No answer whatsoever.
And that leaves us with three possible explanations:
1) They don't know - meaning: they don't know what they are doing adding these SSL stuff into bitcoin
2) Yes, my PC might connect to CA each time I do a payment - meaning: our IP gets exposed each time we pay, but they don't want to worry us
3) I don't deserve their answer - meaning: who besides me cares about such a minor concerns?
Since we don't know the correct number, maybe we should make a poll?

[CIYAM]

Since we don't know the correct number, maybe we should make a poll?

A "poll" - I hope you aren't being serious (you did put a smiley after that so I guess not).

How does a CA signature actually *change* anything at all?

Doesn't it just add something (that you can ignore if you want)?

The private key of the cert is still private isn't it (and how do you propose to do something better)?

[piotr_n]

A "poll" - I hope you aren't being serious (you did put a smiley after that so I guess not).

Of course I wasn't serious.
But my concern is a really serious one.

It is a known fact that SSL certificates have a built in mechanism to be revoked by their CA.
And it is also a known fact that today SSL certificates are essentially validated by an OS, since the OS has the root certificates.
Maybe not in case of Firefox, but definitely in case of Chrome, and since we have a Google employee putting it into Bitcoin, it seems natural to assume that he would use the Chrome approach.

So once again: how can we be sure that our OS does not report each transaction we send, along with our IP, to the CA?

[CIYAM]

So once again: how can we be sure that our OS does not report each transaction we send, along with our IP, to the CA?

Okay - now we are getting more into the "bread and butter" - is the major concern about privacy?

All my BTC bills that are done through BitPay are already recorded with even more details than just my IP (it includes address details) so how exactly is this going to be any worse than what is already *standard*?

[piotr_n]

All my BTC bills that are done through BitPay are already recorded with even more details than just my IP (it includes address details) so how exactly is this going to be any worse than what is already *standard*?

Well, IMHO the question you should be asking is: how is it going to be any better than what is already *standard*?

And this question I can even answer myself: it isn't.

[CIYAM]

So my question to you is "what do you expect?".

Do you really think that major corporations who pay their taxes and make profits are suddenly going to want to try and stop paying their taxes?

This is simply a question of what is sensible - no-one is stopping the Bitcoin protocol with these new options - they are simply making something that will be more palatable to the companies that already are happy with the way things are.

The revolution is not going to come from the corporations.

[piotr_n]

Eeee...
Sorry, but what my unwillingness to broadcast each of my bitcoin transactions to a CA has to do with anyone paying taxes?

And once again: I really don't care about "major corporations".
If they all fucked off and died today - that would have been the best day of my life
Bitcoin is for people - not for corporations.

[CIYAM]

Sorry, but what my unwillingness to broadcast each of my bitcoin transactions to a CA has to do with anyone paying taxes?

That is an issue - but already if you pay BTC using BitPay or other equivalents you are *already* doing this - have I missed something?

(also I don't see how your tx is broadcast to the CA as they only *sign* the cert - unless they own the private key how exactly do they *see* your tx?)

[piotr_n]

Sorry, but what my unwillingness to broadcast each of my bitcoin transactions to a CA has to do with anyone paying taxes?

That is an issue - but already if you pay BTC using BitPay or other equivalents you are *already* doing this - have I missed something?

No, you get it all right. That is exactly why I cleverly never pay BTC using BitPay.

[CIYAM]

No, you get it all right. That is exactly why I cleverly never pay BTC using BitPay.

So then how does this new stuff affect you at all then?

[piotr_n]

No, you get it all right. That is exactly why I cleverly never pay BTC using BitPay.

So then how does this new stuff affect you at all then?

It doesn't.
But it does affect bitcoin-qt.
There are millions of people using this s/w and ever since the new payment protocol is introduced they will be using it, unconsciously ignoring the fact that each time they make a "secured payment", they likely log it along with their IP, at the CA server that issued the recipient's cert.

[CIYAM]

There are millions of people using this s/w and ever since the new payment protocol is introduced they will be using it, unconsciously ignoring the fact that each time they make a "secured payment", they are probably log it, along with their IP, at the CA server.

Sure - but those same people would be using BitPay or some other equivalent and doing exactly the same thing.

I just don't see the fuss - it's not as though *more* information is being gathered that already is.

[gweedo]

Lets face it the Payment protocol only helps a hand few of companies and people, at the expense of privacy. PKIs are broken, and because of the payment protocol I have looked into starting a CA. The software to do that is a mess. Also to have this in a 0.9 release when even Gavin himself has said they are in need of developers to do things, doesn't make sense. I want to know when the blockchain will be worked on, this is an area that needs a lot of work and so far one developer is actually doing all the work. So I pose this question does Gavin know how to manage his time or is he just scamming us for a paycheck by saying this is important when it is clearly isn't.

[CIYAM]

The problem is creating a serious way of developing software - I have set up http://ciyam.org/open and even offered free listing of projects (for life) so it is not as though there is no platform do get things done but finding the people to do it is another thing (as I have found).

If you want to really get things done then I am more than happy to help!
 

[piotr_n]

IMHO there is no lack of developers who would like to help with bitcoin.
What there is though, is a cartel controlling the development of the reference client, not letting in anyone who would try to invent anything that would have made bitcoin even a bigger threat to the establishment.

This is the only way I can explain the past 2 years of essentially no useful progress in this project.
Despite of the fact that the price of bitcoin went up tens of times fold.

[CIYAM]

IMHO there is no lack of developers who would like to help with bitcoin.

Well - I'd have to disagree with this - I've offered very reasonable bounties (actually unreasonable in terms of the payee) and still found no-one willing to write any source code at all.

If you really think the guys are out there then please create a project on CIYAM Open (for free) and let's get something done!

[piotr_n]

Well - I'd have to disagree with this - I've offered very reasonable bounties (actually unreasonable in terms of the payee) and still found no-one willing to write any source code at all.

You shouldn't be surprised, considering that you don't care about anonymity at all.
Any dev working for your money, would not have been much different from what Gavin or Mike are doing right now.
As much as the media admires them, the people who can actually develop stuff see that there is something wrong around it.
Nobody wants to take a part in building a worse future for his children, even if you pay them.

[CIYAM]

You shouldn't be surprised, considering that you don't care about anonymity at all.

People can be as anonymous as they like with CIYAM Open (clearly you have not looked into it at all).

I don't block TOR or control anything about how people do things at all so where do you get your ideas about my care about anonymity from?

[piotr_n]

You shouldn't be surprised, considering that you don't care about anonymity at all.

People can be as anonymous as they like with CIYAM Open (clearly you have not looked into it at all).

You're right - I have not looked into it at all.
Sorry, but I never watch ads, no matter how good a movie is

But what I can tell you is that, as far as I know you, I would not trust you with protecting my anonymity.
I'd rather use Tor with enabled JavaScript.

[CIYAM]

Sorry, but I never watch ads, no matter how good a movie is

Fair enough about ads - actually I was just trying to help out Gavin in this topic (and no he and I have never even exchanged a PM).

(as stated you can use Tor with CIYAM Open)

I will bow out of this topic now as it seems I have overstepped the mark - hopefully the rest of the posts can at least be on topic.

[piotr_n]

FWIW, I don't think you helped Gavin at all, while stating: yes, the user's transaction along with his IP will be logged at the CA server, every time the new payment protocol handles an outgoing transaction.

But thank you - you definitely helped the rest of us.
Knowledge is power

[riplin]

FWIW, I don't think you helped Gavin at all, while stating: yes, the user's transaction along with his IP will be logged at the CA server, every time the new payment protocol handles an outgoing transaction.

Can anyone please point me to the section in the BIP that actually states that this is the case?

[Cryddit]

What gets logged at the CA is not the transaction and IP address; it's the *hash* of the transaction and IP address.  Essentially the same hash Bitcoin uses to secure the integrity of its blockchain, which works because nobody can find a preimage.  IE, given a 256-bit hash value, you can't find the original message (in this case the transaction and IP) without doing 2²⁵⁶ work.  Which nobody can do, or the difficulty threshold for mining would be around 115792089237316000000000000000000000000000000000000000000000000000000000000000 instead of around 267731249 right now.


So what happens is that you and the other party/parties to the transaction both/all know about the transaction.  The CA signing the hash doesn't mean anybody else (not even the CA itself) can find out about the transaction, because nobody can find a preimage; what it means that either/any of you can choose to prove what you know by revealing the transaction record and showing that it is the preimage for the CA's hash.

Essentially, there's little risk that there wasn't before.  A party to the transaction can let other people know about the transaction.  All that changes with the CA is that you (or they) can prove when they reveal it that it's the same thing the CA signed.

Well, not quite all.  If someone has hacked, burgled, extorted, blackmailed, bribed, or served the CA with a court order, and is able to spoof your traffic when you're making the transaction,  they will be able to eavesdrop on or alter the transaction unless you develop and deploy better channel security than the users of the payment protocol have so far developed and deployed.

[piotr_n]

What gets logged at the CA is not the transaction and IP address; it's the *hash* of the transaction and IP address.

OK.
So on the 11th page of this topic, it is already sort of official: each time you use the new payment protocol, your PC connects to the CA server and leaves there the TxID and your IP.

Guys, you should have started from it - then we would tell you already at the first page to not waste a year of your time on developing such a crap.
Hell, if you put it into 0.9, I am not going to run it even once, on my PC. Thank you very much for such a great features, but I'm totally fine without them

[riplin]

each time you use the new payment protocol, your PC connects to the CA server and leaves there the TxID and your IP.

I still haven't seen the section of the BIP that states this to be true.

The way I understand it, the actual transaction is signed using either the merchant certificate or the payment processor (like bitpay for example), NOT the CA.

What IS signed by the CA is the certificate of the merchant. This happens in a chain like fashion (if there are more intermediary CA's). This happens when the merchant acquires his certificate, long before he uses it to sign any transactions. All these certificates are sent in the payment request package, except for the root certificate, which is acquired out of band, either locally from the OS or from something like the Mozilla root store.

All communication is between the merchant and the client as shown in this nice image that's in the BIP:



At no point in that image is any kind of information sent to the CA.


If any of this is wrong, then please tell me and I'd appreciate if you supplied sources.

[piotr_n]

yeah, but this diagram does not seem to cover the SSL authentication process at all.
WTF "Authorize?" means??

[riplin]

yeah, but this diagram does not seem to cover the SSL authentication process at all.
WTF "Authorize?" means??

Authorize means: "Do you wish to make this payment? (Y/N)"

It's a dialog presented to the user asking him if he wants to execute this payment.

[piotr_n]

yeah, but this diagram does not seem to cover the SSL authentication process at all.
WTF "Authorize?" means??

Authorize means: "Do you wish to make this payment? (Y/N)"

It's a dialog presented to the user asking him if he wants to execute this payment.

Right.
So where/when is the SSL verification?
It's definitely missing in there.

[riplin]

So where/when is the SSL verification?
It's definitely missing in there.

It's not missing. It's done at the point where the PaymentRequest is received by the wallet app.

The payment message is signed with the merchant's (or payment processor's) private key. The PaymentRequest contains the merchant's (or payment processor's) certificate, which contains the public key, which is used to verify that the PaymentRequest isn't tampered with.

Now this doesn't solve anything by itself, since you don't know if the merchant's certificate is authentic, so, you need to figure that out next. That's where the chain of certificates comes in. They basically state: "I hereby declare that this certificate is authentic". If you traverse up this chain of certificates (all of which are present in the PaymentRequest message) then eventually you'll end up at the top, where you'll need the ROOT certificate to see if this chain is valid.

The root certificate is usually shipped with your OS. And if it isn't the BIP suggest that you request it from the Mozilla Root Store.

At no point in this entire exchange has any information been sent to the CA.

[piotr_n]

That was actually my initial understanding that SSL does not need CA server, as long as it has a trusted parent cert in local storage.

But still, this diagram does not mention SSL validation at all, and some people in this topic have clearly stated that it involves signing (verifying) transaction's hash with the CA server itself.
To be honest, I don't know if it is entirely true. All I know is that these are the same people who are sort of defending this new payment protocol.
And I also know that SSL certificate has a built in mechanism to be revoked - so it makes me wonder how it works with the payment protocol, since it's logical that it must connect to CA at least to revoke a cert. Having this in mind, I would not be surprised anymore finding out that it also connects to CA to verify the signature itself.

The problem is that we don't know how the validation process really works, step by step and Mike's "fantastic payment protocol FAQ" does not come handy here at all, does it?

How do identities work?

The protocol can be extended with multiple methods, but for v1 the only one that works is X.509 certificates. This is the same scheme used for SSL.

https://bitcointalk.org/index.php?topic=300809.msg3225143#msg3225143

[riplin]

But still, this diagram does not mention SSL validation at all, and some people in this topic have clearly stated that it involves signing transaction's hash with the CA itself.

As long as nobody provides any sources, there's no reason to believe this is the case.

And I also know that SSL certificate has a built in mechanism to be revoked having this in mind, I would not be surprised if it connects to CA even to verify the signature.

The signature verification only requires the certificate, nothing more.

Testing whether or not a specific certificate is revoked is done using certificate revocation lists:

http://en.wikipedia.org/wiki/Revocation_list

These are published lists that contain ID's of certificates that have been revoked.

Again, this does not expose any kind of information from the PaymentRequest.

[kjj]

yeah, but this diagram does not seem to cover the SSL authentication process at all.
WTF "Authorize?" means??

Authorize means: "Do you wish to make this payment? (Y/N)"

It's a dialog presented to the user asking him if he wants to execute this payment.

Right.
So where/when is the SSL verification?
It's definitely missing in there.

You know, if you would just learn to use google, you'd make a hell of a lot less incoherent emo posts, and probably do a fair bit less cutting.

Please read the RFCs for OCSP (2560, 5019, etc).  OCSP involves asking the OCSP server for the current revocation status of the certificate.  There is no provision for sending your transaction to the OCSP server for tracking.  Very close to 100% of OCSP traffic is used for validating SSL certs.  If it was leaking data, it would have already leaked all of your SSL session keys (since 1999!).

If OCSP is enabled in bitcoind, the OCSP server might be able to figure out that you are looking at a signed payment request from entity X, which they probably already knew because your browser checked the exact same certificate a few seconds earlier.

It is entirely possible that I'm being unfair in my estimation that you are a giant fucking troll*, in which case I would owe you an apology.  But you are clearly aware of the existence of OCSP (since your questions make no sense in any other context), but you have either intentionally refused to educate yourself about it, or you know perfectly well what it does and does not do, but want to spread misinformation.

* Not like we don't all know about you from your insane rants in other threads.

[piotr_n]

yeah, but this diagram does not seem to cover the SSL authentication process at all.
WTF "Authorize?" means??

Authorize means: "Do you wish to make this payment? (Y/N)"

It's a dialog presented to the user asking him if he wants to execute this payment.

Right.
So where/when is the SSL verification?
It's definitely missing in there.

You know, if you would just learn to use google, you'd make a hell of a lot less incoherent emo posts, and probably do a fair bit less cutting.

Please read the RFCs for OCSP (2560, 5019, etc).  OCSP involves asking the OCSP server for the current revocation status of the certificate.  There is no provision for sending your transaction to the OCSP server for tracking.  Very close to 100% of OCSP traffic is used for validating SSL certs.  If it was leaking data, it would have already leaked all of your SSL session keys (since 1999!).

If OCSP is enabled in bitcoind, the OCSP server might be able to figure out that you are looking at a signed payment request from entity X, which they probably already knew because your browser checked the exact same certificate a few seconds earlier.

It is entirely possible that I'm being unfair in my estimation that you are a giant fucking troll*, in which case I would owe you an apology.  But you are clearly aware of the existence of OCSP (since your questions make no sense in any other context), but you have either intentionally refused to educate yourself about it, or you know perfectly well what it does and does not do, but want to spread misinformation.

* Not like we don't all know about you from your insane rants in other threads.

Really man I don't even know what OCSP stands for, since I really don't care about such a useless technologies.

But sure, feel free to call me a giant fucking troll, as opposed to a member of the bitcoin elite that you are obviously representing here - from you, I actually take it as a compliment

[riplin]

Really man I don't even know what OCSP stands for, since I really don't care about such a useless technologies.

How do you expect people to take you seriously with statements like these?

[Carlton Banks]

each time you use the new payment protocol, your PC connects to the CA server and leaves there the TxID and your IP.

I still haven't seen the section of the BIP that states this to be true.

[...]


If any of this is wrong, then please tell me and I'd appreciate if you supplied sources.

According to BIP 70, it's a non-mandatory part of the protocol. The behaviour is defined in pki_type in the Payment Request message. If pki_type is not supplied, then the protocol treats the instance as if the lack of PKI specifics means that none is to be used. This means the composer of the message needs to specify this correctly themselves, there is no "send to the CA for a signature whether people like it or not" behaviour.

Take a look at the constituents of the PaymentRequest message in BIP 70:

PaymentDetails/PaymentRequest

Payment requests are split into two messages to support future extensibility. The bulk of the information is contained in the PaymentDetails message. It is wrapped inside a PaymentRequest message, which contains meta-information about the merchant and a digital signature.

    message PaymentDetails {
        optional string network = 1 [default = "main"];
        repeated Output outputs = 2;
        required uint64 time = 3;
        optional uint64 expires = 4;
        optional string memo = 5;
        optional string payment_url = 6;
        optional bytes merchant_data = 7;
    }        

network    either "main" for payments on the production Bitcoin network, or "test" for payments on test network. If a client receives a PaymentRequest for a network it does not support it must reject the request.
outputs    one or more outputs where Bitcoins are to be sent. If the sum of outputs.amount is zero, the customer will be asked how much to pay, and the bitcoin client may choose any or all of the Outputs (if there are more than one) for payment. If the sum of outputs.amount is non-zero, then the customer will be asked to pay the sum, and the payment shall be split among the Outputs with non-zero amounts (if there are more than one; Outputs with zero amounts shall be ignored).
time    Unix timestamp (seconds since 1-Jan-1970) when the PaymentRequest was created.
expires    Unix timestamp after which the PaymentRequest should be considered invalid.
memo    UTF-8 encoded, plain-text (no formatting) note that should be displayed to the customer, explaining what this PaymentRequest is for.
payment_url    Secure (usually https) location where a Payment message (see below) may be sent to obtain a PaymentACK.
merchant_data    Arbitrary data that may be used by the merchant to identify the PaymentRequest. May be omitted if the merchant does not need to associate Payments with PaymentRequest or if they associate each PaymentRequest with a separate payment address.

A PaymentRequest is PaymentDetails optionally tied to a merchant's identity:

    message PaymentRequest {
        optional uint32 payment_details_version = 1 [default = 1];
        optional string pki_type = 2 [default = "none"];
        optional bytes pki_data = 3;
        required bytes serialized_payment_details = 4;
        optional bytes signature = 5;
    }

payment_details_version    See below for a discussion of versioning/upgrading.
pki_type    public-key infrastructure (PKI) system being used to identify the merchant. All implementation should support "none", "x509+sha256" and "x509+sha1".
pki_data    PKI-system data that identifies the merchant and can be used to create a digital signature. In the case of X.509 certificates, pki_data one or more X.509 certificates (see Certificates section below).
serialized_payment_details    A protocol-buffer serialized PaymentDetails message.
signature    digital signature over a hash of the protocol buffer serialized variation of the PaymentRequest message, where signature is a zero-byte array and fields are serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order), using the public key in pki_data.

From this, you can see that the Payment Details message is contained in the overall PaymentRequest message (in the serialized_payment_details variable). What I've tried to highlight is, that:

• your Bitcoin public key (message Payment Details { repeated Output outputs })  
• the Merchant's message for details of the request (message Payment Details { optional string memo })
• your IP (message Payment Details { optional string payment_url })

are all contained in the presiding message PaymentRequest variable {required bytes serialized_payment_details}.

If you look at the description in the section for the PaymentsRequest message that describes the composition of the signature, also bolded, you'll see that the PaymentRequest message itself is hashed using the public key (optionally) provided by the merchant.

What concerns me is that I have no idea whether the data in the Payments Details (non-mandatory as some of it is) can be somehow cajoled into something meaningful, given that the nature of the hashing of this information involves using a certificate to authenticate that some of the contents of the hash are verifiable. The PKI public key of the merchant must be positively identified from within the hash of the information, so is the rest of the hashed information also safe?

What is the necessity of sending the PaymentDetails for the purpose of verifying the merchant key, could something that is not user sensitive be used? Or not? Does it even matter at all?

[piotr_n]

Really man I don't even know what OCSP stands for, since I really don't care about such a useless technologies.

How do you expect people to take you seriously with statements like these?

I believe most people don't know what OCSP stands for - so why would they not take me seriously asking about it?

[riplin]

Really man I don't even know what OCSP stands for, since I really don't care about such a useless technologies.

How do you expect people to take you seriously with statements like these?

I believe most people don't know what OCSP stands for - so why would they not take me seriously asking about it?

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

[piotr_n]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

Well, at least I'm not lying.

Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

[Carlton Banks]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Optionally sends a hash of a transaction to the CA.

[kjj]

Really man I don't even know what OCSP stands for, since I really don't care about such a useless technologies.

Go educate yourself.

Even better, according to Gavin on IRC just now, OCSP is not currently scheduled for implementation.  So, just to be absolutely clear to anyone reading this thread, at this time, there will be absolutely zero communication with any CA done by the bitcoind client.

At some point, some form of OCSP probably will be implemented, because it is a very useful security feature.  When that time comes, everything I said above about OCSP not leaking the transaction details will still apply, and several billion people will have the opportunity to verify on their own that the code isn't doing anything sneaky.

[riplin]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Optionally sends a hash of a transaction to the CA.

Do you have a source for this?

[piotr_n]

Go educate yourself.

I fink you meant the other verb

Educating myself is exactly what I have been trying to do here, before you jumped in here, to insult me on behalf of the bitcoin elite.

Even better, according to Gavin on IRC just now, OCSP is not currently scheduled for implementation.  So, just to be absolutely clear to anyone reading this thread, at this time, there will be absolutely zero communication with any CA done by the bitcoind client.

Oh, thank you for finally making that clear, though...

At some point, some form of OCSP probably will be implemented, because it is a very useful security feature. 

Right. So we are going back to the entry point

When that time comes, everything I said above about OCSP not leaking the transaction details will still apply, and several billion people will have the opportunity to verify on their own that the code isn't doing anything sneaky.

It is not me who said in this topic that the hash is sent to CA - I only repeated it, since you were not here to state it wrong.
Go educate yourself.

[Carlton Banks]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Optionally sends a hash of a transaction to the CA.

Do you have a source for this?

https://en.bitcoin.it/wiki/BIP_0070

Read my dissemination of the relevant parts above where I quote BIP 70, or look it all through yourself.

[kjj]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

Well, at least I'm not lying.

Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Links?  I could only find one, and I have no idea why he thinks that anything related to the transaction would ever be sent to the CA.

[piotr_n]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

Well, at least I'm not lying.

Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Links?  I could only find one, and I have no idea why he thinks that anything related to the transaction would ever be sent to the CA.

https://bitcointalk.org/index.php?topic=128442.msg3402965#msg3402965
https://bitcointalk.org/index.php?topic=128442.msg3403915#msg3403915

Why would he think so? Maybe because he followed your advise and educated himself...

EDIT:
Sorry - one of the links points to a post of a non-supporter.

[Carlton Banks]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

Well, at least I'm not lying.

Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Links?  I could only find one, and I have no idea why he thinks that anything related to the transaction would ever be sent to the CA.

Given the circumstance in which the CA system produces the signature for the Payment Request message, how can a valid signature be produced that the CA did not sign?

[kjj]

Read my dissemination of the relevant parts above where I quote BIP 70, or look it all through yourself.

I've read your posts several times, and I still can't figure out why you think that anything is being sent to the CA.  Digital signing involves hashing the message, and OCSP involves sending the hash of the certificate issuer's DN and pubkey, but it doesn't follow that OCSP is going to throw every hash it sees into the OCSPrequest.

[piotr_n]

Read my dissemination of the relevant parts above where I quote BIP 70, or look it all through yourself.

I've read your posts several times, and I still can't figure out why you think that anything is being sent to the CA.  Digital signing involves hashing the message, and OCSP involves sending the hash of the certificate issuer's DN and pubkey, but it doesn't follow that OCSP is going to throw every hash it sees into the OCSPrequest.

Where do you get the root certificates from?
Or let me ask otherwise, make it a simpler question: which openssl function do you use to verify a certificate and the message, and how do you know what this function does inside?

[jgarzik]

The bitcoin client does not connect to the CA.

Stop repeating clueless people.

[piotr_n]

The bitcoin client does not connect to the CA.

Stop repeating clueless people.

So it does not support a chained certificates?

The bitcoin client does not need to connect to the CA.
All it takes is an SSL lib connecting there, likely even on the OS level, since the root certs are installed right there.

You guys obviously don't quite understand how this protocol works inside, and it's obvious since it is a one big mess and nobody does, but don't you think that merging the bitcoin client with a lib that nobody really understands might be a bit dangerous, to say the least?

[riplin]

From this, you can see that the Payment Details message is contained in the overall PaymentRequest message (in the serialized_payment_details variable). What I've tried to highlight is, that:

• your Bitcoin public key (message Payment Details { repeated Output outputs })  
• the Merchant's message for details of the request (message Payment Details { optional string memo })
• your IP (message Payment Details { optional string payment_url })

That is not YOUR IP. It's the merchant's return URL where the payment message is sent and a payment ack is retrieved.

are all contained in the presiding message PaymentRequest variable {required bytes serialized_payment_details}.

If you look at the description in the section for the PaymentsRequest message that describes the composition of the signature, also bolded, you'll see that the PaymentRequest message itself is hashed using the public key (optionally) provided by the merchant.

the message isn't "hashed using the public key". It's simply hashed. And it's signed with a private key. This all happens on the merchant's server.

What concerns me is that I have no idea whether the data in the Payments Details (non-mandatory as some of it is) can be somehow cajoled into something meaningful,

I think that you're not entirely up to date on what hashing does. It is nothing more than jumbling together the input data in a thoroughly destructive manner that produces an output that is impossible to reverse. This is a reproducible operation. Meaning, every time you feed it the same input data, it will produce the same output hash.

given that the nature of the hashing of this information involves using a certificate to authenticate that some of the contents of the hash are verifiable.

You've got it the wrong way around. The PaymentRequest is hashed using either SHA1 or SHA256 and that hash is then signed using the private key. The reason that is uses a hash is because of how the signature function works. It's simply an irrelevant implementation detal.

This signature can then be verified using the public key contained in the merchant's certificate. The merchant's certificate is verified using the rest of the chained certificates in the PaymentRequest, all the way up until the ROOT certificate is needed, which is either already present on your computer or can, as the BIP suggests, be requested from the Mozilla Root Store. At no point is any information in this process sent to the CA.

The PKI public key of the merchant must be positively identified from within the hash of the information, so is the rest of the hashed information also safe?

No, wrong way around. You cannot extract information from a hash. That's the sole purpose of hashing; producing a reproducible number that cannot be reversed.

[Carlton Banks]

The bitcoin client does not connect to the CA.

Stop repeating clueless people.

Which bitcoin client? The users or the merchants? Some party can do so, whether it's through the Bitcoin client or not.

It would reflect better on the core devs if they were not defensive, aversive, or insulting in their participation. I'm coming entirely from the perspective of asking questions, and attempting to answer them myself after the dev team member I was speaking to before hand reverted to being insulting, aversive and defensive.

You guys are all following the same pattern, and yet there is a distinct lack of any honest attempt to clarify. You keep focusing on the people asking the questions, and not answering the questions posed.

[riplin]

Where do you get the root certificates from?

People have already told you several times that the root certificates are either already present on your computer (supplied by the operating system) or can be fetched from the Mozilla Root Store.

Or let me ask otherwise, make it a simpler question: which openssl function do you use to verify a certificate and the message,

You don't need openssl to test if a certificate is valid. you can use any crypto library you fancy. depending on the crypto method used, this could be an RSA library or an EC library.

and how do you know what this function does inside?

Because we took the time to figure that out? You should try it some time.

[piotr_n]

and how do you know what this function does inside?

Because we took the time to figure that out? You should try it some time.

But you did not tell me which function, nor any other specifics that I asked about.
E.g.: how do you know which root certificates are installed in the system? Let's say Windows...

So it's totally cool that you play a smart ass pretending that you know how it works, but before you can explain me the details, I cannot really assess if you are not just playing stupid

[riplin]

It would reflect better on the core devs if they were not defensive

And it would reflect better on you if you tried to actually figure out some of the basics first. You've shown a significant lack of understanding of even something as simple and instrumental as a hash function.

aversive, or insulting in their participation. I'm coming entirely from the perspective of asking questions, and attempting to answer them myself after the dev team member I was speaking to before hand reverted to being insulting, aversive and defensive.

You guys are all following the same pattern, and yet there is a distinct lack of any honest attempt to clarify. You keep focusing on the people asking the questions, and not answering the questions posed.

There have been multiple clarifying posts in this thread, yet you continue to ignore them.

[kjj]

It's not about OCSP. It's about the fact that you are displaying wilful ignorance.

Well, at least I'm not lying.

Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.

Links?  I could only find one, and I have no idea why he thinks that anything related to the transaction would ever be sent to the CA.

Given the circumstance in which the CA system produces the signature for the Payment Request message, how can a valid signature be produced that the CA did not sign?

Ahh.  The problem then is that you don't know how SSL PKI works.

The CA generates a private key, and a matching public key.  The pubkey is packaged into a certificate, which is then signed by the privkey (which is funny, because it is a self-signature, but it still provides some assurances).  They then publish that certificate.

The merchant generates their own private key and the matching pubkey.  They package that into a certificate with some identifying information, which is sent to the CA.  The CA signs the merchant certificate with their private key and sends it back.

The merchant then generates a payment request, hashes it, and signs the hash with their private key.

You get the request, the signature and the certificate.  Your software verifies that the attached certificate does indeed correspond to the signature.

To verify that the certificate you are looking at does indeed belong to the vendor you think it belongs to, your client checks that the certificate it received has been signed by a trusted CA.  In this simple example, the CA's published pubkey has been included in the client through some out-of-band mechanism (hardcoded into the source maybe).

You will notice that at no time during your transaction is anything sent to the CA.  The CA isn't signing your specific message, they already signed the merchant's certificate, and the merchant's private key is used to sign the request.

There are two wrinkles that can be added to the simple example.  The first is when the CA doesn't sign your certificate directly.  In that case, the merchant sends a certificate chain.  Your client then follows the chain backwards, making sure that the merchant's cert has been signed by X, and that X was signed by Y, and so on until certificate Z was signed by the CA.

The second is OCSP.  In OCSP, your client can look in the merchant certificate for a field specifying the OCSP server.  Your client can then ask the OCSP server if the certificate it is looking at is still valid.  If the certificate was signed in error, or if the private key for it was stolen from a compromised server, you can find that out in real time using OCSP, and potentially reject the transaction despite having valid signatures.

(There is also a variation of OCSP called OCSP stapling where the server, rather than the client, requests proof of validity from the OCSP server and attaches it to the certificate.  This is better for privacy, since your client doesn't then need to tell the CA that someone from IP address X is checking on the certificate issued to Y.  OCSP already has a timestamp and a validity window, and are signed, so it doesn't really matter who asks for it or which servers it passes through in transit.)

[riplin]

and how do you know what this function does inside?

Because we took the time to figure that out? You should try it some time.

But you did not tell me which function, nor any other specifics that I asked about.

Sigh.

https://github.com/sipa/secp256k1/blob/master/src/secp256k1.c

line 23, secp256k1_ecdsa_verify:

Code:

int secp256k1_ecdsa_verify(const unsigned char *msg, int msglen, const unsigned char *sig, int siglen, const unsigned char *pubkey, int pubkeylen) {
    int ret = -3;
    secp256k1_num_t m; 
    secp256k1_num_init(&m);
    secp256k1_ecdsa_sig_t s;
    secp256k1_ecdsa_sig_init(&s);
    secp256k1_ge_t q;
    secp256k1_num_set_bin(&m, msg, msglen);

    if (!secp256k1_ecdsa_pubkey_parse(&q, pubkey, pubkeylen)) {
        ret = -1;
        goto end;
    }
    if (!secp256k1_ecdsa_sig_parse(&s, sig, siglen)) {
        ret = -2;
        goto end;
    }
    if (!secp256k1_ecdsa_sig_verify(&s, &q, &m)) {
        ret = 0;
        goto end;
    }
    ret = 1;
end:
    secp256k1_ecdsa_sig_free(&s);
    secp256k1_num_free(&m);
    return ret;
}

E.g.: how do you know which root certificates are installed in the system? Let's say Windows...

http://technet.microsoft.com/en-us/library/cc754841.aspx

[Carlton Banks]

Ok, so the signature sent to the user is composed by the merchant, and the hash does what hashing should.

Can someone explain then why the signature is sent to the user, if the user does not verify it with the CA themselves? (given the case where using the CA system is used)

Can someone explain then why the signature must contain a hash of the Request Details? Just saying "it doesn't matter what data is hashed" suggests that any data could be used in place of the Request Details.

[piotr_n]

and how do you know what this function does inside?

Because we took the time to figure that out? You should try it some time.

But you did not tell me which function, nor any other specifics that I asked about.

Sigh.

https://github.com/sipa/secp256k1/blob/master/src/secp256k1.c

line 23, secp256k1_ecdsa_verify:

Are you fucking kidding me?
I've gone though every single line of sipa's code and I can guarantee you that it has nothing to do with any SSL certificates whatsoever.
Don't dare to blame this mess on the guy - he is one of a few left, if not the only one, who actually do a useful work for the satoshi client.

http://technet.microsoft.com/en-us/library/cc754841.aspx

Thank you!
And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server.

[kjj]

Ok, so the signature sent to the user is composed by the merchant, and the hash does what hashing should.

Can someone explain then why the signature is sent to the user, if the user does not verify it with the CA themselves? (given the case where using the CA system is used)

Can someone explain then why the signature must contain a hash of the Request Details? Just saying "it doesn't matter what data is hashed" suggests that any data could be used in place of the Request Details.

The point of the signature itself is that it is now impossible to change the signed data without invalidating the signature.  Things that are important need to be included in the signed portion.  It would be pointless to sign a transaction request message that didn't include the Request Details in the signature, as the details could then be changed by anyone, at any time.

The certificate, and the CA's signature on the certificate, is to connect that certificate (and by extension, signatures made by the corresponding private key) with a real world identity.  In theory, the CA will not sign any random certificate they see, but will only sign the ones that appear to come from the entity named in the certificate.

Anyone can be a CA and sign whatever certificates we want.  But no one will trust your CA's signatures (and by extension, the certificates signed by you) unless you are a serious organization committed to only signing valid certificates.  The nominal reason why browser vendors charge thousands of dollars for including a certificate in their browser is because the browser vendor needs to audit (or hire an audit of) the alleged CA's policies and practices to ensure that certs signed by the CA will be trustworthy.

[riplin]

Are you fucking kidding me?
I've gone though every single line of sipa's code and I can guarantee you that it has nothing to do with any SSL certificates whatsoever.
Don't dare to blame this mess on the guy - he is one of a few left, if not the only one, who actually do a useful work for the satoshi client.

I was being facetious. The signature verification for an X.509 certificate is determined by the certificate itself.  It's nothing more than a basic crypto function and it doesn't need to connect to any 3rd party in order to verify if a signature is produced by the private key that a specific certificate represents.

see http://en.wikipedia.org/wiki/X.509 for details.

[riplin]

And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server.

What if it does. What if you request the root certificate of CA "DERP" and it connects to that CA to fetch that certificate. What information is shared, other than that it requested that specific root certificate?

Nothing. The CA has no idea what you need that certificate for.

[Carlton Banks]

It would reflect better on the core devs if they were not defensive

And it would reflect better on you if you tried to actually figure out some of the basics first. You've shown a significant lack of understanding of even something as simple and instrumental as a hash function.

aversive, or insulting in their participation. I'm coming entirely from the perspective of asking questions, and attempting to answer them myself after the dev team member I was speaking to before hand reverted to being insulting, aversive and defensive.

You guys are all following the same pattern, and yet there is a distinct lack of any honest attempt to clarify. You keep focusing on the people asking the questions, and not answering the questions posed.

There have been multiple clarifying posts in this thread, yet you continue to ignore them.

I wouldn't be asking any questions, or attempting to provide my own answers if I either fully understood all of this, or if the devs weren't being awkward about it. I don't know whether you've noticed, but the stakes in this here Bitcoin system are worth money, being as it is that it is money. I kind of take an interest in the way the design and the infrastructure works, so unless being rightfully inquisitive isn't disrespectful or uncalled for, I will reserve the right to ask as many questions and get as many details wrong as it takes. Getting it wrong is not criminal, and it certainly doesn't disqualify anyone from asking more questions, the opposite if anything.

[piotr_n]

Are you fucking kidding me?
I've gone though every single line of sipa's code and I can guarantee you that it has nothing to do with any SSL certificates whatsoever.
Don't dare to blame this mess on the guy - he is one of a few left, if not the only one, who actually do a useful work for the satoshi client.

I was being facetious. The signature verification for an X.509 certificate is determined by the certificate itself.  It's nothing more than a basic crypto function and it doesn't need to connect to any 3rd party in order to verify if a signature is produced by the private key that a specific certificate represents.

see http://en.wikipedia.org/wiki/X.509 for details.

Right.
You know everything, except the basic function's name..
Well, thank you for sharing your valuable knowledge with me

[riplin]

Right.
You know everything, except the function's name..
Well, thank you for sharing your valuable knowledge with me

Because it's completely irrelevant. It's a set of crypto functions, depending on which signing algorithm is used.  The one thing I do know about these functions is that they are given all the required input data in order to verify if a signature is valid. and that's a hash of the data, depending on the hash algorithm used (SHA1, SHA256, whatever), the public key, and the signature. No other information is needed in order to verify a signature.


You somehow think that you've "won" the discussion simply because I can't tell you the name of the required function. This type of discussion is also referred to as "pigeon chess":

Refers to having a pointless debate with somebody utterly ignorant of the subject matter, but standing on a dogmatic position that cannot be moved with any amount of education or logic, but who always proclaims victory.

Origin:
"Debating piotr_n on the topic of the payment protocol is rather like trying to play chess with a pigeon; it knocks the pieces over, craps on the board, and flies back to its flock to claim victory."

[kjj]

I wouldn't be asking any questions, or attempting to provide my own answers if I either fully understood all of this, or if the devs weren't being awkward about it. I don't know whether you've noticed, but the stakes in this here Bitcoin system are worth money, being as it is that it is money. I kind of take an interest in the way the design and the infrastructure works, so unless being rightfully inquisitive isn't disrespectful or uncalled for, I will reserve the right to ask as many questions and get as many details wrong as it takes. Getting it wrong is not criminal, and it certainly doesn't disqualify anyone from asking more questions, the opposite if anything.

If you go ask a cardiac surgeon to explain how a multiple bypass surgery works, and every time he starts to answer you interrupt him by asking how that step helps to balance the humors, or some other pseudomedical nonsense, he's pretty likely to quickly become exasperated.  If you are the twelfth guy this week to pull that stunt, he may not be entirely polite when he tells you to come back when you have a better grasp on medicine.

I'm sorry that the devs didn't have time to spoonfeed "How the Internet Works, Volume 7: SSL" to you.  But this is the age of Google.  It is within your own capability to educate yourself enough to ask meaningful questions.

[piotr_n]

And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server.

What if it does. What if you request the root certificate of CA "DERP" and it connects to that CA to fetch that certificate. What information is shared, other than that it requested that specific root certificate?

Nothing. The CA has no idea what you need that certificate for.

What it does - is not so important.
What is important is that you have no clue what it does - and that's dangerous. For privacy, I mean.
I cannot believe that I even need to explain it here

From what I see ATM nobody seems to really know what it does.
It needs to be established on IRC first, but we can be sure that results will be positive...

[riplin]

And now tell me that using this API you have no reason to suspect that it will ever connect to a CA's server.

What if it does. What if you request the root certificate of CA "DERP" and it connects to that CA to fetch that certificate. What information is shared, other than that it requested that specific root certificate?

Nothing. The CA has no idea what you need that certificate for.

What it does - is not so important.
What is important is that you have no clue what it does - and that's dangerous. For privacy, I mean.

Hardly. Root CA's are used to sign hundreds, if not thousands of certificates. The CA has absolutely no clue which certificate you're trying to verify.

[riplin]

From what I see ATM nobody seems to really know what it does.

From what I see here, there are only a few that don't know what it does, you being one of them.

[Mike Hearn]

Perhaps we need a basic tutorial somewhere on how X.509 / PKIX works. I didn't go into details in the payment protocol FAQ because I thought people would research this if they didn't already know.

A lot of the frustration and talking past each other in this thread and elsewhere makes a lot more sense now it's clear that some people have a garbled understanding of how certificates and the PKI operate. This article is reasonable:

http://en.wikipedia.org/wiki/X.509

piotr_r, you can see the code that verifies payment requests here:

https://github.com/gavinandresen/paymentrequest/blob/master/c%2B%2B/paymentrequest-dump.cpp

Look for the functions that begin with X509_ or EVP_ to see which functions manage in it OpenSSL. Or look at the Java implementations for one that's not OpenSSL:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/validator/PKIXValidator.java?av=f

[piotr_n]

From what I see ATM nobody seems to really know what it does.

From what I see here, there are only a few that don't know what it does, you being one of them.

As for a guy who has just refereed me to a source code of ECDSA verify function, after I had asked him for the function name that verifies the SSL certificate, you seem to be pretty funny advertising your expertise in the matter

[riplin]

As for a guy who has just refereed me to a source code of ECDSA verify function, after I had asked him for the function name that verifies the SSL certificate, you seem to be pretty funny advertising your expertise in the matter

I already told you that I was being facetious. You asked me for a function that can verify a signature. That was one. Whether or not that's actually used in SSL is irrelevant. I know it's not, but the inputs to that function are exactly the same as the function you requested. Hash, public key, signature. output: true / false.

For what it's worth, ECDSA is one of the algorithms supported by X.509: http://tools.ietf.org/html/rfc5758

[piotr_n]

Perhaps we need a basic tutorial somewhere on how X.509 / PKIX works. I didn't go into details in the payment protocol FAQ because I thought people would research this if they didn't already know.

A lot of the frustration and talking past each other in this thread and elsewhere makes a lot more sense now it's clear that some people have a garbled understanding of how certificates and the PKI operate. This article is reasonable:

http://en.wikipedia.org/wiki/X.509

piotr_r, you can see the code that verifies payment requests here:

https://github.com/gavinandresen/paymentrequest/blob/master/c%2B%2B/paymentrequest-dump.cpp

Look for the functions that begin with X509_ or EVP_ to see which functions manage in it OpenSSL. Or look at the Java implementations for one that's not OpenSSL:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/validator/PKIXValidator.java?av=f

Thanks Mike.
I hope you don't take my comment personally and you understand that you work for Google while I work for the people.
We play for different teams, but it doesn't mean we cannot play fair.

So, let's get into X509_verify_cert

A complete description of the process is contained in the verify(1) manual page.

And this is the verify(1) manual page: http://www.manpagez.com/man/1/verify/

Do you still claim that there is no way that the bitcoin client can leave my IP a CA server, when you just use this function?
I am not saying that it does - I am just saying that it isn't totally clear what this function actually does. And I'm betting that it's also not totally clear for you.

[Carlton Banks]

Ok, so the signature sent to the user is composed by the merchant, and the hash does what hashing should.

Can someone explain then why the signature is sent to the user, if the user does not verify it with the CA themselves? (given the case where using the CA system is used)

Can someone explain then why the signature must contain a hash of the Request Details? Just saying "it doesn't matter what data is hashed" suggests that any data could be used in place of the Request Details.

The point of the signature itself is that it is now impossible to change the signed data without invalidating the signature.  Things that are important need to be included in the signed portion.  It would be pointless to sign a transaction request message that didn't include the Request Details in the signature, as the details could then be changed by anyone, at any time.

Ok, so only the holder(s) of the merchant's privkey can verify that the signature is a hash of the Payment Request. The merchant's certificate cannot be used to do this. Is this right?

If so, I still fail to understand the necessity of hashing the Request Details and signing that. The end user cannot verify that the hash is a result of such a hashing operation, and they are the only recipient of this signature. Only the merchant should be able to ascertain that the signature is generated by signing a hash of the Request, and they have no apparent need to verify this, being as they presume to have collected the details in a direct https session with the user.

Why use the Payment Details, which the merchant should be confident of anyway?

[riplin]

Do you still claim that there is no way that the bitcoin client can leave my IP a CA server, when you just use this function?
I am not saying that it does - I am just saying that it isn't totally clear what this function actually does. And I betting that it's also not totally clear for you.

Code:

-CApath directory
           A directory of trusted certificates. The certificates should have
           names of the form: hash.0 or have symbolic links to them of this
           form ("hash" is the hashed certificate subject name: see the -hash
           option of the x509 utility). Under Unix the c_rehash script will
           automatically create symbolic links to a directory of certificates.

       -CAfile file
           A file of trusted certificates. The file should contain multiple
           certificates in PEM format concatenated together.

So you need to supply your own trusted root certificates.

[Mike Hearn]

Look, it's late and I'm tired. If you want to learn OpenSSL then go read the documentation instead of demanding personalised tutorials whilst simultaneously talking crap about my coworkers. Your attitude reveals you to be both obnoxious and incompetent.

For example, you could start here:

http://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_flags.html

and in particular this statement:

If CRLs checking is enable CRLs are expected to be available in the corresponding X509_STORE structure. No attempt is made to download CRLs from the CRL distribution points extension.

Seriously Piotr, this stuff isn't rocket science. If you aren't capable of understanding it yet then go and read documentation until you do, then come back.

[piotr_n]

I am not saying it is a rocket science - I am saying that OpenSSL is a one big mess and nobody knows what it really does these days.
Come on, you must know life; how much you can actually rely on any documentation? OpenSSL is surely no exception.
Mind that you have just quoted "Bugs" section of the doc, to support your statement that "No attempt is made to download CRLs from the CRL distribution points extension".

If my fate is about to be judged on whether you set a flag or not while calling the lib, and whether this flag actually does what the man page says it should - then I would rather stay away from such a secured payment solution. And I will be advising people to do the same, if you don't mind.

[grau]

While I assume that you integrate these protocols with extreme care, they are hairball on their own with lots of flavors and options. Adding them is the exact opposite of what I would like to see happening to the reference client.

Is there a hope for a standard build without payment protocol, like the no wallet option jgarzik worked on?

[piotr_n]

Yeah, that would be cool.
A no-GUI node with a block-parser only, no wallet and as few external dependencies as possible, even without UPnP.
Instead of adding more mess to the existing one...

[justusranvier]

Yeah, that would be cool.
A no-GUI node with a block-parser only, no wallet and as few external dependencies as possible, even without UPnP.

It's called btcd.

[metacoin]

Yeah, that would be cool.
A no-GUI node with a block-parser only, no wallet and as few external dependencies as possible, even without UPnP.
Instead of adding more mess to the existing one...

Hopefully this soon becomes a reality. In Gavin's blog post today, he mentioned the goal of making the client less monolithic and more modular. This is absolutely a step in the right direction.

We are (slowly) moving from a monolithic code base that does everything (wallet, RPC, network, blockchain storage/validation) towards more modular internals with fewer dependencies between the different pieces. Another change you should see in the 0.9 release is moving away from the bitcoind executable functioning both as a server and as a RPC client– Wladimir J. van der Laan split the RPC client functionality (“tell the running bitcoin daemon to do THIS”) into a separate executable, ‘bitcoin-cli’.  The RPC client code will eventually be removed from bitcoind, but will be kept for backwards compatibility for a release or two.

https://bitcoinfoundation.org/blog/?p=290

[Carlton Banks]

I'd just like to make the general point that if we were all perfectly aware of every factor that affects this new introduction pertaining to all wider contexts, then there wouldn't really be anything to discuss. Sort of a general principle to the concept of discussions, really.

Those that complain about me and others being ignorant of everything that they themselves already know should get a grasp of the limits of their own perceptions. Your expert level of understanding is by definition exceptional. Opening it up to discussion, but making any reasonable discussion conditional on us all being versed in everything you know is clearly never going to be productive. We do need to get your comments on the implications of this proposal, your comments are the most relevant of all contributors, seeing as you guys know this software better than anyone else. Some don't trust your motives for the introduction, others like me don't know either way and would like to take the opportunity proposed by the creation of this thread to, as described, discuss the proposal. It seems as if the very idea that broaching subject of whether this protocol endangers the privacy or identity of the user is being taken as an offense, and I am sorry if that's how you feel, but it's unavoidable given the wider circumstances. If you know you're acting with the best intentions, then having your integrity questioned by those that do not understand the whole as completely as you do must be frustrating. This is no excuse to behave unpleasantly towards those who pose the questions, especially when my own such questions have been posed entirely on the basis of the technical aspects without bringing any aspersion on the good character or technical competence of the core developers who choose to answer the questions. It seems that not all devs can say the same about their own conduct in this thread.

I propose that we should be concentrating on improving the understanding and acceptance of this protocol, not indulging in one-upmanship as a diversion from the topic matter. Anyone would think that this proposal is already reflected in the title of this thread, which is not "Where everyone tears strips off each other to prove who's the biggest computer science know-it-all, under the pretense of discussing some protocol or other". The outcome of the overall consensus of this discussion should be more important to us all than the way this has played out so far.

(plaudits to kjj for writing some good posts overviewing the relevancy of the SSL PKI, a far more useful response than just saying "read up about the entire thing from this overarching article")  

[johnyj]

Sigh, I'm not a technical expert and I don't have time to dig into it either, but I start to understand why central banks control the world by just printing money

We now have the most brilliant monetary system in the world but the designer of the system are talking about business, profit, salary ... Exactly those things made billions of people the slaves of current monetary system while bankers happily print money to keep them working ...

How did those banks achieve this? All they did is very simple: Maintain and strengthen people's trust of their monetary system. They build biggest modern office, paying employee highest salary, strict clothing rules... Just to make sure people always believe that they are trustworthy and professional, and they seldom change their system for decades

But what I saw here is opposite: Once a while devs will come out with a complex change that brings a lot of uncertainty, reduce our trust and increase our confusion. The bitcoin project is quite unstable, not very trustworthy, at least in my opinion

I wish core devs can spend some time on monetary history and macro economy to better understand the devastating power of this project, thus less concerned about trivial things at enterprise level. All the enterprises in the world are still slaves of banks, since they only care about profit and they don't know where those money they made come from

Is there any dev spend enough time studying the meaning of what Satoshi wrote in the genesis block?
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"

[kjj]

Ok, so only the holder(s) of the merchant's privkey can verify that the signature is a hash of the Payment Request. The merchant's certificate cannot be used to do this. Is this right?

If so, I still fail to understand the necessity of hashing the Request Details and signing that. The end user cannot verify that the hash is a result of such a hashing operation, and they are the only recipient of this signature. Only the merchant should be able to ascertain that the signature is generated by signing a hash of the Request, and they have no apparent need to verify this, being as they presume to have collected the details in a direct https session with the user.

Why use the Payment Details, which the merchant should be confident of anyway?

No, in DSA systems, the signature is verified with the public key, but created with the private key.  This way, only the private key holder can create a signature, but anyone can verify it.  The certificate is a jumble of stuff, but at heart it is a carrier for the public key and information related to the public key.

This is really the whole point of digital signatures, and the reason why DSA is always done with public key cryptosystems.

I'd just like to make the general point that if we were all perfectly aware of every factor that affects this new introduction pertaining to all wider contexts, then there wouldn't really be anything to discuss. Sort of a general principle to the concept of discussions, really.

Those that complain about me and others being ignorant of everything that they themselves already know should get a grasp of the limits of their own perceptions. Your expert level of understanding is by definition exceptional. Opening it up to discussion, but making any reasonable discussion conditional on us all being versed in everything you know is clearly never going to be productive. We do need to get your comments on the implications of this proposal, your comments are the most relevant of all contributors, seeing as you guys know this software better than anyone else. Some don't trust your motives for the introduction, others like me don't know either way and would like to take the opportunity proposed by the creation of this thread to, as described, discuss the proposal. It seems as if the very idea that broaching subject of whether this protocol endangers the privacy or identity of the user is being taken as an offense, and I am sorry if that's how you feel, but it's unavoidable given the wider circumstances. If you know you're acting with the best intentions, then having your integrity questioned by those that do not understand the whole as completely as you do must be frustrating. This is no excuse to behave unpleasantly towards those who pose the questions, especially when my own such questions have been posed entirely on the basis of the technical aspects without bringing any aspersion on the good character or technical competence of the core developers who choose to answer the questions. It seems that not all devs can say the same about their own conduct in this thread.

I propose that we should be concentrating on improving the understanding and acceptance of this protocol, not indulging in one-upmanship as a diversion from the topic matter. Anyone would think that this proposal is already reflected in the title of this thread, which is not "Where everyone tears strips off each other to prove who's the biggest computer science know-it-all, under the pretense of discussing some protocol or other". The outcome of the overall consensus of this discussion should be more important to us all than the way this has played out so far.

(plaudits to kjj for writing some good posts overviewing the relevancy of the SSL PKI, a far more useful response than just saying "read up about the entire thing from this overarching article")   

I'd like to point out that this is not an expert level discussion, not even close.  This is basic stuff, "Introduction to Cryptography 101" level.  In short, this is stuff that you should already know to participate in discussions in Dev & Tech.

I don't say that to be insulting.  I don't want to drive anyone away.  I don't want to discourage anyone from learning.  I don't want to prevent anyone from contributing to the conversation.  Quite the opposite on all counts, actually.  I have very little time to devote to bitcoin, but most of the time that I do have is spent helping and teaching others, at the expense of time I'd rather be spending on my own projects.

But if someone comes in here and their understanding is not sufficient to making meaningful contributions, they really should spend a lot of time reading silently, or asking very polite questions and reading the answers with great care.  What they should not be doing is repeating nonsense they heard elsewhere or arguing with the dismissive answers they get when they do.

Now let me explain why I'm so hostile to piotr_n.  For the last year or two, there has been a deluge of FUD.  Virtually all changes that have come to public discussion have come under relentless attack, typically by people "asking questions" and spreading misinformation.  Piotr is a good example of this.  Go read his post history and you'll find a fairly complete catalog of recent changes to the bitcoin system.  He is opposed to every single one of them, he thinks that Gavin is the puppet of the Illuminati, and when pressed, he doesn't know a fucking thing about anything he's ever talked about.

But he isn't alone.  Dozens of him have come and gone.  I don't like to assume malice while incompetence is still a viable option, but after a while even the least paranoid among us starts to wonder exactly who wants to undermine the development team and process, and why.

So, again, I apologize to anyone* that has ever been dismissed or answered less than politely.  But no one here is here to educate you, particularly not about the basics, and if you show up saying the sorts of crap that we've been dealing with nonstop for the last year or so, the odds really aren't in your favor.

* With a few exceptions.

[riplin]

Hi Carlton,

Sorry I snapped at you. You kind of got caught in the crossfire.

I'd just like to make the general point that if we were all perfectly aware of every factor that affects this new introduction pertaining to all wider contexts, then there wouldn't really be anything to discuss. Sort of a general principle to the concept of discussions, really.

There would be loads to discuss. New features, other security measures, etc.

Those that complain about me and others being ignorant of everything that they themselves already know should get a grasp of the limits of their own perceptions. Your expert level of understanding is by definition exceptional. Opening it up to discussion, but making any reasonable discussion conditional on us all being versed in everything you know is clearly never going to be productive.

The problem is, it's not a discussion if some parties are not educated in some of the core technologies that are being used in the payment protocol. I for example could not have any kind of meaningful discussion with a quantum physicist, simply because I don't know anything about the subject matter. I can ask him loads of questions, but me making any kind of statement on the subject at hand would be foolish.

We do need to get your comments on the implications of this proposal, your comments are the most relevant of all contributors, seeing as you guys know this software better than anyone else.

Ok, I'll try to summarize what the payment protocol is trying to solve (at least, the way I see it, correct me if I'm wrong).

Right now, when you want to buy alpaca socks, you go to the website, click on the product, click pay and then you're presented with a QR code or a link that you can use to make a payment to the merchant.

There are two problems with this.

1) There's no telling if that QR code or link isn't modified en route to your computer (man in the middle attack);
2) Once the payment has been made, there's no proof that you actually made that purchase.

The first one isn't even a truly big issue. Most likely the webpage you're visiting is already running over SSL. The second one however, proof of purchase, is a big one. If you want to file a dispute (and would want to take the merchant to small claims court), then you want to show the judge some kind of receipt. That's exactly what the payment protocol provides. A signed payment request (tied to the merchant's identity), containing the payment request and the address(es) that you sent your payment to.

That's the gist of it. It has other features, like you can supply a refund address when you make your payment and you optionally get an acknowledgement (but this is optional).

At no point in this communication is the customer required to identify himself. (other than the practical need to supply a shipment address for the product of course).

I'm sure there are more things possible, but that's in layman's terms what it does.

In two words: Consumer protection.

[grau]

1) There's no telling if that QR code or link isn't modified en route to your computer (man in the middle attack);
2) Once the payment has been made, there's no proof that you actually made that purchase.

The first one isn't even a truly big issue. Most likely the webpage you're visiting is already running over SSL. The second one however, proof of purchase, is a big one.

We agree that the first one is not really an issue since every serious webpage works with https:// and a certificate of a well known CA.

The second is an issue not limited to Bitcoin but to any type of payment. Having a cryptographic proof of the payment at customer side would positively distinguish Bitcoin payments.

In my opinion both address generation and digital receipts belong to the webshop's business process facilitated by other tools. There could be a whole lot of business rules influencing how payment is requested and there are already digital bills and regulatory requirements to present a receipt for money taken in (at least in the EU). 

I do not question if goals of payment protocol are noble or that its design is not careful and state-of-the art, but if it should be embedded into the bitcoin protocol server.

I wish for a proof of concept implementation of the payment protocol that is a separate build artifact from the protocol server and ask if this was considered and if why rejected?

[riplin]

The second is an issue not limited to Bitcoin but to any type of payment. Having a cryptographic proof of the payment at customer side would positively distinguish Bitcoin payments.

Yup. Right now there's nothing you can provide as proof, as compared to traditional payment methods, where identities are already linked to CC's and bank accounts, etc.

I wish for a proof of concept implementation of the payment protocol that is a separate build artifact from the protocol server and ask if this was considered and if why rejected?

https://github.com/gavinandresen/paymentrequest


Should give you everything you need to get up and running. I recall that Gavin also had a test page up and running somewhere, but I can't seem to find it right now.

[grau]

I wish for a proof of concept implementation of the payment protocol that is a separate build artifact from the protocol server and ask if this was considered and if why rejected?

https://github.com/gavinandresen/paymentrequest


Should give you everything you need to get up and running. I recall that Gavin also had a test page up and running somewhere, but I can't seem to find it right now.

This is great, but why is it planned to be closely coupled and embedded with the code base of bitcoin-qt in 0.9 ?

[riplin]

I wish for a proof of concept implementation of the payment protocol that is a separate build artifact from the protocol server and ask if this was considered and if why rejected?

https://github.com/gavinandresen/paymentrequest


Should give you everything you need to get up and running. I recall that Gavin also had a test page up and running somewhere, but I can't seem to find it right now.

This is great, but why is it planned to be closely coupled and embedded with the code base of bitcoin-qt in 0.9 ?

I edited my previous comment, but I'll move it here.

It makes sense to roll this into the Bitcoin-QT client (in fact, it would be totally awesome if all bitcoin clients were to support it). It's kind of the same as the mailto: URI handler. It wouldn't make much sense to have a separate app that would handle that for you only to present it to you so you could copy/paste it into your email client.

The payment protocol is proposed to become a standard way for merchants to present payment requests. If everyone were to roll their own solution, it would be really hard for all the wallet developers to support. And as was stated earlier in this thread, this is version 1. Everyone is welcome to propose new features, improvements, etc for an eventual version 2. On top of that, the protocol buffers allow you to add additional fields to the messages that you could use in your own solution to extend the current functionality.

As for the server side, that's what you could use that reference implementation for.

[grau]

It makes sense to roll this into the Bitcoin-QT client (in fact, it would be totally awesome if all bitcoin clients were to support it).

Would it not be easier to achieve wide support by implementing the payment protocol self contained, so it can be connected to other wallet implementations?

I know, bitcoin-qt does not currently have interfaces to allow such loose coupling, but should that be the excuse to embed yet an other complex protocol instead of implementing a better interface?

We do suffer under a monolithic reference implementation and this extension, if added as usual, compounds the problem.

[riplin]

It makes sense to roll this into the Bitcoin-QT client (in fact, it would be totally awesome if all bitcoin clients were to support it).

Would it not be easier to achieve wide support by implementing the payment protocol self contained, so it can be connected to other wallet implementations?

I know, bitcoin-qt does not currently have interfaces to allow such loose coupling, but should that be the excuse to embed yet an other complex protocol instead of implementing a better interface?

We do suffer under a monolithic reference implementation and this extension, if added as usual, compounds the problem.

If you look at the C++ code, it's quite minimal. ~600 lines of code total. The bulk of the work is probably UI handling, database storage, etc. That's all pretty specific per wallet implementation. I personally don't think it's going to be too big of an issue.

[wumpus]

I know, bitcoin-qt does not currently have interfaces to allow such loose coupling, but should that be the excuse to embed yet an other complex protocol instead of implementing a better interface?

How would that help? It'd put another program between the wallet client and the web browser which does what, exactly? The payment request interface as it is now is pretty well documented (https://en.bitcoin.it/wiki/BIP_0070), and if you have questions you can always ask them on the mailing list or IRC channel. I don't get what would be gained with another interface.

IMO it's much better if the different wallet clients simply implement the payment protocol themselves. If you've gone all the way to implement a bitcoin client, which is an impressive feat, adding the payment protocol functionality is easy and relatively well documented and easily testable.

[jgarzik]

This is great, but why is it planned to be closely coupled and embedded with the code base of bitcoin-qt in 0.9 ?

bitcoin: URI hander.

[grau]

If you've gone all the way to implement a bitcoin client, which is an impressive feat, adding the payment protocol functionality is easy and relatively well documented and easily testable.

I did not re-implement a "bitcoin client" but a protocol server facing P2P and other modules that connect to the protocol server using its message bus.

Those modules implement wallets, exchanges, a payment processor and more to come. The payment protocol is a puzzle that will fit into some modules or be implemented as part of specific business processes.

I would eventually replace my protocol server with the reference client if it was moving into a direction of being extensible instead of embedding yet an other proof of a concept. I agree with the concept but not the implementation and the priority it enjoys.

[Crowex]

1. Merchant pays for a certificate from a certificate authority, and
then gives the payment service the certificate and their private key.
This could be the same certificate and private key as is used for the
merchant's web site, but best security practice would be to purchase a
separate certificate for authenticating Invoices.


why is it best security practice to buy a separate certificate?
if I trust the original website authentication and encryption then why wouldn't I trust it to sign the invoice and know that the person who signed the invoice is the one that I have been communicating with.
If I don't trust the original certificate then why would getting a separate certificate give me any more confidence.
I don't understand the security advantages of a separate certificate?

[johnyj]

Just because there have been security breaches, doesn't mean that the system is useless.  While the system could be improved, the alternatives are terrible.  If you don't use an established system, then you need to build up a whole new "web of trust", and users and merchants will be doing a lot of work, outside an established system, just to accommodate this use case (Bitcoin payments).

This put it very well

The spirit of bitcoin is "trust no one but the network", since human are always prone to failure. So, build up a trust of web will just end up like today's system where a few highly trusted elites sitting at the top deciding people's fate, and when they run into a crisis, they turn to government asking for bailout

Of course it is convenient for children to find a trustworthy authority to rely on, but adults should manage their own risk individually. If everyone know how to manage risk by themselves and don't blindly trust authorities like banks and institutions, they won't run into this financial crisis

My opinion is that user should manage their own risk in payment. If they have a good risk management strategy, and accidentally lose some money, that should not impact them too much

And from risk management point of view, this move is also risky for bitcoin, because it is a large change. If it caused some unforeseeable problem in future, it will spread negative sentiment for bitcoin, sink its value, thus impact all bitcoin users (majority of bitcoin users use it as a store of value)

Third party payment solution will not affect bitcoin network, thus much less risky for bitcoin's robustness. I think an interface for third party payment solution to connect to is much better in this case

[kjj]

1. Merchant pays for a certificate from a certificate authority, and
then gives the payment service the certificate and their private key.
This could be the same certificate and private key as is used for the
merchant's web site, but best security practice would be to purchase a
separate certificate for authenticating Invoices.


why is it best security practice to buy a separate certificate?
if I trust the original website authentication and encryption then why wouldn't I trust it to sign the invoice and know that the person who signed the invoice is the one that I have been communicating with.
If I don't trust the original certificate then why would getting a separate certificate give me any more confidence.
I don't understand the security advantages of a separate certificate?

By definition, the https certificate and private key must be on the front line.  Keeping that private key secure is a gigantic pain in the ass, and pretty much no one bothers doing it right.  They are pretty much disposable.

The invoice key, however, can sit safely on a hardened back end box, well insulated from the outside world.  Depending on the implementation, you can also store it encrypted with the encryption key stored only in non-swapped memory.  (You can do the encryption thing on a webserver too, but no one ever does.*  Think load balancers and cloud servers starting up without human intervention.)

So, while the two offer little difference in security, it is still a "best practice" to do things right, when possible.

* For certain values of "no one".  I used to work in a datacenter, and one of our customers had their webserver configured for security.  We had to physically key in the decryption key for the certificate's private key every time the server rebooted.  Everyone hated that box, I think including the customer.

[gmaxwell]

And from risk management point of view, this move is also risky for bitcoin, because it is a large change.

Huh?

[Carlton Banks]

Ok, so only the holder(s) of the merchant's privkey can verify that the signature is a hash of the Payment Request. The merchant's certificate cannot be used to do this. Is this right?

If so, I still fail to understand the necessity of hashing the Request Details and signing that. The end user cannot verify that the hash is a result of such a hashing operation, and they are the only recipient of this signature. Only the merchant should be able to ascertain that the signature is generated by signing a hash of the Request, and they have no apparent need to verify this, being as they presume to have collected the details in a direct https session with the user.

Why use the Payment Details, which the merchant should be confident of anyway?

No, in DSA systems, the signature is verified with the public key, but created with the private key.  This way, only the private key holder can create a signature, but anyone can verify it.  The certificate is a jumble of stuff, but at heart it is a carrier for the public key and information related to the public key.

This is really the whole point of digital signatures, and the reason why DSA is always done with public key cryptosystems.

Ok, I'm following. So this means that the unhashed Payment Details are not required to verify the signature, contrary to my presumption before. Any light to shed on why the Payment Details are used to generate signatures at all? They themselves form no part of the verification. Is it useful (for security?) to have some piece of "unique to this transaction" data to generate the signature? I appreciate that the hashed Payment Details are not being sent to the CA, so if anything they're more vulnerable when sent SSL encrypted, but not hashed, to the user from the merchant (as well as from the user to the merchant in the first instance). There must be a good reason to hash the Payment Details and have them specifically signed and sent to the user for verification against the CA certificate (which the user already possesses locally via a web browser or their OS)!

Sorry about all this, but I'm quite capable of misinterpreting documents like BIP 70 that are pretty concisely defined in their descriptions, now that I can take another look having talked it over.

 

[Crowex]

1. Merchant pays for a certificate from a certificate authority, and
then gives the payment service the certificate and their private key.
This could be the same certificate and private key as is used for the
merchant's web site, but best security practice would be to purchase a
separate certificate for authenticating Invoices.


why is it best security practice to buy a separate certificate?
if I trust the original website authentication and encryption then why wouldn't I trust it to sign the invoice and know that the person who signed the invoice is the one that I have been communicating with.
If I don't trust the original certificate then why would getting a separate certificate give me any more confidence.
I don't understand the security advantages of a separate certificate?

By definition, the https certificate and private key must be on the front line.  Keeping that private key secure is a gigantic pain in the ass, and pretty much no one bothers doing it right.  They are pretty much disposable.

The invoice key, however, can sit safely on a hardened back end box, well insulated from the outside world.  Depending on the implementation, you can also store it encrypted with the encryption key stored only in non-swapped memory.  (You can do the encryption thing on a webserver too, but no one ever does.*  Think load balancers and cloud servers starting up without human intervention.)

So, while the two offer little difference in security, it is still a "best practice" to do things right, when possible.

* For certain values of "no one".  I used to work in a datacenter, and one of our customers had their webserver configured for security.  We had to physically key in the decryption key for the certificate's private key every time the server rebooted.  Everyone hated that box, I think including the customer.

well I suppose I was looking at it from the point of view of the customer and not the merchant.
if you use a different certificate for the invoicing, possibly from a different certificating authority, then how do I know that both of these separate authorities have been able to ascertain that the owners of both certificates are the same? it seems to introduce extra security issues.
I would have thought that best practice would have been to use the same certificate seeing as the main focus of this in the first place was to provide the customer with a provably authentic receipt.


 of course if we're talking about best practice in terms of key management it might be considered that if you can't manage one key properly then you'll do a better job with two?
 i am sure that in reality the invoice keys would be signing stuff dynamically and would not necessarily be any more insulated from the outside world than any other private key being used for encryption - unless you were going to manually sign each invoice away from the server.

 I am being picky here but using two different certificates, possibly from different authorities does technically introduce other problems into any authentication protocol.
 

[johnyj]

And from risk management point of view, this move is also risky for bitcoin, because it is a large change.

Huh?

Maybe it is not (anyway I don't think bitcoin will be used as a payment medium at large scale due to liquidity problem), but judging from the extensive amount of explanation in BIP70, I can't say it is a minor change

[gmaxwell]

Maybe it is not (anyway I don't think bitcoin will be used as a payment medium at large scale due to liquidity problem), but judging from the extensive amount of explanation in BIP70, I can't say it is a minor change

It's a new, additional thing, not a change. It's also pretty simple: BIP70 without the motivation boiler plate fits on a single page. Effectively you're faulting something for being well documented.  It's not well documented because its complex or risky, its well documented so that other people will have a maximally easy time implementing it correctly.

The implementation in bitcoin-qt is under 1000 lines of code, not counting UI message text. The patch between git where the payment request support was integrated in late July and now is 23,615 lines long, and 26,059 lines for the patch to go one further version back. The patch between current git and v0.8.5 is 114,129 lines long... so from a pure lines of code change complexity it's probably about 3% or so of what will be in 0.9 vs 0.8.5.  Not really a smart metric, but since it's largely a free standing feature the impact to other things is even smaller.

[kjj]

Ok, I'm following. So this means that the unhashed Payment Details are not required to verify the signature, contrary to my presumption before. Any light to shed on why the Payment Details are used to generate signatures at all? They themselves form no part of the verification. Is it useful (for security?) to have some piece of "unique to this transaction" data to generate the signature? I appreciate that the hashed Payment Details are not being sent to the CA, so if anything they're more vulnerable when sent SSL encrypted, but not hashed, to the user from the merchant (as well as from the user to the merchant in the first instance). There must be a good reason to hash the Payment Details and have them specifically signed and sent to the user for verification against the CA certificate (which the user already possesses locally via a web browser or their OS)!

Sorry about all this, but I'm quite capable of misinterpreting documents like BIP 70 that are pretty concisely defined in their descriptions, now that I can take another look having talked it over.

No, the payment details are needed for verification.

You sign by putting (private key, message) into the signing function, and you get back a signature.  You verify by putting (public key, signature, message) into the verification function, and you get back a boolean.

Inside both of those functions, the message is hashed, and the hash is used internally.*

The idea is that the merchant can say "I will ship item X to you, if Y bitcoins show up at address Z".  They then sign that message (which involves hashing the message and then, ahem, "multiplying"** the hash by their private key) and then they send you (public key [in certificate form], signature, message).

You then stuff (public key, signature, message) into the verification function, and it will hash the message, then "multiply" the message hash by the public key, and then check to see if the product it calculated bears the proper relationship to the signature**.  It then returns TRUE or FALSE.

At this point, if the verification returned TRUE, you know with certainty that the message in question was signed by the private key that corresponds to the public key you are looking at.

Note that you explicitly do not know who signed the message yet.  This is where PKI comes in.  I wrote a longer post about PKI earlier, and I won't rehash it all.  But basically, you repeat the signature verification process, but this time the message to be checked is the certificate presented by the merchant, and the public key used for verification is from a certificate provided by someone that you explicitly (or implicitly) trust to only sign certificates that bear verifiable contact information tying the certificate to a real world entity (someone you can sue, basically).

When that is done, you now know that the message was actually signed by a real world entity which has been validated by the CA that you trust for such things.  The last step is to compare the entity information from the certificate against the entity information you were expecting to deal with.  Without this step, an attacker could potentially get a perfectly valid and verified certificate for "Bob's Malware Farm, LLC." and present it to you after hijacking your attempt to log in to your bank's website.  Hopefully, you'll notice that the certificate presented wasn't the "Global Megabank Savings and Theft" certificate that you were expecting and you won't give the attacker your account info.

* The hash function forces the input to the actual signing function to be a known size, which is very useful to the signing function.  Hash functions aren't perfect, but the structure of the message makes it impossible to find working pre-images.  This is a subtle point, but all of our structured signatures would remain safe, even if the hashing function in the signing function were found to be generally insecure. 

** I'm doing a lot of handwaving here.  The signing function isn't really multiply, and I'm not going into detail on how signatures are verified in reality.  This is something you can look up if you want to, for the purposes of this discussion, we can just assume that these functions exist and work correctly.

[Carlton Banks]

No, the payment details are needed for verification.

You sign by putting (private key, message) into the signing function, and you get back a signature.  You verify by putting (public key, signature, message) into the verification function, and you get back a boolean.

Inside both of those functions, the message is hashed, and the hash is used internally.*

The idea is that the merchant can say "I will ship item X to you, if Y bitcoins show up at address Z".  They then sign that message (which involves hashing the message and then, ahem, "multiplying"** the hash by their private key) and then they send you (public key [in certificate form], signature, message).

You then stuff (public key, signature, message) into the verification function, and it will hash the message, then "multiply" the message hash by the public key, and then check to see if the product it calculated bears the proper relationship to the signature**.  It then returns TRUE or FALSE.

At this point, if the verification returned TRUE, you know with certainty that the message in question was signed by the private key that corresponds to the public key you are looking at.

And so the message must be sent to the user, unhashed but encrypted in an SSL session, between the merchant and the user. Otherwise the process described above couldn't work. Ok.

Note that you explicitly do not know who signed the message yet.  This is where PKI comes in.  I wrote a longer post about PKI earlier, and I won't rehash it all.  But basically, you repeat the signature verification process, but this time the message to be checked is the certificate presented by the merchant, and the public key used for verification is from a certificate provided by someone that you explicitly (or implicitly) trust to only sign certificates that bear verifiable contact information tying the certificate to a real world entity (someone you can sue, basically).

Or in the case of someone who illegitimately obtains the private key and certificate of the merchant, someone you possibly or definitely cannot sue (successfully, anyway). I see though how this means zero direct communication with the CA for the user.... even the list of valid (and revoked) certificates must get updated with browser and/or OS updates, and so again, not directly from the CA.

When that is done, you now know that the message was actually signed by a real world entity which has been validated by the CA that you trust for such things.  The last step is to compare the entity information from the certificate against the entity information you were expecting to deal with.  Without this step, an attacker could potentially get a perfectly valid and verified certificate for "Bob's Malware Farm, LLC." and present it to you after hijacking your attempt to log in to your bank's website.  Hopefully, you'll notice that the certificate presented wasn't the "Global Megabank Savings and Theft" certificate that you were expecting and you won't give the attacker your account info.

It's certainly the case that the 1-1 SSL connection where the unhashed Payment Details are sent to the user is a weak link. It would be interesting to know what can be done to mitigate the risk of this part of the scheme being eavesdropped on. Certainly the purpose is to prevent the information being changed by a MITM, but I understand it's still possible to read this information despite the SSL encryption. Or is this also wrong? The technology press has reported otherwise, but it would be nice to hear a different take on what the risks of this are.

[kjj]

And so the message must be sent to the user, unhashed but encrypted in an SSL session, between the merchant and the user. Otherwise the process described above couldn't work. Ok.

No, it doesn't need to be encrypted.  Encryption protects the privacy of the message.  If the parties wish to keep the communication private, it should be encrypted, but encryption isn't necessary for authentication, which is what DSA does.

Because any change to the message will invalidate the signature, the message has become tamper-proof.  You simply reject any messages that don't have a valid signature, so any messages that aren't rejected are known to have come from the signing key without changes.

Or in the case of someone who illegitimately obtains the private key and certificate of the merchant, someone you possibly or definitely cannot sue (successfully, anyway). I see though how this means zero direct communication with the CA for the user.... even the list of valid (and revoked) certificates must get updated with browser and/or OS updates, and so again, not directly from the CA.

That will generally leave a trail.

Also, we have CRLs and OCSP to help us keep track of which certificates are no longer valid, despite having a trusted signature.  CRL is a batched process that involves just downloading the current list from time to time (this is technically communication with the CA, but not of the sort that gets anyone riled up).  OCSP requires communication with the CA, but this can be done by the server instead of the client (stapled OCSP), and at no time involves sending message details to anyone (the protocol allows enough data to identify the certificate, only).

It's certainly the case that the 1-1 SSL connection where the unhashed Payment Details are sent to the user is a weak link. It would be interesting to know what can be done to mitigate the risk of this part of the scheme being eavesdropped on. Certainly the purpose is to prevent the information being changed by a MITM, but I understand it's still possible to read this information despite the SSL encryption. Or is this also wrong? The technology press has reported otherwise, but it would be nice to hear a different take on what the risks of this are.

Well, SSL certainly has weaknesses, but in general, SSL really does allow secure (private) communication.  But it turns out that PKI is really, really hard.  Corporate proxies can use wildcard certificates (signed by actual CAs in some cases) to actively MITM all SSL connections passing through.  Governments can do the same thing, and some have speculated that they might use (or have used) their power to, ahem, request that CAs sign bogus certs that look perfectly correct.  If you run into a situation like that, or if you are merely careless and fail to notice that you've been hijacked by a null-suffix certificate, you can end up having a totally secure communication with an attacker instead of whoever you thought you were talking to.

This comes up a lot in debates about how browsers should handle self signed certificates.  How does a user know that a certificate that has been presented is the right one unless a CA has signed it?  Unless the fingerprint has been sent out of band, and then actually checked, they have no way to know.  See here.

[johnyj]

Maybe it is not (anyway I don't think bitcoin will be used as a payment medium at large scale due to liquidity problem), but judging from the extensive amount of explanation in BIP70, I can't say it is a minor change

It's a new, additional thing, not a change. It's also pretty simple: BIP70 without the motivation boiler plate fits on a single page. Effectively you're faulting something for being well documented.  It's not well documented because its complex or risky, its well documented so that other people will have a maximally easy time implementing it correctly.

The implementation in bitcoin-qt is under 1000 lines of code, not counting UI message text. The patch between git where the payment request support was integrated in late July and now is 23,615 lines long, and 26,059 lines for the patch to go one further version back. The patch between current git and v0.8.5 is 114,129 lines long... so from a pure lines of code change complexity it's probably about 3% or so of what will be in 0.9 vs 0.8.5.  Not really a smart metric, but since it's largely a free standing feature the impact to other things is even smaller.

Even if I change one line of code I could cause a hard fork  

Yesterday I read the core development update from bitcoin foundation, it is very straightforward but leaves a specific link to that Mike's post about this new feature. Judging from amount of posts that debate this new feature, it sure raised lots of new concerns about security and privacy

I worked with CAs some years ago and I know it is a group of greedy enterprises who try all the possible tricks to get people paying money for their certificate, it is very business oriented

http://en.wikipedia.org/w/index.php?title=Certificate_authority&action=view&section=6#Providers

Why trust CAs when you already have the most authoritative CA in the world: the blockchain

[Peter Todd]

Why trust CAs when you already have the most authoritative CA in the world: the blockchain

Please go and implement the code to turn the blockchain into a certificate authority, get Bitcoin-using businesses and people to use it as their primary identity, the one users use to also secure all other communications with those businesses and people, and get back to us so we can add it to the payment protocol specification.

Of course, that's already been done, Namecoin, but no-one uses it.

[johnyj]

Why trust CAs when you already have the most authoritative CA in the world: the blockchain

Please go and implement the code to turn the blockchain into a certificate authority, get Bitcoin-using businesses and people to use it as their primary identity, the one users use to also secure all other communications with those businesses and people, and get back to us so we can add it to the payment protocol specification.

Of course, that's already been done, Namecoin, but no-one uses it.

Wow, that's a good observation! I will have a look at Namecoin, actually I always wondered what is the practical use of Namecoin 

[StarfishPrime]

...

Ok, I'll try to summarize what the payment protocol is trying to solve (at least, the way I see it, correct me if I'm wrong).

Right now, when you want to buy alpaca socks, you go to the website, click on the product, click pay and then you're presented with a QR code or a link that you can use to make a payment to the merchant.

There are two problems with this.

1) There's no telling if that QR code or link isn't modified en route to your computer (man in the middle attack);
2) Once the payment has been made, there's no proof that you actually made that purchase.

The first one isn't even a truly big issue. Most likely the webpage you're visiting is already running over SSL. The second one however, proof of purchase, is a big one. If you want to file a dispute (and would want to take the merchant to small claims court), then you want to show the judge some kind of receipt. That's exactly what the payment protocol provides. A signed payment request (tied to the merchant's identity), containing the payment request and the address(es) that you sent your payment to.

That's the gist of it. It has other features, like you can supply a refund address when you make your payment and you optionally get an acknowledgement (but this is optional).

At no point in this communication is the customer required to identify himself. (other than the practical need to supply a shipment address for the product of course).

I'm sure there are more things possible, but that's in layman's terms what it does.

In two words: Consumer protection.

Finally, a rational real-world business use case for this protocol!

This will clear the courts of frivolous alpaca socks lawsuits. You know, the ones where someone buys alpaca socks, gets scammed by a man-in-the-middle attack, and then sues the online store in small claims court when the site claims they never received payment. Now we'll finally have a cryptographically-signed receipt so that we can subpoena the CA-certificate issuer and get to the bottom of the whole mess as soon as possible.

(sorry Riplin, couldn't resist. It is a good summary of the protocol though!)

[riplin]

2) Once the payment has been made, there's no proof that you actually made that purchase.

So I guess the blockchain is just for show and the signing/verifying messages will be removed now.

Currently, you can prove that you made a payment,  but you can't prove that the merchant owns the address that you sent the funds to.

[gmaxwell]

2) Once the payment has been made, there's no proof that you actually made that purchase.

So I guess the blockchain is just for show and the signing/verifying messages will be removed now.

Currently, you can prove that you made a payment,  but you can't prove that the merchant owns the address that you sent the funds to.

Or what the terms of the agreement were.  "It was a donation!"

And forget courts— though perhaps someday it might matter in those too— it's also about making the case in the court of public opinion. Certainly plenty of people have made fraudulent scam complaints (against business competitors or just for fun), strong evidence for a contract protects both parties and the public in general.

Making strong cryptographic evidence of contracts is an important part of building infrastructure that enables people to freely contract without depending on things like courts to enforce their agreements. Less use of trust and subjective calls and more use of math.

[Peter Todd]

And forget courts— though perhaps someday it might matter in those too— it's also about making the case in the court of public opinion. Certainly plenty of people have made fraudulent scam complaints (against business competitors or just for fun), strong evidence for a contract protects both parties and the public in general.

Real-world example: piuk told me that blockchain.info was moving to CoinJoin transactions for their send-shared service so that there would be transactions in the blockchain that could be used to help stop people from fraudulently claiming the service never forwarded their coins. (they don't keep any logs after all)

With the payment protocol they could have just gave the customer a signed receipt.

[kjj]

Lets back up now, this why we have SSL, we can kinda prove that the page we had with the address came from the valid source we want to pay.

No you can't.  The authentication in SSL is ephemeral.  At no point do you ever possess a document signed by their key.

[gweedo]

Lets back up now, this why we have SSL, we can kinda prove that the page we had with the address came from the valid source we want to pay.

No you can't.  The authentication in SSL is ephemeral.  At no point do you ever possess a document signed by their key.

That is why I said kinda, but if you connected SSL to a site, and a CA says you are connected to the right server you can use that to prove that the page was coming from them. Yes of course Man the middle sets up a fake CA forces all other CA request to go thru him, then yes it isn't.

[gmaxwell]

now my receipt is technically "invalided" cause they revoke that certificate.

uhhh.  So you're saying that every receipt that doesn't have a cryptographic signature on it (meaning basically every receipt which has ever been created in the history of mankind) is "invalid"?

The CA model is weak and lame and mildly exploitative. But what alternative are you suggesting?   This is an optional feature, and if it's used its certainly no worse than if its not used.

The protocol itself is specifically designed to be extensible to other authentication types, but at the moment there don't appear to be any actually useful alternatives, as they arise future extensions can add support for them... and you still have the option of not using the authentication.

[gmaxwell]

No I am not saying that at all.

Then what you are saying makes no sense. If an unsigned receipt is valid then why would a signed receipt be invalid just because a CA was compromised?

[phillipsjk]

I skimmed the whole tread.

Mike Hearn's FAQ helped explain the reasoning behind this: PKI is hard apparently.

I think the hostility to this stems from the fact that the CA system is known to be broken. An attacker will not try to change the "common name"; they will change the payment address: the very thing being hidden by this proposal.

With money on the line, attackers may even be well-funded, purchasing one of those corporate CA spoofing appliances in order to go after a high-value target.

I was also wondering why it was stated as fact that self-signed certificates allow the MITM attack. Later in the thread, somebody even pointed out that CAs themselves use self-signed certificates. The difficulty, hinted at in this link is that X.509 certificates do not allow the end-user to trust a specific CA for a specific domain. All CAs can sign for all domains: which makes me trying to be my own CA for *.economicprisoner.com a very bad idea.

In my experimentation with OpenPGP, I noticed that most people have shockingly lax certificate verification practices. They are confused when you ask for their public key: when you can simply search for their e-mail address or their short-key is included in their mail signature. They don't realize that it is trivial to generate collisions with both of those identifiers. There has essentially been a gentleman's agreement to not do that as far as I can tell. This tells me that even if a "bricks and mortar" business had the fingerprint of their self-signed cert prominently displayed: nobody would actually check it.

PS: To the people hung up on SSL: You can have Certs without using SSL.

TL;DR: I still don't like it, but don't really have a better suggestion at the moment. Namecoin would not work since the first person to grab a specific .bit domain can not be forced to surrender it in the event of a trademark dispute (unless you can get the holder in court somehow).

[Carlton Banks]

I was seeking clarification for this, and the reality is that this is no greater a danger to your privacy when paying than what everyone does today, and it increases the needed attack sophistication to replace a genuine merchant payment address with the address of an attacker.

The danger of any MITM attack with the Payments Protocol is not any privacy leak, but someone using a faked or stolen certificate in combination with further attack code infecting the webmerchant itself, all coming together to allow the attacker to supply their own address for the user to pay, instead of the address belonging to the webmerchant. The Payment Protocol could be tricked into validating the authenticity of the faked/stolen Certificate, and in turn incorrectly verifying the address as being one supplied by the webmerchant. Payment Protocol can't solve this problem, it's an issue with the inherent design of the CA system. But pulling it off successfully is more difficult to engineer than attacking the webmerchant payment methods being used today, hence the barrier to hijacking payments through html web pages are higher with Payments Protocol.

Personal information (like your real name, postal address and the Bitcoin address you pay from) is now and will continue to be transmitted to the merchant over plain old html, or using SSL encrypted htmls sessions if they're using currently considered best practice. What level of security the webmerchant uses to store this information on their servers is another factor. These things have nothing to do with Payment Protocol, it's between you and them: your browser and OS, their webstore software and webserver configuration.

[justusranvier]

A discussion of why the payment protocol should default to using BIP32 extended public keys instead of individual addresses, and a debunking of several common objections:

http://bitcoinism.blogspot.com/2014/01/business-accounting-and-bitcoin-privacy.html

[Peter Todd]

A discussion of why the payment protocol should default to using BIP32 extended public keys instead of individual addresses, and a debunking of several common objections:

http://bitcoinism.blogspot.com/2014/01/business-accounting-and-bitcoin-privacy.html

Or if you want to be able to reveal the address publicly without sacrificing privacy: Stealth Addresses

[Mike Hearn]

A discussion of why the payment protocol should default to using BIP32 extended public keys instead of individual addresses, and a debunking of several common objections:

http://bitcoinism.blogspot.com/2014/01/business-accounting-and-bitcoin-privacy.html

Good article, thanks for writing it.