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

[1714864714]

1714864714

[1714864714]

1714864714

[1714864714]

1714864714

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