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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <drice@greenmangosystems.com>) id 1Wwdu1-0001BN-BA
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 20:53:17 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of
greenmangosystems.com designates 209.85.128.169 as permitted
sender) client-ip=209.85.128.169;
envelope-from=drice@greenmangosystems.com;
helo=mail-ve0-f169.google.com;
Received: from mail-ve0-f169.google.com ([209.85.128.169])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wwdtz-0003OR-GV
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 20:53:17 +0000
Received: by mail-ve0-f169.google.com with SMTP id pa12so6812125veb.28
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jun 2014 13:53:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=Drq1Mna46MsMAGLukvRUTw81kKILyNrgUWqt1dG48z4=;
b=Ws0jQS+lt3ZyF5GtPTU6LhGUuV+gdYtPPmOnP4jCXn4eEahHuDexSMIiy6lgFxTqUa
1zJOLHq9546kEWJ0n2G+N8fo3rN3xaWQJ/yKcy8PIZxeel4M+swe9EzbUvYIuHiDPH+T
CjOeFiC1g+qrJvM1jFr07yMh+PW4NDAEEgYH+B18wwj4oV0sgS8AFSdLD7ZHKi7hjYP1
YbiWWjbwLdAdTMwU8H++iVik29bRoj+poct11mQ560MbncnBe7d4WF2OztuNiPu9XdkP
gkRmGM7S7lFGgYcexWST3xUVOUKOw65+UP3tAnxYmoHqvfmMnjPcoHO/zha4M6hpziwX
Obvg==
X-Gm-Message-State: ALoCoQkDqFxaButQeg8oH7XeKIC0nz8RZqCnrSspp69yy2Io9SbRPXa14gD585pKWFYSIHRWP2Cf
MIME-Version: 1.0
X-Received: by 10.220.94.146 with SMTP id z18mr2317583vcm.40.1402951989534;
Mon, 16 Jun 2014 13:53:09 -0700 (PDT)
Received: by 10.58.123.35 with HTTP; Mon, 16 Jun 2014 13:53:09 -0700 (PDT)
In-Reply-To: <CANEZrP3P-EzS22QCSLuY8u42pZG7yTPNjoa4prQaSZzEjbxESg@mail.gmail.com>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
<CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com>
<CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com>
<CADE3-jA8LizD8cjdqKm0pFc8OV7JqPBGhs4uvp6=VhEU2emV6w@mail.gmail.com>
<CANEZrP3KKSkD7_R0Dvt600b7vh0oia78vHhPrPqSGBbwf9DsSQ@mail.gmail.com>
<loom.20140616T181739-326@post.gmane.org>
<CANEZrP3er1NVoAiVmROTxQ3TC80r7enKaHkWjOYTbKehf7qJjQ@mail.gmail.com>
<loom.20140616T184930-521@post.gmane.org>
<CANEZrP2fg9k9fC+QAO2GQS7VC-JCtbEjubHB9j1TJtR9vuaDSQ@mail.gmail.com>
<loom.20140616T190550-931@post.gmane.org>
<CALDj+Bbvvs4rkrSOndk4rbt9JGwSwF1VeFk2XPjFy7Ro4O9heg@mail.gmail.com>
<CANEZrP384LFKaCbAL-p06FQdHHp1bqmcRs+XZDbwVXVrPRDS7g@mail.gmail.com>
<CAFDyEXg8OnoYCNLT1WeX2tBPTB_zcXsZ6ujP_8YmPvGyf4pzkw@mail.gmail.com>
<CANEZrP2NKG8etGtGgbkA8rPr3BqCMPmVQ-3xqiKXVOK2vf9+7w@mail.gmail.com>
<CAFDyEXistfW2Y-93ipty_Z5NgtqT_1BRUNqBsYQNRFz_GjOQ6w@mail.gmail.com>
<CANEZrP3P-EzS22QCSLuY8u42pZG7yTPNjoa4prQaSZzEjbxESg@mail.gmail.com>
Date: Mon, 16 Jun 2014 13:53:09 -0700
Message-ID: <CAFDyEXhh=1uX+hrio5dbu8vchDc4pSOrW-PLWq8dHgF4tD4vHA@mail.gmail.com>
From: Daniel Rice <drice@greenmangosystems.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a11c1e9d0f9352304fbfa3603
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 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: 1Wwdtz-0003OR-GV
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Lawrence Nahum <lawrence@greenaddress.it>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol
backwards compatible proto buffer extension
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: Mon, 16 Jun 2014 20:53:17 -0000
--001a11c1e9d0f9352304fbfa3603
Content-Type: text/plain; charset=UTF-8
The trust can be more automated in this case than it can with CAs. The
difference is that when a CA does something it shouldn't, like generates an
extra cert for a government to use in spoofing a site, nobody knows about
it, unless they mess up. Double spends on the network can be monitored and
stored for history. Merchants can and will share information on instant
provider trust with eachother, so they will essentially be able to build up
a credit history on a given instant provider without really knowing who
they are.
On Mon, Jun 16, 2014 at 1:46 PM, Mike Hearn <mike@plan99.net> wrote:
> On Mon, Jun 16, 2014 at 10:37 PM, Daniel Rice <drice@greenmangosystems.com
> > wrote:
>
>> True, that would work, but still how are you going to bootstrap the
>> trust? TREZOR is well known, but in a future where there could be 100
>> different companies trying to release a similar product to TREZOR it seems
>> like one company could corner the market by being the only one that is an
>> accepted instant provider at most vendors
>>
>
> It's no different to the CA problem. People can only mentally handle a few
> trust anchors, so for SSL it goes:
>
> 1 User -> 2-3 browser makers -> 100's of CAs -> millions of websites
>
> The trust starts out narrowly funnelled and grows outwards as things get
> outsourced.
>
> For this it'd go
>
> 1 merchant -> 4-5 payment processing engines -> dozens of hardware
> manufacturers -> hundreds of thousands of devices
>
>
>
--001a11c1e9d0f9352304fbfa3603
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The trust can be more automated in this case than it can w=
ith CAs. The difference is that when a CA does something it shouldn't, =
like generates an extra cert for a government to use in spoofing a site, no=
body knows about it, unless they mess up. Double spends on the network can =
be monitored and stored for history. Merchants can and will share informati=
on on instant provider trust with eachother, so they will essentially be ab=
le to build up a credit history on a given instant provider without really =
knowing who they are.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Jun 1=
6, 2014 at 1:46 PM, Mike Hearn <span dir=3D"ltr"><<a href=3D"mailto:mike=
@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
class=3D"">On Mon, Jun 16, 2014 at 10:37 PM, Daniel Rice <span dir=3D"ltr"=
><<a href=3D"mailto:drice@greenmangosystems.com" target=3D"_blank">drice=
@greenmangosystems.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">True, that would work, but =
still how are you going to bootstrap the trust? TREZOR is well known, but i=
n a future where there could be 100 different companies trying to release a=
similar product to TREZOR it seems like one company could corner the marke=
t by being the only one that is an accepted instant provider at most vendor=
s</div>
</blockquote><div><br></div></div><div>It's no different to the CA prob=
lem. People can only mentally handle a few trust anchors, so for SSL it goe=
s:</div><div><br></div><div>=C2=A0 =C2=A01 User -> 2-3 browser makers -&=
gt; 100's of CAs -> millions of websites</div>
<div><br></div><div>The trust starts out narrowly funnelled and grows outwa=
rds as things get outsourced.</div><div><br></div><div>For this it'd go=
</div><div><br></div><div>=C2=A0 =C2=A01 merchant -> 4-5 payment process=
ing engines -> dozens of hardware manufacturers -> hundreds of thousa=
nds of devices</div>
<div><br></div><div><br></div></div></div></div>
</blockquote></div><br></div>
--001a11c1e9d0f9352304fbfa3603--
|
