Topic: Invoices/Payments/Receipts proposal discussion - page 7. (Read 24740 times)

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?

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)

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.

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.

Gavin did you catch my question about colored coin support?

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.

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.

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

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.

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.

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

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

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.

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

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

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?

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)

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

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.

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://bitcointalksearch.org/topic/mass-adoption-of-btc-313029

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

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.

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.

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!".