Topic: [PROPOSAL] Secure Payment Protocol - page 2. (Read 3584 times)

Not only a base ECDSA key but a base script template for direct payments to multisig outputs.

If we were only interested in ECDSA base keys, couldn't we simply add secp256k1 in addition to P-256 in OpenPGP and distribute base keys via web-of-trust? Should be trivial to change some curve parameters. [EDIT] Seems that ECDSA in openPGP is for the future, just an RFC yet. [/EDIT]


How does having multiple outputs conflict with EC math? Just iterate some number inside the contract. Remember contracts should always be salted for privacy.

Slightly more than that, the customer can create his own PaymentRequest.


Yes, this is orthogonal, so can be ignored for now.


Yes, but if we agree on a standard for a 'labelled wallet' then it's already usable. This is the only thing that strictly needs to be done inside the bitcoin client. Of course, it would be better to agree on other details as well, like the structure of the contracts. But with only labelled wallets implemented you can already do this: connect to a webshop without SSL, have the webshop display an unsigned PaymentRequest, cut and paste it into the bitcoin client as 'label', confirm merchant base key and pay.

Do you really want to base the payment protocol on hierarchical X.509 and root CAs? Personally, I feel great discomfort with that.

I hope your primary thought is wrong and pay-to-contract (call it P2C) is just "slightly more complex despite the assumption that the merchants web server should not have signing keys".
Since nothing gets signed by the merchant at order time, in a way you can also consider it as "less complex because of the assumption that the merchants web server should not have signing keys".


The point of P2C is that no SSL connections are necessary anymore. Example: I go to my local bakery and want to order a birthday cake for tomorrow. The bakery is unexpectedly closed. There is a piece of paper pinned on the door. It says cake A costs 1BTC and cake B costs 2BTC. There is also a table printed on it with the columns "address", "A", "B". I fill out one line with (my home address, 1, 0). I scan a QR-encoded pubkey on the paper with my phone, and, since I have previously shopped with this bakery or otherwise obtained its pubkey, my phone recognizes the pubkey and shows me the name of the bakery, which it has linked to the pubkey. Then I type (home address, 1, 0) into my phone and confirm. Next morning I have one cake A at my door.

All communication between bakery and me can be tampered with by others. But what do they gain? Nothing, except denial-of-service of my order. I may not have a cake, but can show the bakery my receipt and get my money back. They even cannot fool the bakery into making cakes that nobody ordered. So maybe it wasn't so unexpected that the bakery was closed because all their customers  pay with bitcoin

For the online world it means we don't need SSL connections because we don't even need interactive connections. If you are a merchant, just post your order forms somewhere and wait for incoming contracts that customers want to redeem. Check if they are paid for and then start processing the order.


With P2C you still need your 2nd factor on the customer side and the merchant needs some kind of certificate. The point is the merchant doesn't use his certificate to sign anything at order time.
Possibly, he may want to sign the order form before posting them.


The intention of P2C is to make it a scope.

As far as I know, they won't (would you sign data structures containing arbitrary things you didn't understand?)

But one of the things I've been thinking about for post-1.0 payment protocol specs is incrementally better PKI. We could define our own cert type (protobuf message) that can connect onto the end of an X.509 chain that supports whatever features we need. Then we could indeed put a base ECDSA key into the new cert type. It'd also allow merchants to use their SSL cert to derive certs of lower power that they can hand out to agents of the firm - certs that can only be used for signing Bitcoin payments, and which expire much faster than SSL certs would.

Simply deriving a single output using EC math is neat but has a big disadvantage - loss of privacy. The reason the payment spec allows you to specify multiple outputs (and pay with multiple transactions) is so merchants can avoid revealing personal or business financial information via the block chain. It most of the sales to them are for 50 BTC and suddenly one comes along that is 2000 BTC (perhaps you only have a single good on sale that costs that much), it leaks information to have a 2000 BTC output in the block chain. When you next use it to buy something, if the entity you're buying off knows who you are, they can infer what you sold! But if the person who bought the 2000 BTC good breaks up the payments into multiple 50 BTC outputs in multiple transactions, that information leak goes away.

Given the fact that in reality, SSL keys are held in web servers all the time, I'm not convinced the tradeoffs presented in the paper make sense. It seems better to just extend the X.509 chains with our own types of certs.

Wow, great paper!

I like the idea of the "bill" (aka contract aka "PaymentRequest") determining the payment address, and the merchant's private bitcoin-signing key or keys being stored off their web server.

I'll append some half-baked thoughts below on melding the current PaymentRequest proposal with your ideas.

Using a Merkle tree to reveal (or not) parts of the bill is a nifty idea, but I think that is orthogonal to the payment protocol, and could be a generic way of encoding any document. I tend to agree with Mike, it feels like a complex solution to something that really isn't a problem right now (maybe if we ever have CyberCourts to adjudicate disputes between anonymous customers and merchants it will be useful).

PS: I was amused by:
Writing the code should be fairly straightforward; getting everybody to agree to the dozens of details we'll need to work out will be more than a little effort.

---

So in the PaymentRequest protocol, a SignedPaymentRequest contains a PaymentRequest that you know came from the merchant's web server (leveraging the SSL/TLS/PKI/X.509 certificate system that we all agree is the worst PKI system there is, except for all the other that have been tried):


As your paper points out, if an attacker compromises the webserver then they can redirect bitcoins to their wallet.

It would be nice if that was impossible, and your paper shows how to do that.  In the PaymentRequest scheme, one way of doing that might be:


The merchant's certificate in the certificate chain would have to contain their base bitcoin public key (or as you point out in the paper, generalized to a "base script"). I think that could be done using an X.509 extended attribute (anybody know if certificate authorities will sign certificates that contain non-standard extensions?).

The customer would hash the serialized_payment_request, combine it with the base key/script, and pay to that address/script.

---

The TODO list for implementing the simpler "x509" payment requests is fairly long (help appreciated by the way, see https://github.com/gavinandresen/paymentrequest/blob/master/TODO.txt ); implementing "x509_homomorphic" would make it even longer. I think we need to implement the simpler protocol first, because I think small merchants will want to re-use their existing web server certificates instead of paying for a new "x509_homomorphic" certificate that contains their "bitcoin identity" public key.

Thanks for the thorough and high quality paper. I only had time to scan read it (nearly 1am here) and might take a closer look later. Hopefully others can comment.

My primary thought having scan read it is that your system is a lot more complex than the one we're developing, because of the assumption that the merchants web server should not have signing keys:


But that's not a normal assumption - the web server already needs the private keys to set up SSL sessions.

The only purpose SSL keys have in our current spec is to ensure that 2nd factors can display a human-meaningful identity, to avoid substitution attacks on compromised end-user machines. Dealing with compromised web servers is not in-scope for the current work because if a server is broken into and its SSL keys stolen, the hacker can as well switch out (some of) the addresses it's vending to their own. That's easier than using the stolen keys to sign fake bills and try and trick users into paying them, seeing as users would only confirm the payment if they were actually intending to pay that merchant anyway.

In our current spec, a "receipt" (proof of payment) is simply a signed payment request plus the transactions that paid the requested amount to the requested keys and the merkle branches linking them to the best chain.

Being able to "tear off" parts of a receipt is indeed useful, I was thinking about it the other day in a different context. But structuring the payment request as a merkle tree is overly complex, in my view. It's simpler for merchants to just provide a few different signatures that cover different parts of the structure, eg, one signature for everything, another signature that covers just the requested outputs.

A payment protocol is already being developed, with input from several on the bitcoin-development SourceForge mailing list.

See https://github.com/gavinandresen/paymentrequest for software or the mailing list discussion archives http://comments.gmane.org/gmane.comp.bitcoin.devel/1574

We would like to propose a payment protocol with a lot of interesting features:
Homomorphic Payment Addresses and the Pay-to-Contract Protocol

This could be of interest to the current ongoing development of hardware wallets as well as to the implementation of deterministic wallets.

[EDIT] Related thread: Destination Address Anonymization in Bitcoin [/EDIT]