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
|
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 <drice@greenmangosystems.com>) id 1WwdfE-0000XO-V1
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 20:38:00 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of
greenmangosystems.com designates 209.85.220.178 as permitted
sender) client-ip=209.85.220.178;
envelope-from=drice@greenmangosystems.com;
helo=mail-vc0-f178.google.com;
Received: from mail-vc0-f178.google.com ([209.85.220.178])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WwdfD-0002Po-54
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 20:38:00 +0000
Received: by mail-vc0-f178.google.com with SMTP id ij19so5607643vcb.9
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jun 2014 13:37:53 -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=1leq6+cRn1kVbVQI+EqoBosMa0ee39OKKYf+hAwbkAk=;
b=Lr1wPkrNr7hZPdwBaKQMRm6YPlorVUVyqA63+EP5hlzyeaDLoOMoBADeq3d3PQIe0X
/Ujnj8F6+C3UgOK9RNuxcdc1H1wBcYfphZkbZSu6NU93iBix2bXH3KqCQJFXWXZHaNx4
ev9mFtypZtm4Gf/2SUJyxvaYrRcVhRFc0+nDVQyKypq9BkYE6nQ5pTbDBDnuWUQAf+u1
XhgQoGI7P0phwRY+WB8cD39LWn2HXyw5dEqKRU+Gje7V7l2mEnKWUYxVwV2ePz6tjJGt
gpocut88NCw609AhqayavVQGU37LoGhfUfnsgBzNwu9534RKamnNQAidvYE1+dOf0/jA
4NHw==
X-Gm-Message-State: ALoCoQlFlHRxYciG6iPe2w7620By8mkgnFOVjitTSf/9X9YO4nfxw7lQ6ryo5Q+3R68L9quEjrPF
MIME-Version: 1.0
X-Received: by 10.58.236.170 with SMTP id uv10mr3317853vec.31.1402951072968;
Mon, 16 Jun 2014 13:37:52 -0700 (PDT)
Received: by 10.58.123.35 with HTTP; Mon, 16 Jun 2014 13:37:52 -0700 (PDT)
In-Reply-To: <CANEZrP2NKG8etGtGgbkA8rPr3BqCMPmVQ-3xqiKXVOK2vf9+7w@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>
Date: Mon, 16 Jun 2014 13:37:52 -0700
Message-ID: <CAFDyEXistfW2Y-93ipty_Z5NgtqT_1BRUNqBsYQNRFz_GjOQ6w@mail.gmail.com>
From: Daniel Rice <drice@greenmangosystems.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=047d7bdc1a9c577c6804fbfa005c
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: 1WwdfD-0002Po-54
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:38:01 -0000
--047d7bdc1a9c577c6804fbfa005c
Content-Type: text/plain; charset=UTF-8
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 seems to encourage monopoly unless
there is a standard way to bootstrap trust in your signature.
On Mon, Jun 16, 2014 at 1:32 PM, Mike Hearn <mike@plan99.net> wrote:
> On Mon, Jun 16, 2014 at 10:29 PM, Daniel Rice <drice@greenmangosystems.com
> > wrote:
>
>> I'm trying to think through how to encourage the maximum number of
>> instant signature providers and avoid the VISA monopoly. Ideal case would
>> be that people can even be their own instant provider.
>>
>
> A provider does not have to be an interactive third party. One reason I
> suggested using X.509 is so secure hardware devices like the TREZOR could
> also be instant providers. The hardware would be tamperproof and assert
> using a secret key embedded in it that the tx came from a genuine,
> unflashed TREZOR. The the server can know the device won't double spend.
>
> In this way you have decentralised anti-double spending. Of course, it's
> an old solution. MintChip sort of worked a bit like this.
>
--047d7bdc1a9c577c6804fbfa005c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">True, that would work, but still how are you going to boot=
strap 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 s=
eems like one company could corner the market by being the only one that is=
an accepted instant provider at most vendors. It seems to encourage monopo=
ly unless there is a standard way to bootstrap trust in your signature.</di=
v>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Jun 1=
6, 2014 at 1:32 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:29 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"><div>I'm trying to thin=
k through how to encourage the maximum number of instant signature provider=
s and avoid the VISA monopoly. Ideal case would be that people can even be =
their own instant provider.</div>
</div></blockquote><div><br></div></div><div>A provider does not have to be=
an interactive third party. One reason I suggested using X.509 is so secur=
e hardware devices like the TREZOR could also be instant providers. The har=
dware would be tamperproof and assert using a secret key embedded in it tha=
t the tx came from a genuine, unflashed TREZOR. The the server can know the=
device won't double spend.</div>
<div><br></div><div>In this way you have decentralised anti-double spending=
. Of course, it's an old solution. MintChip sort of worked a bit like t=
his.</div></div></div></div>
</blockquote></div><br></div>
--047d7bdc1a9c577c6804fbfa005c--
|
