Invoices/Payments/Receipts proposal discussion

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

[1714487137]

1714487137

[1714487137]

1714487137

[1714487137]

1714487137

[1714487137]

1714487137

[1714487137]

1714487137

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