Fwd: FYI: FAQ on Bitcoin Payment Protocol

FYI this may be interesting to some of the people on this list.  The
Bitcoin Payment Protocol aims to use URLs for identity based on X.509
certificates.

---------- Forwarded message ----------
From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: 24 September 2013 18:00
Subject: FYI: FAQ on Bitcoin Payment Protocol
To: Web Payments <public-webpayments@w3.org>, Mike Hearn <mike@plan99.net>


[[ By Mike Hearn cc'd ]]

https://bitcointalk.org/index.php?topic=300809.0

[[

Recently Gavin merged support for BIP 70<https://en.bitcoin.it/wiki/BIP_0070>,
71 and 72 into Bitcoin-Qt. BIP 70, aka the payment protocol, is intended to
be a big change to how people use Bitcoin. A lot of questions about it come
up repeatedly, so here's an attempt to answer the most common ones.

*What is the payment protocol?*

Old timers will remember that Bitcoin v0.1, the first version ever
released, allowed you to pay people in two ways. One was by entering a
Bitcoin address. The other was to enter an IP address. If you entered an IP
address, your computer would connect to the node on that IP and run a
rudimentary payment protocol that involved asking the node for a fresh
public key, then uploading the payment transaction directly.

Satoshi thought this payment protocol would be how people mostly used
Bitcoin. It had some advantages, like guaranteeing a fresh address. He
originally intended addresses to be used only for when the recipient was
offline. But he was wrong - addresses quickly came to dominate and hardly
anyone used the pay-to-IP feature. Eventually it was removed.

Why did it fail?

One reason is that it wasn't very secure, anyone who could MITM your
internet connection (like someone sharing your wifi) could steal money sent
this way. Another more practical reason is that back then there were no
online shops that accepted Bitcoin. In fact Bitcoin was a Windows-only pure
GUI app with no JSON-RPC API so nobody could even build online shops. So
you never knew if the person you were trying to pay would be online or not
at the time, meaning giving an address was more reliable. Also: NAT,
firewalls, etc.

But it wasn't a bad idea and so now we're bringing it back, but with a
better design. The hope is that over time this will come to replace Bitcoin
addresses for most usages. But don't worry. Addresses aren't going to
disappear. They'll still be around if you want them.

*How does it work?*

It's a way to format a small piece of data (think file) that contains
instructions on how to pay someone (a *PaymentRequest* message), and then a
formal specification of how to satisfy those instructions by submitting a *
Payment* message. The data is designed to be extensible in future so we can
add lots of useful features.

In future, clickable bitcoin links will look like this:

bitcoin:1EZEqFBd8yuc9ir2761987q7k3VcALC8YQ?request=https://bitcoinstore.com/r/aBcdE

When clicked, your wallet app will download the request URL and read the
PaymentRequest it gets. The request message contains another URL, which is
where to submit the finished transaction to (instead of/as well as
broadcasting it to the P2P network).

*Who is implementing the new protocol?*

Support will be in the next Bitcoin-Qt release, and is being worked on for
MultiBit/Android Bitcoin Wallet at least. BitPay has also committed to
implementing it, so all merchants who use their services will get support
automatically. If you're planning to support it, let me know and I'll add
you here!

*What's wrong with Bitcoin addresses?*

Lots. They lead to privacy leaks, they are inflexible and tough to extend
with new features, they aren't authenticated and they're one way only.

*Why do they lead to privacy leaks?*

The standard way to use an address is one address per payment received (if
your wallet makes that easy to do). This can lead to privacy leaks in the
following scenario.

Say you work for a small coffee shop which accepts Bitcoin payments of say
0.01 coins for a coffee. Over the month lots of these small payments get
accepted. At the end of the month you get your salary, so you give your
employer a fresh address. They make a payment to that address by collecting
together lots of the coffee payments and generating one giant salary-sized
output.

You then go to the pub and your friend says, hey mate, you owe me $10 for
losing that bet we made last week (or whatever). So you send him $10 worth
of Bitcoins, of course your wallet goes and selects your salary output to
do that. Your friend can now look at the transaction he received and see
that it came from a single large, salary-sized looking output. Now they
know how much you earn.

A better way would be if you gave your employer 100 addresses, and they
could then pay you with 100 transactions that re-allocate small numbers of
coffee payments to your keys. Then the linkage would be much smaller. But
in practice nobody does this.

*How does the payment protocol solve that?*

The request message allows you to request the payment be spread over
multiple outputs (which don't have to be pay-to-address type outputs at
that point, they could contain any script, like multi-signature scripts).
It also lets the payer submit multiple transactions as part of satisfying
the same payment. When an app generates a payment request (e.g. to get your
salary), it knows how much money it's requesting and it can spread the
money over many outputs. They payer might still generate one
mega-transaction, but it's smarter for the payer to try and match up what
it's got most closely with what's requested, to maximize privacy and
minimise leakage.

*Why does the sender submit transactions directly to the recipient?*

Currently to pay someone you broadcast transactions to the P2P network and
the recipient waits for them to arrive. This works OK, but can be
inflexible. For instance, what if the sender doesn't have an internet
connection? What if they're behind an evil firewall that only allows web
traffic? What if the recipient has a deal with a specific miner and doesn't
want to broadcast the transactions at all?

In the new payment protocol, the request contains instructions on how to
submit the payment. Typically, the wallet will be given an HTTPS URL to
submit the data too, but alternatives are easily possible. For instance,
the Android wallet app already supports using Bluetooth to send
transactions directly to the recipient (when both sides use Android).
That's great when you're travelling/roaming and might not have an internet
connection. The payment protocol will let us standardise that behaviour
instead of it being specific to that one app.

*What other features does it add?*

In v1 of the protocol:

Refunds. The sender can submit some refund addresses to the recipient at
the same time as submitting the transactions. Now if the seller wants to
give the buyer a quick refund, they can do so. No more problems with trying
to "guess" the users address and sometimes getting it wrong due to shared
wallets. Bitcoin-Qt generates a refund address for every payment done this
way, but you'll only see them if you do actually get a refund.

Memos. Clickable links can already contain short strings or labels, but
their length is tightly limited by what browsers will accept and what fits
in a QRcode. BIP 70 allows payment requests to contain arbitrarily long
memos, which can be used to describe what you are buying. This is super
useful when the payment request is authenticated ....

*What is authentication about?*

Bitcoin is a difficult project partly because we're moving money around
with general purpose computers that can be hacked or get viruses. VISA and
MasterCard have moved everyone (outside the USA) to special-purpose
hardware like chip cards and dedicated readers which can't have random apps
installed on them. Our approach has to be a bit different, but dedicated
hardware is still coming. The Trezor device <http://bitcointrezor.com/> is
a mini computer just for Bitcoin that plugs into a "real" computer via USB.
It has a display and a couple of buttons. It holds your private keys. When
you want to make a payment, the details of the payment are shown on the
screen and if they're what you want, you press OK and things get signed.

There's an obvious flaw with that design when combined with Bitcoin as it
is today. The "details of the payment" you'll see on screen will look like
this:

  Pay 0.5 BTC to 1EZEqFBd8yuc9ir2761987q7k3VcALC8YQ?

Where did that address come from? Well, it came from your computer. The
thing that probably has a virus on it. That virus could have swapped out
the address sent by the online shop you're using for one owned by the virus
author, and because they're just random numbers you'd never know. Although
the virus can't empty your wallet immediately, it can still steal payments
when you make one, and avoiding that is the whole point of using special
hardware!

The payment protocol allows recipients to sign their requests under an
"identity". An "identity" is just some arbitrary string, that was itself
signed by some "certificate authority". The authority vends signed
statements that say (simplifying a bit)  "I, Bob Smith, believe address
1EZEqFBd8yuc9ir2761987q7k3VcALC8YQ is owned by Mike Hearn". Now if your
Trezor happens to trust that Bob Smith validates identities reliably, it
can display:

   Pay 0.5 BTC to Mike Hearn?

and that message can't be tampered with by any virus. As you can see this
is much safer.

*How do receipts work?*

When a payment request is signed it's not just the addresses. The memo is
also signed. By keeping around the signed payment request, and the
transactions you created to satisfy it, you obtain a mathematical proof of
payment. The merchant cannot dispute what was paid for because the memo
field contains a description, nor can they dispute that payment was
delivered (unless they claim they lost control of their private keys, of
course).

This is great because it fills in a missing piece for low-trust third party
dispute mediation<https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation>using
multi-sig transactions. Currently if you tried to implement that,
you'd run into the problem of a buyer saying "seller did not deliver!!" and
the seller saying "the buyer never paid me!" or more problematically,
 buyer saying "seller gave me something different to what I asked for" and
the seller saying "I gave him exactly what we agreed on".

With receipts, it suddenly becomes much easier to figure out what happened
in a transaction and recompense the right party.

*Do payment requests have to be signed?*

No. Without a signature they are basically just a container for addresses
and memos.

*Do payment requests get stored in the block chain?*

No. Payment requests and responses are transmitted directly between buyer
and seller. They are not recorded publicly.

*What about other features, like tips?*

The payment request and response messages use a format called protocol
buffers, which is easy to extend. I compiled a list of future feature ideas
here:

https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147<https://bitcointalk.org/index.php?PHPSESSID=81onjvf0qg3o3tljkhucnmv3h0&topic=270055.msg2890147#msg2890147>

None of those exist today, but before they can be created we need somewhere
to stash the data they require. The payment protocol is the perfect place.

*How do identities work?*

The protocol can be extended with multiple methods, but for v1 the only one
that works is X.509 certificates. This is the same scheme used for SSL.

Essentially, anyone can get a certificate attesting to some kind of
identity. Often it's just an email address or website domain name (e.g.
bitcointalk.org has a certificate containing its domain name). It can also
be a legal name like "Michael C Hearn" or "Mt Gox Ltd". In fact, if you
have a passport with a chip in it then you already have a certificate
containing your passport data, but it's not very useful because there's no
private key associated with it.

Sometimes certificates are paid for and other times they are free. The
certificate authorities never get your private key. Instead you generate a
private key locally, then ask the CA to sign your public key. At the same
time you prove your identity, if your identity is an email address then you
typically receive a clickable link there for instance. If it's your name
you might have to submit some paperwork.

*Does this make Bitcoin less anonymous or private?*

No. People always know an identity of who they're paying already. That
doesn't have to be a legal identity. It can be a forum handle or pseudonym
too, so even on the Silk Road this holds true - you know you're paying
"Drug Dealer Dan" or whoever. But you basically never send money into the
void with absolutely no idea of who it's meant to go to (outside of special
protocols we're not going to address here).

Knowing the identity of who is paying you is less common, but the payment
protocol doesn't establish two-way identity. Only the entity requesting
payment has the option to sign (and of course they don't have to).

*Can I use the PGP web of trust?*

No, that's not supported in v1. However anyone can become a certificate
authority, in fact Apple ships a GUI for creating and running one with
every copy of MacOS. But you would have to convince people to trust you,
which is the hard part. The "web of trust" doesn't solve that problem - you
would still have to convince people to trust you for the purpose of signing
keys.

That said, it's imaginable that trusted community members might create
their own CA's and start issuing identities. For example, BitcoinTalk could
issue certificates where the identity is your forum username. If wallet
authors/hardware wallet designers decided to trust theymos for that
purpose, you could see forum handles appear on your Trezor.

*Isn't SSL horribly broken?*

No, not really. Some people say it is, but there are no better systems -
the X.509 PKI (public key infrastructure) reflects the result of many years
of evolution and improvement. What's more, it's *still being improved*.
Because it underpins SSL there's a lot of rich and powerful entities who
want to see it get better, like Google, which pays people to work on it.

Let's make that concrete. One of the most common concerns with the X.509
PKI is that there are too many certificate authorities. This is still an
improvement on the old days (early 90's) when there was only one CA, but
having hundreds means that any CA can issue a cert that every user will
accept. What stops a CA issuing a bogus cert to an imposter, like a hacker
or a government .... or just another customer?

Currently the act of issuing a cert leaves no traces so this is a real
concern, although there are remarkably few known cases of it happening
given the enormous size and scale of the PKI. Google is developing a
solution called "certificate transparency":

http://www.certificate-transparency.org/

It's a public post-unforgeable audit log of all certificates issued. It
works a little bit like the Bitcoin block chain, in fact. Each certificate
can contain a proof (some Merkle branches) linking it to an entry in the
public log. Once a CA has started using the system, if a certificate is
found signed by that CA which does not contain such a proof it can be
rejected as invalid. This means the CA can no longer issue certificates in
secret. By watching the public audit logs, you can spot if a CA issues a
certificate in your name .... or even in a name that's just confusingly
similar to yours (so it is a way to fight against phishing as well).

*I still prefer the web of trust*

You shouldn't. The PKI is the result of evolving a web of trust style
system over many years, as it got real usage. It looks the way it does
because of its solutions to the problems the raw web of trust model has.

For instance, let's say Bob starts signing keys using GPG. His signature is
worth very little unless I happen to know and trust him. In practice as a
new Bitcoin user who just saw it on CNN, I don't know Bob. However, maybe I
do trust the guys making the Trezor because they are a real company and
they live in a country with sane laws, etc, they have lots of happy
customers, so that gives me a starting point. Then if stick and slush trust
Bob, and Bob has signed the key of bitcoinstore.com then I have a chain of
trust to the store.

Bob has become a certificate authority!

How trustworthy is Bob, really? Does he keep his private key on a computer
running a warez copy of Windows XP that is full of malware? It would be
nice if we could formalise the "stick and slush trust Bob" part of the
above description. Otherwise what stops Mallory turning up and demanding
that Trezor trusts him too?

A good way to resolve this conundrum is to come up with a set of best
practices, like keeping your private key inside a hardware security module,
and setting some rules around when Bob/Mallory should sign a public key. To
increase trust in the system and stop Mallory just claiming he follows the
rules when really he doesn't, we might want to create a formal audit system
and an auditor organisation that verifies these guys are following the
rules.

We just re-invented the WebTrust Audit:


http://www.sslshopper.com/article-what-is-webtrust-for-cas-certification-authorities.html

Eventually as Bob and Mallory get more professional and trusted, they'll
discover it's sort of hard to do it in their spare time so they'll create
companies and start charging fees. They'll compete in the open market.
After a long time, some of them will discover that for the most basic kind
of key signing (emails and domain names) it can be entirely automated and
done for free.

That's StartSSL.

As the number of trusted parties goes up and they handle more and more key
signings, eventually Bob or Mallory might get hacked or pressured by the
government. It'd be nice if everyone knew what keys Bob and Mallory had
signed, in a more scalable way than just relying on everyone to upload all
their keys to the MIT key server.

That's certificate transparency.

I hope you can see now why the PGP web of trust would eventually end up
being pretty similar to the regular PKI, if it got big enough.

]]