1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
|
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 <joel.kaartinen@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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 <bitcoin-development@lists.sourceforge.net>
(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 <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"
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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" <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" <<a
moz-do-not-send="true" href="mailto:mike@plan99.net">mike@plan99.net</a>>
wrote:<br>
><br>
> 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>
><br>
> 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 & 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&iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=122218951&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--
|
