Topic: FAQ on the payment protocol (Read 47138 times)

That's absurd. The whole Lavabit episode actually indicates how strong the CA infrastructure really is - these guys were going after Snowden, public enemy number one at that time, and they had to ask Lavabit for their SSL keys. They didn't simply pop round to their local friendly CA and grab a fake cert (because that would have been spotted and the CA itself would have risked revocation) .... they spent weeks and months arguing in court to try and get the keys for the original cert instead.

How could the infrastructure have done any better here, exactly? Is that not the doomsday scenario you're worried about, and yet there was no fake cert? When the US government is reduced to "give us your keys or we'll throw you in jail", that's basically a 100% success for the crypto system, isn't it?

As was already explained in the FAQ, payment requests don't go into the block chain or anywhere else. They are sent between the merchant and you. If the NSA can obtain them, they can already obtain all your communications with the merchant anyway, at which point receipts are the least of your concerns.

Look, I'm all for reasonable paranoia. This has long since left the realm of the reasonable.

I'm going to lock this thread now because the arguments are going round in circles. The payment protocol is designed to support more than
just the SSL PKI. If you don't like it, design and implement a system you think is better and get people to adopt it.

Gavin, I have a higher opinion of your intentions than that. You're the only reason I ponied up 25 btc when the foundation started and you're still the only reason I don't regret having done so. But your antenna for realpolitik doesn't seem to be quite as attuned as your abilities in programming and organization are.
 
Lavabit's cert was just revoked. The inclusion of CAs in Bitcoin allows for a pressure point to those who use CAs to verify their identity to customers. Run afoul of someone in the regulatory/enforcement world and a seller's CA could end up like Lavabit's and their biz gets threatened or wiped out. Or they could just take a look at the CA-connected address that a merchant is using and make all kinds of links to the buyer's address and then follow the change address transactions after that. The CA-connected address is like an anchor in the intel ocean.

The strength of Bitcoin is, or was, in how it protected the merchant. This BIP opens up a weakness in that protection to both seller and buyer. I'm sorry to see it happen to the reference client and to Bitcoin.

"Impress with this protocol" ??

My primary motivation for the payment protocol can be seen in this mock-up of multi-signature transaction authorization:
  https://moqups.com/gavinandresen/no8mzUDB/p:af7339204

I want much more secure wallets, but we can't get there unless the "who am I paying" piece is authenticated.

You should save the "Gavin is trying to impress evil institutional investors" mud-slinging for when I get around to laying out the argument for increasing the block size, because that would be closer to the truth.

+1   Well said!

If Bitcoin wants to be the first real independent world currency then it must standalone and ignore the interference and control of governments or commerce.

You've just described the very people that I suspect some folks on the dev team and within the Bitcoin Foundation are trying to impress with this protocol: institutional investors and their related ilk in large online commercial concerns. I understand the desire some people have to see Bitcoin accepted in the wider world, but this isn't the way to do it. Some folks working with TLAs might be interested in this BIP also due to possibility of connecting real-world info to Bitcoin addresses and increasing their tracking capabilities on the blockchain.

^ Yes. Any support should be in the form of a general API for external tx signing. Nothing vendor specific (obviously). 

Well, they're adding this implementation of the payment protocol too early for it to work out quite like that. But I'm with you guys in principle, I don't intend to encourage merchants that use this too much. And I'd be very positive about a real solution to the ease of use issue. I'm not sure if the developers haven't missed the point a little anyway: the more popular a genuinely free and open protocol gets, the more the culture will take on a life of it's own. They can't force merchants to use the payments protocol, and there are simple and secure ways to make homemade server-side payment processes for the merchants that don't want to deal with the CAs. This solution is for lazy, unimaginative and conformist/convention minded kinds of people, i.e. the sort that aren't that attracted to Bitcoin at all yet.

I expect this original incarnation of the Payments Protocol will be long forgotten in the not so distant future, especially if it's use gets pushed too hard by any significant figures within Bitcoin. There are too many idealistic people who can just innovate their own solution, I strongly encourage it. Core dev team is not a dictatorship, there's already independent teams doing work on the Satoshi client, and independent clients. We still have the power of choice, for now.

At the moment nobody is adding Trezor support to Bitcoin-Qt.

It'd be nice if there could be a standardised protocol so Trezor and its competitors were all compatible. It's a bit early for that though.

+1

I also believe Bitcoin should remain vendor-neutral, are the devs in any way affiliated with Trezor?

What happens when other companies start offering similar products, are the bitcoin devs also going to include support for them in the official bitcoin client?

What happens when by a string of back luck some design flaw in Trezor causes or contributes to the loss of someone's bitcoins?

If think there should at least be a Bitcoin-Qt client to download without Trezor-related or other products' code, or if the extra Trezor-supporting code was released as a separate plugin/add-on/whatever.

I just generally support modularity. Trezor should have its own host program to connect it to bitcoin qt instead of bitcoin qt directly including the Trezor specific logic in its own code.

By "MITM attack" we're also talking about viruses on your computer here, which is a not so uncommon occurrence unfortunately. In this case the "middle" is your computer and the "man" is whoever controls the virus. The Trezor manages your wallet so it can't get infected, the computer just provides support services and connectivity.

I think being able to handle the case of a virus infected computer is pretty much core wallet functionality. But, sure, opinions can differ on that. In the past month a couple of new desktop wallets appeared (both Mac only sadly), so it's definitely not that hard to create your own wallet with your own blend of features these days.

I think a Tor specific PKI sub-protocol for the payment protocol would be a great thing. Hidden services are already identified by public keys, so it should not be very hard to add support for that at all, if someone wanted to do it.

If MITM is such a great problem then go behind the bushes and exchange your keys there. Really, to me this whole thing seems like an excuse to make everyone pay more money to CAs.

Also, if you absolutely need to make user experience more resistant to MITM attack then please create a branch bitcoin wallet instead of ruining the core code with features that are not really needed for bitcoin to work.

Making the user experience more resistant to MITM attacks is not bloat.

Well Trezor is cool, I don't argue that but it's conceptually wrong to add excess features to a bitcoin wallet program that should be the most trivial and standard one. You can always make a new program that would act as a proxy between bitcoin QT and Trezor. Thus, I still don't support the idea of bloating the standard wallet with anything other than what the bitcoin protocol needs.

Bitcoin QT should be commercially neutral. This means that it should not feature any entity that gets direct monetary profit from such features. Introducing features that glorify CAs is on the same level of wrongness as adding the following text to the Bitcoin-QT's GUI: "Click here to buy bitcoins from Mt. Gox!"

Absolutely.  It would be quite nice if wallets support Trezor, including Bitcoin-QT.

I believe bitcoin qt should only provide features strictly in the context of the bitcoin protocol. If you want BIP make a new program for that, different from bitcoin (qt) so that I don't have to install this crap.

If you are going to insert bloatware into bitcoin standard client then this is no longer a standard client for bitcoin protocol. What next? Adding support for http://www.bitcointrezor.com/ to the standard bitcoin wallet? This is getting ridiculous and it's time for a new bitcoin qt branch as soon as the devs go rogue and start adding bloat code and what not.

I'm sure you know enough economics that I'm talking about return on investment curves: for mining that curve is fairly flat, and your ROI is similar regardless of what scale you are mining at. (and actually, smaller scale can be more profitable because getting rid of a small amount of waste heat is a lot easier than getting rid of a large amount)

StartSSL on the other hand proves my point: with CA's you have a very large upfront investment before you make any money at all. In StartCOM's case they operated their StartSSL CA as a money losing educational project that took years before browsers started included them in their certificates. It's a huge barrier to entry, one that makes the CA market entirely unlike mining.

Just an example of how you love to make arguments that even you should know don't make much sense. In this case that habit of yours is extremely harmful, because that kind of dishonesty gives credence to those writing technically unsophisticated paranoia; non-technical people who understand that your economic argument made no sense are likely to make the assumption that what you're saying about security is bogus too.



You can add Tor to that list, specifically bookmarks of .onion sites.

A decent idea for a payment protocol extension would be to work out what kind of UI and other details would make sense to make it possible for a user to add a .onion URL to their second-factor wallet so they could verify a payment request against a .onion URL correctly.

A logical next step would be to do some work on a reputation/timestamping/something else entirely system, to make it easier to detect the case where the .onion URL you got was itself invalid and not the one that the majority of users of the site use. Done right this stuff could eventually lead to a namecoin-style system, but with typo-squatting less useful among other things.

By virtue of existing https use, the voting is active and ongoing.

The only robust, deployed systems in active use are SSL and PGP.

I guess that's the most important point. People yell about the CA market not being a market because it has so few players yet I guess we will see yet fewer CAs in wallets than in browsers plus maybe one or two bitcoin internal CAs that are excluded in firefox. We will see which CAs will cause problems first.

Sweet. I'll set up a Namecoin based CA then. 

Seriously, what about having a vote on the payment protocol / CA stuff going into the standard client? That would give the thing some backing if it was successful.