From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VfSsn-0000rY-T1 for bitcoin-development@lists.sourceforge.net; Sun, 10 Nov 2013 11:08:45 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.219.53 as permitted sender) client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com; helo=mail-oa0-f53.google.com; Received: from mail-oa0-f53.google.com ([209.85.219.53]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VfSsm-0006nX-Ip for bitcoin-development@lists.sourceforge.net; Sun, 10 Nov 2013 11:08:45 +0000 Received: by mail-oa0-f53.google.com with SMTP id j17so4277362oag.12 for ; Sun, 10 Nov 2013 03:08:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.28.134 with SMTP id b6mr13872852obh.27.1384081719160; Sun, 10 Nov 2013 03:08:39 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.156.42 with HTTP; Sun, 10 Nov 2013 03:08:38 -0800 (PST) In-Reply-To: <0887034B-AA65-468B-A8DB-4DF1E6C27DA2@gmail.com> References: <0887034B-AA65-468B-A8DB-4DF1E6C27DA2@gmail.com> Date: Sun, 10 Nov 2013 12:08:38 +0100 X-Google-Sender-Auth: fktnxekxMOd4TqGbIi2oDuw7awQ Message-ID: From: Mike Hearn To: Taylor Gerring Content-Type: multipart/alternative; boundary=001a11c2903c36192b04ead0a3ec X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: doubleclick.net] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VfSsm-0006nX-Ip Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Extending the Payment Protocol with vCards X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 11:08:46 -0000 --001a11c2903c36192b04ead0a3ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey Taylor, It's great to see people thinking about payment protocol extensions. I'm not totally convinced vCard support is the best idea relative to social network integration - I can't recall the last time I saw someone use a vCard. However, that should not hold you back from experimenting or prototyping. All an extension requires is some tag numbers and we're not in danger of running out of numbers any time soon. The reason I favour social network integration is because those are the ID's people already have. Distributed social networks (like the PGP web of trust) have never really taken off, and fixing that is an entirely separate project to Bitcoin. Doing so is quite easy. Major social networks all have a concept of a user ID, moreover, one that can be queried without any kind of API authorization for basic info. Examples: https://graph.facebook.com/i.am.the.real.mike https://plus.google.com/s2/u/0/photos/profile/114798402540078632611 So you could simply embed a social network URL into a payment request, and use that to associate a name/photo with a payment. That would be unauthenticated (the sender is not proving they are the real owner of the social network profile). However, authentication may not turn out to be necessary. If it were to be, then steganographically embedding a key into the profile picture and signing the payment request with it would be a way to do so. On Sat, Nov 9, 2013 at 6:43 PM, Taylor Gerring wr= ote: > Hi everyone, > > I made a post on the BitcoinTalk forums < > https://bitcointalk.org/index.php?topic=3D329229.0> outlining how the > Payment Protocol could be extended with optional vCard support to increas= e > the usability of Payment Protocol for user-to-user transactions and impro= ve > the user experience in wallets supporting PP. > > I=E2=80=99ve outlined the concept in as much detail as my feeble brain ca= n handle, > drawing on BIP 0070 itself and Mike Hearn=E2=80=99s Payment Protocol FAQ.= I know > there is interest in =E2=80=9Ccontact exchange=E2=80=9D functionality fro= m the Hive team, > so I=E2=80=99m hoping this will begin a discussion on how we can make wal= lets more > friendly in a standard way. > > Please read, digest, and let me know if you have any feedback. > > Thanks, > > Taylor Gerring > > > > > > -------------------------------------------------------------------------= ----- > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the mo= st > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=3D60136231&iu=3D/4140/ostg.= clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a11c2903c36192b04ead0a3ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Taylor,

It's great to see peopl= e thinking about payment protocol extensions. I'm not totally convinced= vCard support is the best idea relative to social network integration - I = can't recall the last time I saw someone use a vCard. However, that sho= uld not hold you back from experimenting or prototyping. All an extension r= equires is some tag numbers and we're not in danger of running out of n= umbers any time soon.

The reason I favour social network integration is becau= se those are the ID's people already have. Distributed social networks = (like the PGP web of trust) have never really taken off, and fixing that is= an entirely separate project to Bitcoin.

Doing so is quite easy. Major social networks all have = a concept of a user ID, moreover, one that can be queried without any kind = of API authorization for basic info. Examples:


So you could simply embed a social network URL in= to a payment request, and use that to associate a name/photo with a payment= . That would be unauthenticated (the sender is not proving they are the rea= l owner of the social network profile). However, authentication may not tur= n out to be necessary. If it were to be, then steganographically embedding = a key into the profile picture and signing the payment request with it woul= d be a way to do so.


On Sat,= Nov 9, 2013 at 6:43 PM, Taylor Gerring <taylor.gerring@gmail.com> wrote:
Hi everyone,

I made a post on the BitcoinTalk forums <https://bitcointalk.org/i= ndex.php?topic=3D329229.0> outlining how the Payment Protocol could = be extended with optional vCard support to increase the usability of Paymen= t Protocol for user-to-user transactions and improve the user experience in= wallets supporting PP.

I=E2=80=99ve outlined the concept in as much detail as my feeble brain can = handle, drawing on BIP 0070 itself and Mike Hearn=E2=80=99s Payment Protoco= l FAQ. I know there is interest in =E2=80=9Ccontact exchange=E2=80=9D funct= ionality from the Hive team, so I=E2=80=99m hoping this will begin a discus= sion on how we can make wallets more friendly in a standard way.

Please read, digest, and let me know if you have any feedback.

Thanks,

Taylor Gerring




-----------------------------------------------------------------------= -------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explor= e
techniques for threading, error checking, porting, and tuning. Get the most=
from the latest Intel processors and coprocessors. See abstracts and regist= er
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D60136231&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a11c2903c36192b04ead0a3ec--