From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WLzC4-0004eT-9V for bitcoin-development@lists.sourceforge.net; Fri, 07 Mar 2014 18:08:24 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.46 as permitted sender) client-ip=74.125.83.46; envelope-from=joel.kaartinen@gmail.com; helo=mail-ee0-f46.google.com; Received: from mail-ee0-f46.google.com ([74.125.83.46]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WLzBz-0008K7-Ah for bitcoin-development@lists.sourceforge.net; Fri, 07 Mar 2014 18:08:24 +0000 Received: by mail-ee0-f46.google.com with SMTP id t10so1888446eei.33 for ; Fri, 07 Mar 2014 10:08:13 -0800 (PST) X-Received: by 10.14.88.131 with SMTP id a3mr20761281eef.64.1394215693073; Fri, 07 Mar 2014 10:08:13 -0800 (PST) Received: from [192.168.1.182] (cable-roi-50dc9a-39.dhcp.inet.fi. [80.220.154.39]) by mx.google.com with ESMTPSA id x6sm9392113eew.20.2014.03.07.10.08.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Mar 2014 10:08:12 -0800 (PST) Message-ID: <531A0AFD.5010702@gmail.com> Date: Fri, 07 Mar 2014 20:07:57 +0200 From: Joel Kaartinen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040508020601040807000507" X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -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 (joel.kaartinen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1WLzBz-0008K7-Ah Subject: Re: [Bitcoin-development] Instant / contactless payments 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: Fri, 07 Mar 2014 18:08:24 -0000 This is a multi-part message in MIME format. --------------040508020601040807000507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think a reputation network is more complicated than is needed for this. This can be solved by the market. What is needed is a simple method for each individual user to mark certain merchant as trusted. For example, if your device gets an untrusted payment request, it'll make a small sound, light up the screen and ask the user to authorize the payment. The user then has the choice of adding the merchant to trust list, authorizing just a single transaction or not paying (and perhaps adding to the user's publicly shared untrusted list?). This way, even lacking a trust architecture, only the first payment to a merchant needs to take several seconds. If trust is granted, the next payments will be swift. The lack of chargebacks presents a clear risk to the customer, though, so a need for a third party that can keep the merchants honest exists. This opens up markets for transaction insurance companies. Even though bitcoin transactions are final, if a transaction insurance company offers to cover your losses in the event of fraudulent charge, the risk is practically eliminated. Such an insurance company would have a strong incentive to make sure the merchants they insure for behave. Otherwise they'll suffer the losses. I think this would result in an equally trustworthy but more decentralized system than with credit cards. - Joel On 06.03.2014 16:20, Brooks Boyd wrote: > > > On Mar 6, 2014 3:47 AM, "Mike Hearn" > wrote: > > > > I just did my first contactless nfc payment with a MasterCard. It > worked very well and was quite delightful - definitely want to be > doing more of these in future. I think people will come to expect this > kind of no-friction payment experience and Bitcoin will need to match > it, so here are some notes on what's involved. > > > > 3) Have some kind of decentralised reputation network. I spent some > time thinking about this, but it rapidly became very complicated and > feels like an entirely separate project that should stand alone from > Bitcoin itself. Perhaps rather than try to make a global system, > social data could be exchanged (using some fancy privacy preserving > protocols?) so if your friends have decided to trust seller X, your > phone automatically trusts them too. > > A reputation network might be an interesting idea, or several > different networks with different curators (to prevent complete > centralization), like how the US credit score system has three main > companies who track your score. Something like a GPG ring of trust, > with addresses signing other addresses would work well, if some sort > of Stealth address or HD wallet root was the identity gaining the > reputation, then address re-use wouldn't have to be mandatory. > > > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --------------040508020601040807000507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I think a reputation network is more complicated than is needed for this. This can be solved by the market.

What is needed is a simple method for each individual user to mark certain merchant as trusted. For example, if your device gets an untrusted payment request, it'll make a small sound, light up the screen and ask the user to authorize the payment. The user then has the choice of adding the merchant to trust list, authorizing just a single transaction or not paying (and perhaps adding to the user's publicly shared untrusted list?).

This way, even lacking a trust architecture, only the first payment to a merchant needs to take several seconds. If trust is granted, the next payments will be swift.

The lack of chargebacks presents a clear risk to the customer, though, so a need for a third party that can keep the merchants honest exists. This opens up markets for transaction insurance companies. Even though bitcoin transactions are final, if a transaction insurance company offers to cover your losses in the event of fraudulent charge, the risk is practically eliminated.

Such an insurance company would have a strong incentive to make sure the merchants they insure for behave. Otherwise they'll suffer the losses. I think this would result in an equally trustworthy but more decentralized system than with credit cards.

- Joel

On 06.03.2014 16:20, Brooks Boyd wrote:


On Mar 6, 2014 3:47 AM, "Mike Hearn" <mike@plan99.net> wrote:
>
> I just did my first contactless nfc payment with a MasterCard. It worked very well and was quite delightful - definitely want to be doing more of these in future. I think people will come to expect this kind of no-friction payment experience and Bitcoin will need to match it, so here are some notes on what's involved.
>
> 3) Have some kind of decentralised reputation network. I spent some time thinking about this, but it rapidly became very complicated and feels like an entirely separate project that should stand alone from Bitcoin itself. Perhaps rather than try to make a global system, social data could be exchanged (using some fancy privacy preserving protocols?) so if your friends have decided to trust seller X, your phone automatically trusts them too.

A reputation network might be an interesting idea, or several different networks with different curators (to prevent complete centralization), like how the US credit score system has three main companies who track your score. Something like a GPG ring of trust, with addresses signing other addresses would work well, if some sort of Stealth address or HD wallet root was the identity gaining the reputation, then address re-use wouldn't have to be mandatory.



------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk


_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--------------040508020601040807000507--