summaryrefslogtreecommitdiff
path: root/da/0d215cd54513e2a39895e818c2ed4983e64746
blob: 66f24bf6c559075fd6a2a3d0ff8bc26c27198623 (plain)
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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1Wwdnq-0000re-Hp
	for bitcoin-development@lists.sourceforge.net;
	Mon, 16 Jun 2014 20:46:54 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.182 as permitted sender)
	client-ip=209.85.214.182; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f182.google.com; 
Received: from mail-ob0-f182.google.com ([209.85.214.182])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Wwdno-0007FS-Ra
	for bitcoin-development@lists.sourceforge.net;
	Mon, 16 Jun 2014 20:46:54 +0000
Received: by mail-ob0-f182.google.com with SMTP id nu7so6472371obb.27
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 16 Jun 2014 13:46:47 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.70.200 with SMTP id o8mr10386183oeu.55.1402951607375;
	Mon, 16 Jun 2014 13:46:47 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.162 with HTTP; Mon, 16 Jun 2014 13:46:47 -0700 (PDT)
In-Reply-To: <CAFDyEXistfW2Y-93ipty_Z5NgtqT_1BRUNqBsYQNRFz_GjOQ6w@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>
Date: Mon, 16 Jun 2014 22:46:47 +0200
X-Google-Sender-Auth: Y_BWuKjUwAwiTMfuwYp3Ru-nQfE
Message-ID: <CANEZrP3P-EzS22QCSLuY8u42pZG7yTPNjoa4prQaSZzEjbxESg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Daniel Rice <drice@greenmangosystems.com>
Content-Type: multipart/alternative; boundary=001a1133446031e17704fbfa20cb
X-Spam-Score: -0.5 (/)
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
	(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: 1Wwdno-0007FS-Ra
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:46:54 -0000

--001a1133446031e17704fbfa20cb
Content-Type: text/plain; charset=UTF-8

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

--001a1133446031e17704fbfa20cb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Jun 16, 2014 at 10:37 PM, Daniel Rice <span dir=3D"ltr">&lt;<a href=3D"=
mailto:drice@greenmangosystems.com" target=3D"_blank">drice@greenmangosyste=
ms.com</a>&gt;</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>It&#39;s no different to the CA problem. P=
eople can only mentally handle a few trust anchors, so for SSL it goes:</di=
v><div><br></div><div>=C2=A0 =C2=A01 User -&gt; 2-3 browser makers -&gt; 10=
0&#39;s of CAs -&gt; 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&#39;d go=
</div><div><br></div><div>=C2=A0 =C2=A01 merchant -&gt; 4-5 payment process=
ing engines -&gt; dozens of hardware manufacturers -&gt; hundreds of thousa=
nds of devices</div>
<div><br></div><div><br></div></div></div></div>

--001a1133446031e17704fbfa20cb--