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; 
Message-ID: <531A0AFD.5010702@gmail.com>
Date: Fri, 07 Mar 2014 20:07:57 +0200
From: Joel Kaartinen <joel.kaartinen@gmail.com>
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: <CANEZrP3w9c_UX3dd+7LdWNXCEwjnAG+bYWxqKYo_fzakWQu=Bg@mail.gmail.com>
	<CANg-TZBv0zT6PywWJwug0DtzhQkXeE+9nMY14xKAfCysGfgkFg@mail.gmail.com>
In-Reply-To: <CANg-TZBv0zT6PywWJwug0DtzhQkXeE+9nMY14xKAfCysGfgkFg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------040508020601040807000507"
Subject: Re: [Bitcoin-development] Instant / contactless payments
Precedence: list

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" <mike@plan99.net
> <mailto: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
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">I think a reputation network is more
      complicated than is needed for this. This can be solved by the
      market.<br>
      <br>
      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?).<br>
      <br>
      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. <br>
      <br>
      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.<br>
      <br>
      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.<br>
      <br>
      - Joel<br>
      <br>
      On 06.03.2014 16:20, Brooks Boyd wrote:<br>
    </div>
    <blockquote
cite="mid:CANg-TZBv0zT6PywWJwug0DtzhQkXeE+9nMY14xKAfCysGfgkFg@mail.gmail.com"
      type="cite">
      <p dir="ltr"><br>
        On Mar 6, 2014 3:47 AM, "Mike Hearn" &lt;<a
          moz-do-not-send="true" href="mailto:mike@plan99.net">mike@plan99.net</a>&gt;

        wrote:<br>
        &gt;<br>
        &gt; 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.<br>
        &gt;<br>
        &gt; 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.</p>
      <p dir="ltr">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.</p>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion &amp; 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.
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=122218951&amp;iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=122218951&amp;iu=/4140/ostg.clktrk</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

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