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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <drice@greenmangosystems.com>) id 1WxIHA-0003nd-DU
for bitcoin-development@lists.sourceforge.net;
Wed, 18 Jun 2014 15:59:52 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of
greenmangosystems.com designates 209.85.220.173 as permitted
sender) client-ip=209.85.220.173;
envelope-from=drice@greenmangosystems.com;
helo=mail-vc0-f173.google.com;
Received: from mail-vc0-f173.google.com ([209.85.220.173])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WxIH8-000437-Kj
for bitcoin-development@lists.sourceforge.net;
Wed, 18 Jun 2014 15:59:52 +0000
Received: by mail-vc0-f173.google.com with SMTP id lf12so1005810vcb.32
for <bitcoin-development@lists.sourceforge.net>;
Wed, 18 Jun 2014 08:59:44 -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=hzYnIv2b4WRni6+zmXZwjeFF+h9IjR842s5KcO/R3r8=;
b=iBN4EjBq4tejB02NQwkDhtbjDESx0e/ymRXaJTNjnvZE+RLgsgurXi2DFpvJ2K20ep
aT7gERwPm8dCeleocS8vnK3Xt5jQVW5CE0SniknlKU90WhT0qtRB4qQWl0/NJLeOuU78
QyPDI9TIPszj+e2fBCga8kqiwg1kmk0ALkSTsOL0zYNsryo0+2/oKD9trvwoch8dJfea
NSP4gk8zfZS5QEUFDUbDNGww3udsPEg3USt+uHh3NvTC2OaY4ouHZ1lsGm3BuwopPG+3
d4p7Zd7mmboLe4FHmudfv+vnnJ5peka4WwzjsuFn+AOL/sRbQJHlwJqz+IiBh99moihm
4QFg==
X-Gm-Message-State: ALoCoQkckWvOzOF+hzyqbDTCt7yDh5XXCvLqF/K8WgPPeYJntHQmvmqjN8W/1uqoZrx7caqs/tnt
MIME-Version: 1.0
X-Received: by 10.58.115.229 with SMTP id jr5mr598161veb.74.1403107184282;
Wed, 18 Jun 2014 08:59:44 -0700 (PDT)
Received: by 10.58.123.35 with HTTP; Wed, 18 Jun 2014 08:59:44 -0700 (PDT)
In-Reply-To: <CANEZrP0ekAHNOHha_8ncu_QKVCidBQndw2x0+5rciD92LdOS7A@mail.gmail.com>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
<lnhgsk$va6$1@ger.gmane.org>
<loom.20140615T111027-736@post.gmane.org>
<lnk4ii$ehf$1@ger.gmane.org>
<loom.20140618T140509-802@post.gmane.org>
<CANEZrP0ekAHNOHha_8ncu_QKVCidBQndw2x0+5rciD92LdOS7A@mail.gmail.com>
Date: Wed, 18 Jun 2014 08:59:44 -0700
Message-ID: <CAFDyEXhY-KxM6dN0ngXiiB4ga85tD6e4gW6QVpST5XxJARLicw@mail.gmail.com>
From: Daniel Rice <drice@greenmangosystems.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=047d7b672d324d251e04fc1e59fe
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: 1WxIH8-000437-Kj
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: Wed, 18 Jun 2014 15:59:52 -0000
--047d7b672d324d251e04fc1e59fe
Content-Type: text/plain; charset=UTF-8
> I'm not sure this is actually important or useful; trusting someone not
to double spend is a pretty binary thing
I think that's true if you assume that the instant provider list is based
on a by hand created list of accepted instant providers. That's how VISA
works now and that's why I was asking for an approach where the
trusted_instant_providers list is scalable because that seems very
dangerous.
Since you can detect when a double spend happens, the entire instant
provider list could be automatically generated based on a 3rd party network
that shares information between vendors and also monitors double spends. In
that scenario, there is no hand written exclusive list of accepted instant
providers. There is just a database of past history on all instant
providers. That database can be used to give a confidence score for a
specific instant provider for a given transaction amount. In this scenario,
a new wallet company would be able to earn trust over time. If the list is
made by hand, "Bitpay accepts Circle, Coinbase, and GreenAddress for
instant transactions", then new wallet providers have to go around bribing
Bitpay and the other large merchant transaction providers to get on their
instant provider list.
Allowing more than one instant signature on a transaction is supposed to
help avoid that scenario. For example, lets say I want to establish my own
instant signature. I use a wallet that already has an accepted instant
signature, but it also allows me to add my own instant signature. I do this
so that I can start establishing trust in my own instant signature while
relying on their instant signature.
On Wed, Jun 18, 2014 at 6:25 AM, Mike Hearn <mike@plan99.net> wrote:
> - allowing multiple signatures ?
>
>
> I'm not sure this is actually important or useful; trusting someone not to
> double spend is a pretty binary thing. I'm not sure saying "you need to get
> three independent parties to sign off on this" is worth the hassle,
> especially because the first signature is obvious (your risk analysis
> provider or hardware) but the second and third are ..... who? Special
> purpose services you have to sign up for? Seems like a hassle.
>
> But it's up to you.
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--047d7b672d324d251e04fc1e59fe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0<span style=3D"font-family:arial,sans-serif;font=
-size:13px">I'm not sure this is actually important or useful; trusting=
someone not to double spend is a pretty binary thing</span><div><span styl=
e=3D"font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><font face=3D"arial, sans-serif">I think that's true =
if you assume that the instant provider list is based on a by hand created =
list of accepted instant providers. That's how VISA works now and that&=
#39;s why I was asking for an approach where the trusted_instant_providers =
list is scalable because that seems very dangerous.</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">Since you can detect when a double spend happens, the ent=
ire instant provider list could be automatically generated based on a 3rd p=
arty network that shares information between vendors and also monitors doub=
le spends. In that scenario, there is no hand written exclusive list of acc=
epted instant providers. There is just a database of past history on all in=
stant providers. That database can be used to give a confidence score for a=
specific instant provider for a given transaction amount. In this scenario=
, a new wallet company would be able to earn trust over time. If the list i=
s made by hand, "Bitpay accepts Circle, Coinbase, and GreenAddress for=
instant transactions", then new wallet providers have to go around br=
ibing Bitpay and the other large merchant transaction providers to get on t=
heir instant provider list.</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">Allowing more than one instant signature on a transaction=
is supposed to help avoid that scenario. For example, lets say I want to e=
stablish my own instant signature. I use a wallet that already has an accep=
ted instant signature, but it also allows me to add my own instant signatur=
e. I do this so that I can start establishing trust in my own instant signa=
ture while relying on their instant signature.</font></div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Jun 1=
8, 2014 at 6:25 AM, 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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">- allowing multiple signatures ?</blockquote><di=
v><br>
</div>
<div>I'm not sure this is actually important or useful; trusting someon=
e not to double spend is a pretty binary thing. I'm not sure saying &qu=
ot;you need to get three independent parties to sign off on this" is w=
orth the hassle, especially because the first signature is obvious (your ri=
sk analysis provider or hardware) but the second and third are ..... who? S=
pecial purpose services you have to sign up for? Seems like a hassle.</div>
<div><br></div><div>But it's up to you.</div></div></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions<b=
r>
Find What Matters Most in Your Big Data with HPCC Systems<br>
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.<br>
Leverages Graph Analysis for Fast Processing & Easy Data Exploration<br=
>
<a href=3D"http://p.sf.net/sfu/hpccsystems" target=3D"_blank">http://p.sf.n=
et/sfu/hpccsystems</a><br>_______________________________________________<b=
r>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div>
--047d7b672d324d251e04fc1e59fe--
|
