Bitcoin Payment Protocol discussion continued

[Hyena]

I created this topic because the original Payment Protocol FAQ (https://bitcointalk.org/index.php?topic=300809.0) was locked and people were asking for a poll anyway.

The major concerns seem to be:
* Man In The Middle attacks
* The fact that Certificate Authorities in their current form and function are not cool
* Bitcoin's Official client should be neutral to any commercial uses and entities

Discuss... I start:

Fact 1: MITM attacks happen rarely.
Fact 2: MITM attacks are pretty much useless when the victim sees it happening.
------------------------------------
What's the worst thing that could happen when getting MITM attacked during BTC tx?
- You send your coins to a wrong address.

What is bitcoin best for?
- Making small transactions.

Conclusion:
Don't send a large sum of money in a single transaction. Instead, make many small transactions that you can afford to lose in case of this rarely occurring MITM attack. When the other party receives this small transaction, it should somehow communicate to you "Keep going, you're sending to the right address". The communication part should obviously use another channel based on some existing trust. If you know you can trust blockchain.info then you can just check the receiver on that site, trusting the CA used by blockchain.info.

But here's another idea:
How to memorize a bitcoin address if it is not a vanity address and contains random characters? Extract the address into the format of common words similarly to what brain wallets do. The computer should then draw a deterministic picture of the address, so that all the used common words would be drawn on the picture.

Hypothesis: if you memorize the picture you are likely to notice if suddenly there is an ELEPHANT instead of a HORSE on that picture. When you see such thing you know that you're sending your money to someone else. Vanity key mining would then become a whole new thing: for example one wants to have a picture of its public key that has 7 loads of gold on it

[Herbert]

I think Mike did a great job by explaining everything related in the FAQ thread. Please don't spread FUD just because you personally disagree.

[Hyena]

I think Mike did a great job by explaining everything related in the FAQ thread. Please don't spread FUD just because you personally disagree.

Explaining something is one thing, discussing it as a community where people other than devs have right to say a word is another.

[🏰 TradeFortress 🏰]

Conclusion:
Don't send a large sum of money in a single transaction. Instead, make many small transactions that you can afford to lose in case of this rarely occurring MITM attack. When the other party receives this small transaction, it should somehow communicate to you "Keep going, you're sending to the right address". The communication part should obviously use another channel based on some existing trust. If you know you can trust blockchain.info then you can just check the receiver on that site, trusting the CA used by blockchain.info.

That's silly. Assume a CA is rogue, they are able to generate a cert for blockchain.info and MITM. I'm not sure how checking Blockchain.info will help because that will just tell you if a transaction was received or not.

[Hyena]

Conclusion:
Don't send a large sum of money in a single transaction. Instead, make many small transactions that you can afford to lose in case of this rarely occurring MITM attack. When the other party receives this small transaction, it should somehow communicate to you "Keep going, you're sending to the right address". The communication part should obviously use another channel based on some existing trust. If you know you can trust blockchain.info then you can just check the receiver on that site, trusting the CA used by blockchain.info.

That's silly. Assume a CA is rogue, they are able to generate a cert for blockchain.info and MITM. I'm not sure how checking Blockchain.info will help because that will just tell you if a transaction was received or not.

It was just an example. If you can't think for yourself then here's another one: go behind the bushes with the receiver, exchange your public keys and everything will be fine. Then when the receiver gets your transaction he or she will send you a message "Thanks dude, I got your initial coins, now send the bulk." (signed by the owner of the public key that you got from behind the bushes).

And now, don't come saying "that's silly, what if someone else wearing your receiver's mask comes to give you the public key behind the bushes". So, it's not silly. Obviously if I was to send 1 000 000 bitcoins then I wouldn't trust blockchain.info but if I had to send 1 bitcoin, it wouldn't be a problem.

[Mike Hearn]

The idea of sending very small payments and then making sure you got what you wanted via some other mechanism is not a bad idea, in fact, it's a great idea, which is why I am working on implementing it.

The idea of sending small payments makes a lot of sense for things that can be micro-billed, for instance, imagine a file server that will serve up a 50kb chunk of a file in return for a micropayment. Now MITM attacks don't matter any more because (assuming you can verify you're downloading what you expected) you pay, and either you get the service or you don't. If you don't, you stop paying and your maximum loss is really tiny.

However, micropayments are a separate thing from the payment protocol. When you can use them, that's great, but for many purchases it's not appropriate (like something being delivered mail order). In that case you really need to send the money all at once.

[Severian]

So much for section 10 of the white paper.

10. Privacy

The traditional banking model achieves a level of privacy by limiting access to information to the
parties involved and the trusted third party. The necessity to announce all transactions publicly
precludes this method, but privacy can still be maintained by breaking the flow of information in
another place: by keeping public keys anonymous. The public can see that someone is sending
an amount to someone else, but without information linking the transaction to anyone. This is
similar to the level of information released by stock exchanges, where the time and size of
individual trades, the "tape", is made public, but without telling who the parties were.

As an additional firewall, a new key pair should be used for each transaction to keep them
from being linked to a common owner. Some linking is still unavoidable with multi-input
transactions, which necessarily reveal that their inputs were owned by the same owner. The risk
is that if the owner of a key is revealed, linking could reveal other transactions that belonged to
the same owner.

http://bitcoin.org/bitcoin.pdf

[StarfishPrime]

So much for section 10 of the white paper.

10. Privacy

The traditional banking model achieves a level of privacy by limiting access to information to the
parties involved and the trusted third party. The necessity to announce all transactions publicly
precludes this method, but privacy can still be maintained by breaking the flow of information in
another place: by keeping public keys anonymous. The public can see that someone is sending
an amount to someone else, but without information linking the transaction to anyone. This is
similar to the level of information released by stock exchanges, where the time and size of
individual trades, the "tape", is made public, but without telling who the parties were.

As an additional firewall, a new key pair should be used for each transaction to keep them
from being linked to a common owner. Some linking is still unavoidable with multi-input
transactions, which necessarily reveal that their inputs were owned by the same owner. The risk
is that if the owner of a key is revealed, linking could reveal other transactions that belonged to
the same owner.

http://bitcoin.org/bitcoin.pdf

^ +1
Introducing a trusted third party (eg. CA) into a system which was created explicitly to not require one seems intuitively wrong on many levels.

An API supporting external applications to handle this sort of tag-on feature would be a more elegant solution than shoe-horning them into the actual client. Same with Trezor support etc... They may be useful for some but they should not bloat the client unnecessarily.

BIP 38 is a good example of what should be included in the client. It's already in widespread use (for encrypted off-line storage, etc) and would actually be useful for most users.

[jgarzik]

Have any of these critics contacted bitcoin websites, asking them to stop using SSL w/ public CA?

No?

I thought not.

For, the payment protocol will be used where there is already a digitally secure relationship between customer and merchant.

So much for section 10 of the white paper.

privacy can still be maintained by breaking the flow of information in
another place: by keeping public keys anonymous.

Nothing about that section changes.  Bitcoin-QT still tries to use a new key for each transaction, just like that section describes.  The payment recipient (merchant) still knows just that public key hash, but not about your other transactions.

Methinks there is some basic reading comprehension fail going on.

[Hyena]

bla bla bla

still sounds more like a separate program / module / plugin rather than something hard-coded into bitcoin QT.

[ineedit]

I think Mike did a great job by explaining everything related in the FAQ thread. Please don't spread FUD just because you personally disagree.

Explaining something is one thing, discussing it as a community where people other than devs have right to say a word is another.

I agree, I seem to have missed somewhere the explanation of why the other thread was locked, where has that discussion moved onto if not here?

[Hyena]

I think Mike did a great job by explaining everything related in the FAQ thread. Please don't spread FUD just because you personally disagree.

Explaining something is one thing, discussing it as a community where people other than devs have right to say a word is another.

I agree, I seem to have missed somewhere the explanation of why the other thread was locked, where has that discussion moved onto if not here?

here's the old topic: https://bitcointalk.org/index.php?topic=300809.0

[ineedit]

...

here's the old topic: https://bitcointalk.org/index.php?topic=300809.0

Thanks Hyena!

I now understand Mike's reasoning behind why he locked the topic. It might have turned into a technological spat on the merits of different methods but still quashes the discussion. I think that you were right to re-open as a poll.

My vote is for "A separate program that uses API to talk to Bitcoin-QT" as I see that is the closest match to "Bitcoin's Official client should be neutral to any commercial uses and entities"