Invoices/Payments/Receipts proposal discussion

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

[1714864961]

1714864961

[1714864961]

1714864961

[1714864961]

1714864961

[1714864961]

1714864961

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