Invoices/Payments/Receipts proposal discussion

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

[1714867142]

1714867142

[1714867142]

1714867142

[1714867142]

1714867142

[1714867142]

1714867142

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