Extending the Payment Protocol with vCards

[tgerring]

This post describes a method by which users of Bitcoin wallets can exchange contact information as an extension of the Payment Protocol to improve the experience of sending bitcoins between non-merchant users. This represents a request-for-comment from the Bitcoin community and all feedback is appreciated.

As you may know, BIP 70-72 will be included in the next major release of the Satoshi client (Bitcoin-QT). However, this functionality is squarely aimed at merchants creating PaymentRequests. Mike Hearn eventually posted a "FAQ on the Payment Protocol" thread which included this subsequent 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.

So what happens if Bob wants to send Alice a payment that Alice didn't specifically issue a PaymentRequest for? As Mike outlined, Alice should have a PaymentRequest dangling out on the internet somewhere that Bob can fulfill. However, because Bob met Alice at a Bitcoin meetup and they didn't previously know each other very well, wouldn't it be nice if Bob could transmit some additional information aside from the name on his SSL certificate? What if Bob wants Alice to have some additional information about him, such as a telephone number or photo?

vCard is a standard that works to fulfill the need of exchanging a "virtual business card" and BIP 0070 defines how extensibility should work:

The protocol buffers serialization format is designed to be extensible. In particular, new, optional fields can be added to a message and will be ignored (but saved/re-transmitted) by old implementations.

PaymentDetails messages may be extended with new optional fields and still be considered "version 1." Old implementations will be able to validate signatures against PaymentRequests containing the new fields, but (obviously) will not be able to display whatever information is contained in the new, optional fields to the user.

Therefore, I suggest it be reasonable to include optional vCard data as an extra field in Payment and PaymentACK. While there may not be a concrete use-case for merchants to leverage this field, users performing user-to-user transactions via Payment Protocol may find it helpful to be able to optionally attach extra personal information, especially when paying a person for the first time. Subsequently, should Alice wish to share her contact details with Bob, she can respond with a PaymentACK, including a similar optional vcard field.

Wallet software can be made aware of this "vcard" field and make use of the data directly or launch an appropriate application on that platform which can handle vCards, such as a contact/email/calendar software. The end result of this is that the Payment Protocol becomes much more useful for user-to-user payments, since user-consumable information can be exchanged at their discretion.

In my eyes, to make this workable, several outstanding issues would need to be addressed:
What if Alice wants to initiate a PaymentRequest to Bob to pay him back for lunch? Could/should a vCard be included then?
Yes, maybe, I don't know. I could make an argument for an optional vcard field at each step of the process, depending where it's initiated from.

Won't this lead to everyone including vCards for everything?
Yes, maybe, I don't know. Wallet software could maintain an association of identities/vCards to limit extraneous data sharing or default sharing to "off", however it would always be up to the user to indicate when he wants information shared.

How will Alice know that the payment request from Bob is from the correct Bob?
This is a very complicated topic to answer and BIP 70 has so far only described identity/security through PKI. However, Peter Todd made a post entitled "Adding OpenPGP to the payment protocol" which describes how to implement the Payment Protocol with PGP/GPG. Following his guidance would allow the simple exchange of a short 8-charcter PGP key in-person. When Alice receives Bob's encrypted Payment, her wallet software (not already having Bob's key) could prompt her for Bob's PGP key, which could then be retrieved from a PGP keyserver. Because this PGP key was exchanged out-of-band (i.e. in person), it would provide sufficient personal identity verification.

Why not send the vCard separate from the Payment Request?
Ease-of-use, primarily. For wallets already implementing the Payment Protocol, vCard support would be simple awareness and decoding of a single extra field. No need to bundle it up into a separate file. Additionally, being a part of Payment Protocol would allow the information to be transmitted "on the wire" instead of having to relay a separate physical file.

vCard has a lot of formats. Which one should be implemented?
I'm not a vCard expert, but I'd be partial to the JSON-encoded representation, known as jCard. I have no idea what the compatibility matrix looks like between versions and consuming software.

[1713996953]

1713996953

[1713996953]

1713996953

[1713996953]

1713996953

[hivewallet]

Perfect timing on this.

[MilkyWayMasta]

Little by little I see your idea extending towards this: https://www.youtube.com/watch?v=IVFBwDHWxG0

[hivewallet]

Little by little I see your idea extending towards this: https://www.youtube.com/watch?v=IVFBwDHWxG0

I think you've got the idea, indeed.

[tgerring]

Little by little I see your idea extending towards this: https://www.youtube.com/watch?v=IVFBwDHWxG0

+1

Anything that allows us operate our own clouds instead of relying on third-party solution is an improvement. I posted this thread's topic to the dev mailing list and Mike Hearn responded suggesting we rely on social network APIs, but I don't see how relying on yet another party improves Bitcoin whatsoever.

Maybe this should lend some context:

What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party.

[Mike Hearn]

Don't get me wrong, I would love to see fully decentralised P2P infrastructure for everything. But creating just one of these infrastructures and making it competitive is an absolutely massive piece of work. Trying to do everything at once is trying to boil the ocean.

If someone were to create a usable, appealing P2P/distributed social network and it took off, by all means, go ahead and integrate it with the payment protocol ... but features that nobody is going to use due to the unpopularity of the underlying integrated system have a real cost.

[hivewallet]

Don't get me wrong, I would love to see fully decentralised P2P infrastructure for everything. But creating just one of these infrastructures and making it competitive is an absolutely massive piece of work. Trying to do everything at once is trying to boil the ocean.

If someone were to create a usable, appealing P2P/distributed social network and it took off, by all means, go ahead and integrate it with the payment protocol ... but features that nobody is going to use due to the unpopularity of the underlying integrated system have a real cost.

Let's say that Bitcoin wallets are presently in the hands of less than .01% of the world's population. That implies that there are ages and ages of massive research and development ahead of us... So why dismiss this kind of an idea now? Other than what we may ambitiously plan, we don't know what is coming. Besides, aren't we talking about bootstrapping on top of the payment protocol itself?

[Mike Hearn]

I don't want to come across as dismissive. If someone wants to build a P2P social network, and integrate it with Bitcoin, that's great - more power to them.

It depends what your goal is. If your goal is "build a p2p social network with payments functionality", it's the right approach. If your goal is "make Bitcoin more usable" it's the wrong approach (currently).

[tgerring]

I don't want to come across as dismissive. If someone wants to build a P2P social network, and integrate it with Bitcoin, that's great - more power to them.

It depends what your goal is. If your goal is "build a p2p social network with payments functionality", it's the right approach. If your goal is "make Bitcoin more usable" it's the wrong approach (currently).

Not sure on this inherent need for a "social network". Plenty of people use the internet without Facebook/Twitter/etc. I think the idea to be able to integrate these and Bitcoin is a fine idea, but I don't see it as an absolute requirement in a world of pseudonymity.

[Mike Hearn]

It's very rare for someone to pay someone else with no idea at all of who that person is. Even on black markets, you know you're paying some specific identity (it just happens to not be their legal identity). But for most payments you do know who you are paying. Bitcoin strives to ensure other people don't know who you are paying, but it doesn't require that you yourself don't know.

Outside of the context of illegal transactions, it's typically A-OK if someone requests payment and their name/photo shows up in your wallet. Indeed it's helpful so you can remember what a transaction was about.

[hivewallet]

It's very rare for someone to pay someone else with no idea at all of who that person is. Even on black markets, you know you're paying some specific identity (it just happens to not be their legal identity). But for most payments you do know who you are paying. Bitcoin strives to ensure other people don't know who you are paying, but it doesn't require that you yourself don't know.

Outside of the context of illegal transactions, it's typically A-OK if someone requests payment and their name/photo shows up in your wallet. Indeed it's helpful so you can remember what a transaction was about.

They may know who that person is, but we're talking about a matter of convenience. If (some address) sends me money, I would greatly prefer that a packet of data that can pre-populate my contact list be included. Otherwise I might spend 3 minutes fiddling with it to add such data, if I ever do at all. It's as simple a need as that. Perhaps a small UX tweak, but from my view a substantially time-saving and helpful one.

[tgerring]

It's very rare for someone to pay someone else with no idea at all of who that person is. Even on black markets, you know you're paying some specific identity (it just happens to not be their legal identity). But for most payments you do know who you are paying. Bitcoin strives to ensure other people don't know who you are paying, but it doesn't require that you yourself don't know.

Outside of the context of illegal transactions, it's typically A-OK if someone requests payment and their name/photo shows up in your wallet. Indeed it's helpful so you can remember what a transaction was about.

I've sent money to friends for various things (experience Bitcoin, payment for beers, etc.), and while they know who I am, all they see is a transaction received on 1ThisIsARandomAddress.

You've got to admit, it's a terrible user experience. By having standardized contact data embeddable, we could transfer a name/photo/something to provide a better UX. After all, the Foundation is pushing for one-time-use addresses, so the label/address association goes out the window.

Mike, if we're all out to lunch with intent of splitting the bill equally and you receive 4 payments in equal amounts. How do you know whose refund address is whose? A crappy certificate name?

[hivewallet]

You've got to admit, it's a terrible user experience. By having standardized contact data embeddable, we could transfer a name/photo/something to provide a better UX. After all, the Foundation is pushing for one-time-use addresses, so the label/address association goes out the window.

+1000

[Mike Hearn]

Sure, we're all in violent agreement that there's a UX problem to solve. The question is just a matter of how to solve it. And actually there's no reason that we can't have multiple solutions at once.

To make progress here, what I suggest is that you wait a little bit until the payment protocol is implemented in the Android wallet app, and then prototype adding it to that (as I guess, person to person payments are often mobile). Once it's working and people agree that it's good, you could turn it into a BIP.

[tgerring]

Sure, we're all in violent agreement that there's a UX problem to solve. The question is just a matter of how to solve it. And actually there's no reason that we can't have multiple solutions at once.

To make progress here, what I suggest is that you wait a little bit until the payment protocol is implemented in the Android wallet app, and then prototype adding it to that (as I guess, person to person payments are often mobile). Once it's working and people agree that it's good, you could turn it into a BIP.

Wait, so you're suggesting we code first THEN write the spec? Seems a bit backwards, no?

I don't understand the objection to discussing how to exchange contact information in a standard format. Perhaps no one else sees this as being a problem since there's only three people on this thread. Would love to see other developers comment on this idea... unless they've already given up on the Payment Protocol as a solution for users?

[Mike Hearn]

No, not at all. Good standards always start with the code first, and the spec second. If you don't do an implementation then you invariably encounter some detail whilst writing the code that you had previously overlooked, or find ways to do things in an easier way, and then you want to change the spec. Also, having an implementation makes it easy for other developers to test their code against yours so they can check it's compatible.

The payment protocol itself was done this way. We prototyped some ideas in code, and once the implementation was largely finished, it became a BIP.

[tgerring]

No, not at all. Good standards always start with the code first, and the spec second. If you don't do an implementation then you invariably encounter some detail whilst writing the code that you had previously overlooked, or find ways to do things in an easier way, and then you want to change the spec. Also, having an implementation makes it easy for other developers to test their code against yours so they can check it's compatible.

The payment protocol itself was done this way. We prototyped some ideas in code, and once the implementation was largely finished, it became a BIP.

Mike, respectfully (or not--I don't seem to be getting any), no matter the topic, all I hear is "wait".

* Need a refund address? Wait for Payment Protocol.
* Want to discuss contact exchange? Wait for Payment Protocol Android implementation.
* Want an answer to "redlisting"? Wait for the Foundation to publish an official position.
* Payment Protocol secured by PGP instead of PKI? Thread locked.

I'm starting to question what value the Bitcoin Foundation provides for the community if they're just going to ignore our requests to implement specific things. i.e. How long have we been waiting for spendfrom/coincontrol in QT? The Foundation pays developers to work on "important" features, but if those features deviate too far from what the core community wants, they're going to paint themselves into a corner and have no users left at all.

Since I apparently need a Official Membership Stamp of Approval(tm) from the Bitcoin Foundation before speaking up, what can us feeble-minded developers work on that will have the almighty blessing of the Foundation? i.e. Where are its priorities? Since Foundation forums are locked from non-members, I'd really love to know.

[Mike Hearn]

You realise the foundation only pays Gavin, right? It's not like there's an army of people waiting for people to suggest features. As you aren't writing code yourself, what possible answer can anyone give you beyond, "wait got someone else to do that".

[tgerring]

You realise the foundation only pays Gavin, right? It's not like there's an army of people waiting for people to suggest features. As you aren't writing code yourself, what possible answer can anyone give you beyond, "wait got someone else to do that".

On the contrary, I am a developer--hence the request-for-comment.

So I'll ask again: "What can developers work on that will have the almighty blessing of the Foundation?"

[Mike Hearn]

Hmm, do we need a document somewhere (on bitcoin.org?) that clears this up? The Foundation pays Gavin, but that doesn't mean it controls development or tells him what to do. His mission from the Foundation can be summed up as, "carry on doing that thing you do".

So you don't need any blessing. For a payment protocol extension, all you need to do is grab some numbers from the extensions wiki page. Then go ahead and write code (for any wallet you want). There's really no process or bureaucracy here.