Bitcoin Forum

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, CoinBase and CoinPunk. BitPay 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

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.

Thanks for a great FAQ.

I'd like to note that splitting initial payment into 10 addresses does not help with privacy much. When you run out of money, your next payment will aggregate several "change" outputs thus linking you to the very first salary payment. Real privacy can only be achieved when you link several outputs that have very big distance between each other in blockchain. For that you'd need real mixing.

Also, when you pay to the same person from different chunks into which your salary was split, he now can detect that you own all those chunks. If the salary was not split from well-mixed (very far from each other) outputs by your employer, it'll be easy to estimate your whole salary size just by seeing a couple of chunks connected together.

The chunks aren't linkable, that's the idea. So you can't estimate the salary, you  can only get a lower bound.

Edit: to clarify, no mixing is required or involved. The coins that were used to pay your salary have never been linked because they came from different people to start with. If you can avoid ever linking them in the process of paying your employee, mixing is not necessary to improve privacy a lot.

I thought of another question/answer:

How will non-shopkeepers create payment requests?

Today the payment request system is intended for online shops and payment processors like BitPay. Gavin wrote some PHP that can be used to generate and serve the signed requests server side.

But in future wallets might create payment requests for their users too. On Android this will be a seamless upgrade - the QRcodes people scan today will start including Bluetooth MAC addresses and the protocol will run over that. We've already got a prototype launched in the Play Store that doesn't use BIP70 but something much more primitive. No pairing is involved, the user experience is seamless.

On the desktop you'd probably fill out a form in your wallet GUI (for the price, the memo, etc) and then drag and drop an icon onto an email you're composing, IM window, web form etc. Anywhere that lets you transfer files basically. The request would be sent to the other side and opened by their wallet.

For signing, anyone can get X.509 certs for an email address for free from StartSSL. It's not super convenient to sign up, but there's no technical reason it can't be just one or two clicks. Once you got a certificate, most operating systems have a "key store" function built in which will let you install the certificate and encrypt your private key for you, often linked to whether the screen is unlocked or not. Android does this as well. Wallets can then talk to the OS to get the key needed for signing.

For receiving asynchronous payments that you didn't explicitly request, I think we'll see web sites pop up that host payment request files for you. Whenever you receive money via the uploaded request your wallet would notice and then upload a fresh one. This would be useful for tips, etc, that currently leak a lot of private data.

This is just abusing the blockchain. It won't work when tx fee gets higher in the future

Hardly. Making payments with good privacy is the one of the features of Bitcoin, isn't it?

Thank you for sharing this!

No. I believe the whole point of Bitcoin is "A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution". Privacy is just a secondary objective.

Back to the topic. Unless the salary is paid with 100 completely unrelated transactions, your friend could still figure out your salary. This will create a massive overhead and is obviously not sustainable.

In addition, it would be a stupid idea to ask your boss to pay directly to a hot wallet on your smartphone. Firstly, it's unsafe. Secondly, you boss can see all your transactions. The right way is to ask your boss to send to your salary wallet, and use some coin-mixing scheme to move the money to your spending wallet.

I think he's saying that payment protocol would generate new destination addresses so you would not leak other wallet addresses to your boss.  

Probably there is a happy spot between consolidation of transactions/leaking information and overwhelming the blockchain.  I'd imagine that this would be both configurable and have defaults that get adjusted with each client release based ultimately on the ratio of the rate of growth of the blockchain vs. rate of growth in storage space per dollar.

when you talk about private key, you mean ssl right? (not the bitcoin private key)

In some cases the payment won't be broadcast to the network but sent directly to the merchant ("What if the recipient has a deal with a specific miner and doesn't want to broadcast the transactions at all?"). In these cases, I could immediately double spend those outputs. How is this prevented?

Yes, thezerg has it right. But I really wish people would back up arguments about scalability with numbers. I think that kind of approach to privacy will scale fine. Prove me wrong.

Yes I mean SSL private key.

The merchant is responsible for broadcasting the transaction if they think you might double spend. You're not responsible for anything except handing it off to the merchant. If the tx is valid they can then propagate in parallel with starting to provide the service (pouring your coffee for example).

Adding OpenPGP to the payment protocol

So you want to use the OpenPGP WoT to authenticate payment protocol requests... here's how you do it:

1) Set pki_type in PaymentRequest to 'openpgp'

2) Set signature in PaymentRequest to a detached OpenPGP signature of the serialized_payment_details

3) Set pki_data to an empty string. Why an empty string? Because OpenPGP signatures already specify the key doing the signing; if you don't already have that key there's a good chance the user never verified it anyway.

4) (client-side) Verify the payment request by checking that the signature is valid. If you don't already have the key, you should tell the user the PaymentRequest can't be used because you don't know who signed it; don't let them pay the request unless the key is already imported and GnuPG or whatever trusts it and don't do that for them.

As for implementing this, you can use the GPGME library for C/C++ code (like the reference client) On Python I've used the python-gnupg (http://pythonhosted.org/python-gnupg/) library with success. Dunno much about Java, but I'm sure you can find something.

But remember that crypto doesn't exist in a vacuum - the payment protocol is mostly useful for multi-factor wallets, where you need to authenticate the same payment request on multiple devices. If you want your hardware wallet to make use of OpenPGP-signed payment protocol requests, it needs to support OpenPGP and you need to securely import your web-of-trust database into it. You're probably going to find that something like the following is far simpler, and almost as likely for users to use securely:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Donations to the Keep Bitcoin Free project are accepted at Peter Todd's
donation address:

1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJRlePvAAoJEH+rEUJn5PoEBeoIAKiqyP+V9mCJXzzLxVY1MzJ6
Lvcx9qRvFVZ/r0F1ph3SwkcCBPvwV7nD0Ca7Dr5eat/SDo0u1i6NdznKcY87zADk
RqhT0JvhNCNSg3uKfqiYlXS6IJNZ4yGSDxJfAaATH9irw0fLHfPXX1rxqp529I9g
bEVi1PBnZx00UHUFAEbVP6uJqjICD8pGwz8K/l2mgGb/1Iw8p3HKxXEogstOILGO
dmX60VzPptm2HwcQ9JLSjgsNv2f6KRZoZwr6eXlbGteNgiXRpV4Lo2V14hBWqXTs
gKDFsZud93Osqj+A3XIr4qj5GtNFqDUXsVbAmmjNGzs4oyzt7YXneGObRsPm4tA=
=EoMU
-----END PGP SIGNATURE-----

Transactions

If you make multiple payments in a row you might wind up not having any confirmed coins to pay the merchant with, which is why the payment protocol lets a Payment message contain more than one transaction. Wallet software will need to determine what unconfirmed transactions are required to complete a given payment, and give the merchant the whole lot. Merchant-side you need to make sure your software considers the payment complete provided the requested txout scriptPubKey:value exists in the blockchain - it's quite possible that the transaction that actually ends up paying you is not the one the customer actually gave you. Note how this also means that every order must use a separate scriptPubKey for that reason.

Right, thanks for the correction. In the first deployment wallets will still be treating 1 tx == 1 payment. The ability to request multiple outputs and submit multiple transactions will get activated over time as wallets get smarter.

Mike,

Please add Coinpunk to the list of clients that intend to support this. Thanks!

I need time to fully digest the implications of this, it's very interesting (and thank you for using protocol buffers here), but I'm initially a little skeptical as to whether this is a good approach. I think depending on central-server hot wallets has been demonstrated to be a dangerous approach to implementation of Bitcoin systems, as evidenced by the theft of millions of USD worth of Bitcoin over the last few years. I do feel like this system could potentially be just as dangerous as addresses, if not more so.

For example, as a merchant I could create a receive address on an offline computer, which is a design where your Bitcoins are very unlikely to be stolen. The trade-off is "privacy" of course, but from my chair, I'm way more concerned with security than I am with privacy. And the way I'm seeing most Bitcoins stolen right now are from server break-ins.

I also have concerns about increasing the complexity of Bitcoin transactions. This definitely increases the education curve, which is probably one of the main reasons why addresses became more popular: they are simple to understand.

It also introduces a non-Bitcoin system as a dependency, which may have far reaching consequences. What if that SSL certificate is revoked, or the government raids and confiscates the domain? If you need the domain to receive a transaction, that is quite a dependency introduced.

Again, very interesting, and I do like the CA approach, but I do have concerns about whether it is an improvement on the address system. It's my hope that there won't be a de-prioritization of the latter for the former.

My apologies in advance if I have not understood something, I have only had a chance to briefly skim over this so far and it's very possible I've misunderstood some of the machinations here and am talking nonsense.

Merchants accepting multiple conflicting transactions is important for CoinJoin, because not all your inputs might be yours and thus it's possible they could get double-spent. You should give the merchant two transactions in this case, one being the CoinJoin tx spending yours and their inputs to their and the merchants txout, and another spending just your input. (second tx having a slightly lower fee so it's not the preferred one by miners)

Of course this does degrade privacy slightly as the merchant can figure out which inputs were yours, but the blockchain record remains anonymized and the next payment you make will come from inputs whose inputs a step back are anonymized.

Another example is multiple payments in a row: suppose I'm Alice and I first pay Bob, and then Charlie using the payment protocol. When I pay Bob I create and sign a transaction, tx1, and give it to Bob in my Payment message. That transaction has two txouts, one that pays Bob, and the other being my change address.

But when I pay Charlie I should actually create two transactions: the first is being a modified version of tx1 - tx1b - that double-spends tx1, (potentially adding new inputs) and adds Charlie's requested address as an additional txout. The second transaction, tx2, then depends on the change output of tx1 and pays Charlie that way. Normally the merged tx1b will be what confirms, efficiently paying both Bob and Charlie in a single transaction, but if tx1 confirms first Charlie still gets paid with tx2. (the order of transactions in the list given to the merchant in this case is tx1b, tx1, tx2)

Of course, if any of the above actually gets implemented I'll be pleasantly surprised.

You can still keep keys offline when using payment requests. It doesn't change anything in that respect.

With regards to increased complexity, yes it's a concern but for now it's only going to be merchants who deal with this (and it's optional of course). In future it'll be used more widely as well, but I think we can come up with simple user interfaces for that.

If a government seizes your domain then having to create unsigned payment requests is really the least of your problems. But at any rate, it means your payment requests wouldn't validate and you'd have to stop signing them (thus making your users less secure).

Cut-thru payments

A future version of the payment protocol can allow the receiver to give the sender a BIP32 seed, and a total amount requested value. The receiver then considers the payment satisfied once outputs with addresses derived from that seed exist in the blockchain with a total value >= the total amount requested.

This means a merchant with debts to someone else, like their employees or suppliers, can get PaymentRequests from whomever they are in debt to and in effect have their customers pay those debts directly.

If those suppliers in turn have debts to other parties the process can repeat again. This time the supplier to the merchant just gives the merchant a list of addresses to pay, addresses that happen to belong to whomever the supplier owes a debt too. (maybe their employees?) Now two steps in the whole payment process have been skipped, and the customers of the merchant could very well be actually paying into wallets owned by employees of the merchant's suppliers!

In the business world 'Net 30 days' accounts are very commonly used, so this kind of arrangement could actually be quite practical and useful. Everyone in between saves on transactions fees, there would be a lot less demand for blockchain space, and privacy is improved for everyone.

Of course, it'd be a bit surprising if you went to pay a bill on Thursday night and the moment you paid it your wallet told you your employer had paid the exact same amount as part of your upcoming Friday paycheck...

It just sounds too complicated. Raised level of complexity normally will have unforeseeable consequence if something went wrong. Maybe this feature could be modularized and called from the official protocol

What, my pie in the sky ideas or something else? Note that the stuff about tx replacement, on the merchant side, actually just assumes merchants have the simplest possible implementation and implement it correctly. Basically a merchant wanting to accept a payment needs to do the following:

for tx in payment.transactions:
    node.broadcast(tx)

and in their "have I been paid yet logic":

def IsOrderPaid(order, min_confirmations=6):
    requested_output_scriptPubKey = order.payment_request.output_scriptPubKey
    requested_output_value = order.payment_request.value
    if requested_output_scriptPubKey in wallet_outputs:
        for outputs in wallet_outputs[requested_output_scriptPubKey]:
            if outputs.value >= requested_output_value:
                return True
    return False

Thing is, if you're implementation doesn't look like this you will occasionally see payments get stuck due to things like transaction mutability. All you should care about is that an output you can spend with greater or equal the requested amount exists in the UTXO set with a sufficient number of confirmations. That's it. Testing for anything more complex than that just gives more opportunities for something to fail because you got paid in a way you didn't expect too.

Thanks! This is the best explanation so far!

I don't understand how come the debt creep into the picture? Bitcoin is a payment system, but it seems these are some accounting function, more like a clearing house. But shouldn't the settlement be handled off-chain by some bitcoin clearing house, and all the merchants have business relationship in one area connect to this clearing house instead?

I'm concerned about the block size limit  :) There are so many accounting software out there, maybe no need to re-invent the wheel

Debt crept into the picture because the parties in it agreed too. Note how what I'm describing is much more organic than any centralized clearing house: it's just showing how what businesses do routinely - extend 30 day credit relationships to each other - can turn into a way for them to organically, indeed, accidentally, create something akin to the Ripple network with the help of suitable accounting/wallet software. Note how that as long as everyone involved has some mechanism to tell a third party "pay me these amounts at these addresses to settle our debt", and accounting/wallet software keeping track of the payments as they happen, the result can be a cut-thru payment system. The parties don't have to use the same software, or for that matter the "official Payment Protocol", and in fact in theory everyone involved could be doing it all manually.


Yes you should be. Notice how all of the above would have never happened if transactions are free or nearly free - why bother? Instead every step would be just done with individual transactions; certainly easier but the cost is a centralized system with bandwidth and storage requirements that only a select few miners can keep up with, and importantly, afford to audit fully. Or in the words of core developer Jeff Garzik:

-http://garzikrants.blogspot.ca/2013/02/bitcoin-block-size-thoughts.html

Mike's post on the consequences of centralized mining is interesting too: Freezing BitCoin addresses by regulating miners (https://bitcointalk.org/index.php?topic=5979.0)

Thank you for sharing ! :)

Due to the deflative and unregulated nature of bitcoin, I doubt anyone are going to have a debt in bitcoin (you might need to work 200% more to payback that debt in a month :D)

The PKI is still horribly broken, if I read the FAQ correctly (correct me if I don't) it means that currently anyone compromising a CA (as in any of them) can easily MITM and steal your money.

maybe it is time to start up a new PKI cartel, specifically for bitcoin applications. bitcoin wallet apps could ship their own version of the root certs.

They could impersonate an entity you genuinely want to pay and redirect the payment, yes. Fixing that is the point of certificate transparency. If a CA issued a certificate in your name that you didn't request, you could see it and report it for revocation.

I think it's stupid to say the PKI is "horribly broken". There aren't any cryptographic systems that do a better job. Andreas' suggestion is the kind of thing that is easy to suggest, but there is no reason to believe some Bitcoin-specific set of CA's would somehow be more secure or harder to compromise than the existing set. These problems are just fundamentally hard.

For big online merchants, the customers could sign the shop's public key in process of payment and easily create the trust line.
Or even better, they could sign it after the order arrive. As a form of review - I like the shop, they're fast, cheap and reliable therefore I'm going to sign their key with my key so all my friends who trust me can see this shop is legit.

All it takes is one dialog box showed to user after X blocks after the payment: "I see you paid for this order from company XY. Do you like it? |Yes| |No|"

Is there any flaw in my proposal?

edit: btw. thanks for the FAQ, Mike!

Mike thank you for the explanation.

Unfortunately I don't have time to dig deep enough to answer this for myself:
How does this relate to micro transaciton channels. You know I see micro transaction channels as the next big thing to solve

• instant payment
• micro payment
• privacy
• transaction fees
• blockchain size growth

between arbitrary parties via a small set of facilitators (micro transaction gateways or whatever you want to call them).

As a merchant will I be able to send a payment request "update the micro transaction channel xy to grant me 0.5BTC more" or how would that work? Especially if the transaction is a three-hop channel one. A – A's gateway – B's gateway – B.

What happens if I the attacker substitute the shop's address for my own, and then use those funds to pay the shop? You've just used your reputation to sign my key rather than the legit merchant's key, and you didn't even know it.

Bonus points: how does this scenario relate to The Silkroad when it comes to PGP communications with your anonymous vendor?

Jeremy Spilman/Mike Hearn style micro-transaction channels are just a mechanism to send funds from one person to another in such a way that the amount being transferred can be increased (renegotiated) gradually over time in a secure fashion. They're a clever mechanism, but with a very niche application; frankly I'd be very surprised to see them get all that much use. User's are never going to like or really understand why setting up a micro-payment channel has all this complex stuff about locking funds and what not, compared to just clicking the "Pay with your inputs.io/easywallet/whatever account!" button; only if those services are consistently shutdown by government forces will alternatives be attractive, and if they can't find at least one friendly country to operate from we've got serious problems...

Remember that micro-transaction channels can-not enable individual micro-transactions between arbitrary parties, and there are no facilitators involved.

Off-chain transactions is what you're thinking of, and mechanisms to use them haven't been standardized in any way - it's premature to talk about the payment protocol in relation to them because the payment protocol is only really useful in conjunction with multi-signature wallets. (when your PC and phone co-operate to authorize a transaction) The other features of the payment protocol are kinda nice, like refund addresses and messages, but they're incidental.

No off-chain tx system - like inputs.io - has plans yet to do true multi-factor authorization of payments AFAIK so the payment protocol doesn't yet add any value.

I agree this proposal is honestly not that good:

Sure sign addresses and sure have signed receipts - brilliant - but keep it away from the blockhain.

http://www.zdnet.com/has-the-nsa-broken-ssl-tls-aes-7000020312/

We don't need arcane CAs from the 90's, Bitcoin works BETTER.


The example given with the paycheck is really weak and doesn't even BEGIN to justify this: Just send your own money around a bit, say you paid using an online wallet or use coin-mixing TOR and the whole shebang.

With Bitcoin it is SOO easy to hide.

EDIT:
And when buying: If the buyer doesn't send, give him a bad review and crush his business.

It doesn't work like that. You don't know any of the other customers, most likely, so being presented with 100 signatures that are claimed to be 100 random people doesn't help. What if they are all fake?

So then you say, OK, customers can sign other customers! We'll make a web of trust!

Well, see the last question in the FAQ for why that sort of scheme eventually turns into the regular PKI.

I'll say it again - these are fundamentally difficult problems. If you think you've found a magic quick fix, then you are saying you found something lots of very bright cryptographers didn't. Probably you're wrong.

Currently they are unrelated. You could at some point extend the payment protocol to be a starting point for the micropayment channels protocol, and that way you'd get the benefits of the authentication, but it isn't supported today.

Doing a network of payment channels is rather complicated. I'm still beating the bugs out of the existing micropayments code and working on an example app and other important APIs for it. So we didn't even nail down the "A pays B" case yet.

That said I'm actually very close to having a nice, easy to use GUI for micropayment based file downloads/servers.  I think it will be the first truly end-user oriented contracts based app, which will be a great milestone. There are some bugs and some other things that need fixing, but I'm almost done. Perhaps if I can work at the same time as listening to the talks I'll even get it finished by the end of the Amsterdam conference. If you're here you could see it ;)

I'm not sure paid-for file downloads are really that big a deal, but the code is really simple so I'm hoping that someone will think it's cool and run with it, like by adding file upload capability, a simple P2P discovery network and so on. A few more features like that and we have the very beginnings of Gregory Maxwells StorJ vision. More importantly I want to turn it into a tutorial app, so everyone can see how we went from a protocol writeup on a wiki page to an actual working, reasonably attractive and professional looking GUI app usable (and programmable!) by mere mortals.

Once people see how we did it and that it's not really so hard, my dream is that we'll see real growth in slick, usable contract-based pure P2P applications. But Peter might be right - perhaps it won't work out like that. Only one way to find out! Up up and away! :-)

I also think that salary example is not that convincing

You will never get your salary paid in bitcoin if its price continuously rise, your boss will not be so stupid to pay you a deflative currency, he will pay you fiat money as long as he can get them, unless fiat money disappear from the world, bitcoin will not be used for purchasing at large scale. Employers will mortgage the bitcoin and get fiat loans to pay their employee  ;)

And I just did two polls, it seems most of the people's action is save the coin instead of spend it, or only spend a very small part of it in a much later time, and this ensured bitcoin's exchange rate will rise forever
https://bitcointalk.org/index.php?topic=295753.0

Anyway, I can see the purpose of this payment protocol is to extend the functionality in payment. But people might just ignore it like before, using that 34 character address makes people feel much more secure so that they might accept the inconvenience comes with that. And it is so cool  8) A web address? The first reaction is a phishing site

this should be a sticky thread, no doubt.

Thanks for this FAQ Mike!

Damn, it's truly a shame that it's impossible to buy bitcoins with fiat or vice-versa, because then the employer could just convert the paycheck to whatever the employee wants it as at the time of payment, regardless of what the merchant keeps their money as. /sarcasm

If you would like to learn more about deflation and bitcoin, read the many topics linked here:
https://www.google.com/cse?cx=016660200577587308545%3Aesf40ml9aag&ie=UTF-8&q=deflation&sa=Google+search#gsc.tab=0&gsc.q=deflation&gsc.page=1

Further discussion about deflation in this thread will be considered off-topic, so please refrain from replying to this post.

Could it be extensible to SSL certificate fingerprints stored in Namecoin blockchain, instead of X.509 (centralised) option?

Employers with more than just few employees are likely use a payroll service anyway so some type of bitcoin service with an audit trail and dispute recourse like Coinbase, BitPay etc., where they can just send it to a user account or email address is a more likely scenario.

They're no more likely to participate in complex, personalized bitcoin transaction protocols than the Dread Pirate Roberts is likely to get an SSL cerificate.

In a stroke of good timing, Mike Perry of the Tor project just posted a critique of the web of trust:

  https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html

He raises a lot of other issues that I hadn't discussed.

His description of the WoT as being a "quasi-religious hacker ritual" made me laugh. That pretty much sums it up.

It is.  That is why I am so unenthusiastic about key signing.  Beyond a single, direct connection, it's just geek wanking.

That is also why I do not think cjdns, with its WoT-like model of "only connect to your friends" will ever scale to any useful size.  cjdns is otherwise quite nice.

Could anybody point me in the general direction of this (or other) examples?

Also is there an official PR where the BIP is implemented?

It's already implemented and merged. Gavin's original pull req has a link to an example generator:

https://github.com/bitcoin/bitcoin/pull/2539
https://bitcoincore.org/~gavin/createpaymentrequest.php

Ritual bathing is a common religious practice, yet no-one uses its existence to disparage people who take showers.

WoT is a tool, and like every other tool it has strengths and weaknesses. It's main strength is that it's heavily decentralized, and attacking it on a broad scale is hard and always will be hard; with CA infrastructure attacking it is quite possible with the current legal environment, (witness the occasional commercial availability of MITM boxes with trusted CA certs in them) and could be made trivial with the stroke of a legislatures' pen. (it's well within the power of government to change the laws to force CA's to create bogus certs on demand) Absolutists like Mike Perry like to wank about scenarios with high-powered attackers, but forget that the human nature of WoT makes those attacks expensive and risky to pull off, and downright impractical to pull off in an automated fashion.

Privacy concerns are a genuine weakness of WoT, but they shouldn't be overstated either: in the case of "Edward" trying to find journalist "Glenn's" genuine PGP key while Edward may have good reasons not to PGP sign Glenn's key, the fact that 10 other well known journalists/writers/etc. signed Glenn's key makes it easier for Edward to validate Glenn's key. At the same time those signatures pose no particular threat to Glenn: he's a public figure anyway. In the scenario where both parties need to maintain their privacy ask yourself, how did those two parties find out about each other in the first place?

The real weakness of WoT is more metaphysical: by being imperfect enough to invite hyperbole about it's insecurities it discourages people from using cryptography at all. In particular people discount the value of PGP signing their public work, like emails to mailing lists, publications and source code, and because people don't see the value in doing so systems are frequently designed in ways that make doing so inconvenient or impossible. (like this forum) Perry appears to have some grasp of this point: "Every time I verify a signature from a key sent to an email address that is not mine ... add a tiny amount of trust to that key" but unfortunately goes on to talk about downloading keys from keyservers, somehow, without describing exactly what the keyserver is supposed to be validating. (Is this a PGP Corporation style email ownership verification? Timestamping/oldest key? Keyservers currently do absolutely no verification at all.)

Of course, if you're unable or unwilling to comprehend how PGP works you probably should just stick with central certificate authorities and hope that efforts like Google's CA transparency keep them honest, but keep in mind that you're outsourcing your security to someone else. If you are willing and able, don't let geeks wanking about how broken WoT is discourage you.

I think Mike's point is that any key in the WoT that became widely known enough and that signed enough keys is basically a CA, and that guy could be legally pressured in the same way as a PKI CA could (or even easier because they are unlikely to have a team of lawyers).

There is indeed value in establishing continuity across a long term key, although key management is hard (and revocation of bogus keys is even harder). I think one of the aspects of the PKI that is often overlooked is that although people love to complain about how there are so many CAs, the fact that there are lots does make a global revocation actually achievable. If there were only 5 then revocation would be much harder or even infeasible. CAs know that being revoked means immediate death of the business, so they put a lot of effort into guarding against accidental screwups.

The other thing is that with cert transparency, it forces the hand of governments - either you subvert the entire global infrastructure publicly, atomically and noisily, or a CA you abuse will end up getting quickly revoked, making it a rather expensive proposition.

My point is that while mass keysigning parties and magic trust in the "strong set" are in fact quasi-religious, using WoT however isn't. Mike Perry's evaluation of WoT as a stand-alone system, and complaining that you can't authenticate it in its entirety completely, throws the baby out with the bathwater. My example of an Edward using the WoT to help him determine if journalist Glenn's key is valid based on evidence like many different PGP signed articles by him and other journalists who have signed Glenn's key makes great use of the WoT.


CA revocation is a good point, but if anything it shows even more clearly why the WoT is valuable: how do you authenticate the CA's key and reputation? With dozens or hundreds of CAs you pretty much can't, especially because they're all indistinguishable to you, and furthermore the very act of revocation is out of your control - the power is really in the hands of the likes of Google and Mozilla. On the other hand, if your "CA" is a person you can easily reason about their reputation and stake in it and who they might reasonably be able to in turn authenticate.

In addition while a government trying to attack CA's can use any compromised CA to attack many different targets at once, attacking individuals may be successful, but any one attack only compromises WoT in a small domain - the cost and effort expended per target is vastly higher.

In any case if the global infrastructure is subverted there's little guarantee those efforts will actually be stopped ("We need to MITM the internet connections of terrorists and child pornorgraphers!") leaving us with WoT; having a community that knows and uses WoT with even marginal effectiveness makes those kinds of subversion attempts less attractive.

How about requesting the 2 or more certificates from different CAs? That makes a random hacker much more difficult to MITM attack

To prevent MITM attack from the government, we could require CAs from different countries. We could further divide countries into groups: US allies, Russian allies, tax havens, etc.

Unfortunately this doesn't work due to downgrading attacks: where do you store the fact that the site is certified by 2 certificates, given that the vast majority only have one?

If you do have a place to store that information, that place itself can be compromised; if it can't be compromised then why not just store the digest of the certificate there? (certificate pinning) It could be usefully used as a way to have certificate pinning with a way to change later though. (and in general it's reasonable for certificates to internally have n-of-m private key schemes)

Yes, for the journalist case you can establish trust in a key external to the WoT indeed.


All you need to do is convince yourself that Chrome/Firefox/etc will only add a CA if it passes audits, and you can do that by sampling their bug databases to find the original inclusion requests (I think, at least I've seen one or two of those in the past). Once you establish that root of trust and you look at what the audits involve, you can then go ahead and convince yourself all the CAs passed those audits.


Certainly not, you can revoke any CA you want at any time. You would then have to validate any certs signed by it out of band some how, no different to a WoT model. Most people don't do that because they prefer to outsource all this complexity.

I find it easier to reason about the trustworthyness of a CA actually, because of the auditing. A random person might or might not treat their private key well or have robust ID verification procedures in place.


Only for as long as that community isn't interesting. Otherwise, bye bye keyservers ...

Think harder - that example is not external to the WoT.


A random person doesn't have too: verifying that Bob is the right Bob is much easier when I know Bob. That's after all the strength of the web-of-trust model: used well it's based on human relationships, which makes so many of the audits and other procedures less important, and greatly increases the difficulty and expense of attacking any given target. Obviously this has a cost because verification is also more manual, but that's just an engineering trade-off.

Of course, certificate authorities don't have magic abilities to verify IDs either: if a CA signs a cert saying "Peter Todd", how do you know it's the Peter Todd known in the Bitcoin world anyway? Web-of-trust on the other hand naturally makes that distinction.


That would be terrible; I mean, it certainly wouldn't be possible to somehow distribute that data in a peer-to-peer fashion...

... since we are having an extended discussion on merits of different authentication approaches I'm going to bump this seemingly simple query

I was talking with Timo Hanke about this at the Amsterdam conference. X.509 PKI and Namecoin solve different problems, so I don't think the question makes much sense.

There's nothing inherently centralised about the PKI, it's just that for convenience we all tend to agree up front on a list of organisations that we think will do a reasonable job of verifying various kinds of identity (email addresses, business details etc).

But nothing stops you deciding you're going to rely on a totally different set instead. If you can convince other people to use one of the signers you trust, you could abandon the existing CA's entirely and switch to some new ones. You could have thousands or tens of thousands if you wanted. The current payment protocol doesn't let you sign with multiple cert chains so it'd be a bit awkward to do a smooth migration (you'd have to jump all at once), but that could be fixed in a future extension if someone was serious about establishing a different PKI.

Using Namecoin as a form of identity would be possible (with an extension to the payment protocol), but is problematic for a lot of different reasons.

Firstly, Namecoin is just a way to own a string. There's nothing meaningful about those strings because it's first come first serve. If someone turns up and claims they work for Mt Gox, and they give you a payment request that is signed by the owner of the namecoin string "mtgox.bit" then it's possible they really do work for Mark, or, they could be random stranger who just grabbed the name first. There's no way to tell, which renders the signature useless.

Secondly, even if you learn about the validity of this namecoin name out-of-band somehow (like MtGox announced they registered the name on their blog), it's tricky to make arbitrary pieces of text meaningful identities. This is going to sound a bit Matrix, but .... what is a string? A sequence of Unicode code points? A set of pixels on a screen? The sound it makes when pronounced? To a computer it's the first one. To a human reading about stuff on the web it's the second, and to a human who learned about your company from an excited conference attendee it's the third.

This matters because the mismatch can cause security holes. The DNS system and cert authorities have been battling this problem for years. The simplest hack is this: the following two domain names are NOT equal to a naively written computer program:

www.google.com is not www.gooɡle.com

Whether you can see this easily or not depends on your font. I can't see it here on my Ubuntu machine except for the fact that the autolinker stopped at the 4th G. But in the code sample below it's more obvious:


This is just one of many such confusion attacks that are possible. Part of the reason certificate authorities get audited and checked is to ensure they're watching out for things like this. As far as I know, Namecoin has no protections against this sort of thing and if it became popular then you'd see scammers descend on it extremely fast, just like they did for SSL.

In short, identity is a hard problem. It's not as simple as "centralised vs decentralised"  - the CA infrastructure has hundreds of players competing in a free market, and you can choose which ones you trust to do a good job. If you aren't happy with the existing set, make a new set, but just be aware that it's a way harder problem than keeping a database of strings to keys.

So cosy right on up to the NSA's CA system and we'll all be just swell then?

http://security.stackexchange.com/questions/38199/can-a-nation-state-adversary-perform-a-mitm-attack-by-compelling-a-ca-to-issue-t (http://security.stackexchange.com/questions/38199/can-a-nation-state-adversary-perform-a-mitm-attack-by-compelling-a-ca-to-issue-t)

What's that saying about the "power of the illusion of security ..."?

Please do re-read the FAQ. It talks about how ways that problem is being tackled. Obviously SSL is important enough that people aren't going to just shrug and give up on it.

Also, the world would notice quickly if there were bulk MITM attacks happening. The leaked documents have mentioned MITM attacks, but they were also mentioned as being highly targeted and not a dragnet. If the NSA have managed to break SSL in bulk it's not due to the CA system but rather their rumoured 2010 cryptanalytic breakthrough.

To be honest I'm tired of this argument. If you've got something better, show us. So far 100% of the proposed alternatives have massive gaping holes in them, with no clear path to a fix.

Wait a minute. How do people go to mtgox? They enter "mtgox.com" in their browser and trust their system to take them to the right place. From the little I know about the current CA system I guess the browser asks the CA server for a certificate fingerprint or something so I get a green lock icon or something if I am talking to a server with matching cert.

So in fact a little string is all that counts.

Probably most people even go there the first time by clicking some random link on the internets. If you fall for rntgox.com or some special character trick - bad luck. If the fake site is good and has a certificate for rntgox.com or even for "MtGox Corp. Lim. (cn)" - bad luck.

Again it's the little string that counts and the cert helps little.

If a company's main domain is betterexchange.bit with Namecoin TLS you can be more certain than with the current CA system that you are talking the server that you want to (assuming a strong implementation).

Not sure if this is being enforced currently in Namecoin but a string of simple characters is an ok solution imho.

The identity problem can be solved with Namecoin. Trust is the hard part but I'm sure it is possible and will come.

edit: I'm not saying the payment protocol should be implemented only with Namecoin domains/ids right now. But somehow I have a dislike against the current CA system, especially in combination with Bitcoin. It is just unbitcoinish.

Not namecoin alone.  Namecoin is just a storage method.

If you go to mtgox.com then you see MtGox Co. Ltd [JP] in the browser address bar (on Chrome). So if someone told you about this Japanese company called Mt Gox then you know you're at the right place and the website was verified as being owned by a real company with that name.

For newish companies that were born on the net usually their domain name IS their identity, but there are lots and lots of organisations in the world that aren't like that.


With the CA system that's not "Bad luck" it's a failure that would get investigated, at least in theory.

With Namecoin, sure, it's just bad luck. You lose your money. That's kind of the outcome we DON'T want, right?


And back in reality the companies main domain is betterexchange.com and they may or may not use NameCoin, so you're back to square one - you don't know if you're talking to the real owner or not.


Yes, brilliant, they "solve" the problem by simply not supporting any alphabet other than the English alphabet. That's not a solution, that's a cop-out.


It's a free market for providers that are unified by common cryptographic protocols. Does that remind you of something? The market for mining blocks, perhaps?

Your take on things is chiefly informed by your marauding ignorance and otherwise well documented (https://bitcointalk.org/index.php?topic=119073.msg1402462#msg1402462) facetiousness.

Stick to generating forks through failing to read code rather than opining on matters you are intellectually unqualified to comprehend.

Also read the relevant Trilema articles, explaining why power does not reside with you collection of fuckwits, and what the required steps are to remedy your problems there.

But in the final analysis you are bolting on "just trust us we're the good guys" payment protocol onto a labelled "trust no-one currency system".

Sounds like a bait and switch. The CA system is prime for MITM because it introduces a third party into every secure connect negotiation, it is complex enough to seem like it must be secure if you don't dig down into it ... but it is broken as all fuck and that's why the NSA loves and pushes it endlessly, eh Mike?

I'm just counting the days until ALL bitcoin transactions are going to be required by legal or regulatory measures to be via the surveillance dragnet payment protocol ... it's pretty transparent where this is heading.

Edit: ""We have over 960 Ph.D.s, over 4,000 computer scientists, over a thousand mathematicians." -Gen. Keith "Starship" Alexander - NSA

Even with the cooperation of the core devs I don't see that being effectively enforced. How do you make all the Chinese, Russian, and European miners and nodes play ball?

Believe in whatever wild conspiracy theories you like. There's no way I can give a good rebuttal to things that aren't happening. The rationale for these changes has been laid out in detail. If you think you found a government-proof way to achieve the same goals without the CA infrastructure, please do go ahead and implement it.

In all fairness, it has become a FAQ.  Given NSA/PRISM fun, it seems likely to remain so, no matter the hard evidence.  I got several variants of this question/complaint at the Atlanta crypto-currency conference, and reddit mirrored more of the same.

The core points I like to mention are

• There is a high likelihood that SSL & standard CAs are being used anyway.  It is probably a browser launching a payment from an https:// supplied page
• The payment protocol does not mandate SSL + standard CAs.  Other methods, including decentralized methods, are possible.

Perhaps it would be a good idea to specify a decentralized example.  PGP comes to mind, or a self-signed ECDSA scenario of bitcoin address or SIN (https://en.bitcoin.it/wiki/Identity_protocol_v1).

I wrote a post on adding OpenPGP to the payment protocol (https://bitcointalk.org/index.php?topic=300809.msg3226868#msg3226868) the other day.

What about certificate pinning to domains? MITMs with the co-operation of a rogue or forced CA will have very limited effectiveness.

Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System" Paragraph 2.

So could it be extensible to Namecoin stored self-signed certificate fingerprints?

Getting wedded to the broken CA system is a poor idea and your petulant non-rebuttals so far make me wonder if you already know you are on a hiding to nothing on this one.

I hate the CA system. As merchant I don't want to pay to some CAs just to have them confirm who I am. I use self signed certificates when necessary. Bitcoin ALREADY HAS message signing. USE THIS.
By just looking at BIP it disgusts me. I really hope you're not going to change the underlying bitcoin protocol to introduce your bip. Better start using namecoin, really!

Well, direct them to this thread. It's titled "FAQ on the payment protocol" for a reason. And it goes in depth on why PGP doesn't work for this. I'd hope that this thread can put it to bed once and for all.


These points are sound. However, the second point leads to the question "why not do a decentralised method to start with?" to which the answer of course is complicated, but boils down to "the CA infrastructure is not actually centralised". So even though the payment protocol leaves choice of PKI open, I don't make the last point anymore because it just leads people round in circles.

Ultimately this stuff boils down to the same arguments that go around endlessly about Bitcoin scalability. If running a Bitcoin node is "hard" where "hard" is left vague and undefined, is Bitcoin now "centralised"? The language is too vague to achieve any reasonable debate. The fact is that literally anyone can run a CA, the very name "authority" is meaningless in that sense, but running one well is quite hard for fundamental reasons. That's why Verisign run a CA and you don't - because you would suck at it. If you stopped sucking at it, then you'd be doing it professionally, at which point you would probably need to charge fees and then people would decide you're an authoritarian Pillar of Centralisation. Back to square one.

The payment protocol is in some sense doomed to be like the question, "do ASICs make bitcoin centralised?". I still see that come up repeatedly. People who enjoy flaming forums will never be satisfied, everyone else will just get on with it.

If you have DNSSEC you don't need the CA infrastructure for domain name validation. However DNSSEC does not remove CA's. It just merges them with DNS registrars instead. You can't pin certs to domains without that because otherwise, DNS itself can be MITM'd.

Rogue/forced CA's can be detected once cert transparency is online and rolled out. It will take a long time to upgrade everything, but when it's done certs can't be issued in secret anymore, which means bogus actions by a CA can be detected.

Anyway, as pointed out a million times already, the NSA are not going to forge payment requests from Amazon. This just isn't something they're going to care about. Lots of other types of criminals DO care about it, but the CA system is designed to handle those kinds of attackers, who are the ones we really care about. The NSA would be interested in snooping around, but payment requests don't give them any more info than they already have.

Sure I will rely on some rumor about some Japanese company called MtCocks Co. Ltd [JP]...   :D

That would certainly help to bring back all the Bitcoins.

The point is that there is no advantage of the current CA system. But it is expensive and potentially government controlled.

CA system has the same problem. Do you know a better solution? Obviously humans can only distinguish between a limited number of characters. Is base58 a cop-out, too?

No.


Given there are quite some voices of doubt in the community (see Hyena above) the question is does this have to go into the standard client right from the beginning?

Maybe this topic should be:
"VOTE on the payment protocol and the CA system to be included in standard client"

CA's verify DNS names and registrars are supposed to have policies in place to stop this kind of attack. But CA's are expected to also have some way to spot such attacks. For instance see here:

https://bugzilla.mozilla.org/show_bug.cgi?id=711366

Search for "homograph" and you can see how Atos plans to handle it. Their solution probably works, but it requires human intervention. This is the kind of reason there are fees attached to getting a cert - it represents actual work.


It should! Anyone can be a miner, in theory. In practice these days it requires some skill, time and capital investment, which is why it's done for profit.

Signing identities is the same. Anyone can do it. You can do it right now, just run a few openssl commands and you made yourself a root CA. But doing it well takes some effort, time and investment, which is why it's done for profit.

If you can't see the parallels, look closer.

Lol.

I like how you're dumb enough to compare mining, a industry with barriers to entry of as little as a few hundred dollars, (including paid time) to a industry where to make any money at all you have to convince some large user-base to adopt your product. Mozilla has 57 trusted root CA's, and the majority of those are very niche ones from large corporations and government-sponsored CA's. As for the "free-market" ones, you've got Symantec with 42% market share, Comodo Group with 26%, and Go Daddy with 14%, and GlobalSign with 7.7% - the four largest companies in the industry have 90% of the market. Not exactly a sign of a competitive free-market at work.

The reality is if Symantec was told to create some fake certificates because the FBI needed to confiscate some Bitcoins they would do as they were told. More importantly doing that wouldn't get them blacklisted because of their 42% market share - no browser is going to break almost half of the sites their users need access to.


You know, you've really got a way of arguing that's remarkably good at undermining your own position. I kinda like the payment protocol, and I want to see it implemented in it's current form so we've got something to use while better solutions for the CA problem are developed; please go away and let more reasonable people talk about it and the nuances involved before you turn public opinion against it.

I never cease to be amazed at how quickly and easily you insult anyone who you disagree with, Peter. It's a nasty habit that limits your effectiveness.

You understood my point perfectly well. You can become your own CA for much less than a few hundred dollars. Are you going to be handling millions of customers with that kind of investment? Duh, no. You can become a miner for a few hundred dollars. Are you going to be making as many blocks as ASICMiner? No.

Basically any activity that involves serious work turns into a market, and that market often ends up with big players. That does not make it less of a market.

If you think all the existing players in that market suck, go ahead and shake it up, just like StartSSL did.

As to revocation - we'd have to see what the browser makers do if/when a really large CA turns out to be routinely minting fake certs. So far if it's happening it has never been detected. Certs are a commodity, any CA can make one, so there's no particular reason to hold back. They can and have scheduled end dates for CA's to be revoked in the past, as they did with DigiNotar which was widely used in the Netherlands. It means people get a couple of months to buy a new cert from somewhere else, then browsers get updated and any site that fell behind sees errors. Painful for the people using the revoked CA but not infeasible.

But even if browser makers decided not to do that for some reason, wallet developers could certainly make different decisions. There's no requirement to use the same policies.

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

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.

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.

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

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/ (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.

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

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!"

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

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.

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.

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.

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

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.

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.

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

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.

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

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

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.

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.