summaryrefslogtreecommitdiff
path: root/95/9d3adbf9f13aaaeba27fa75210c5197f5eb2a1
blob: 8982f4438155fe60b57e625156d4ab420af37084 (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
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
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 1WwZL4-0005wD-4r
	for bitcoin-development@lists.sourceforge.net;
	Mon, 16 Jun 2014 16:00:54 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of
	greenmangosystems.com designates 209.85.220.182 as permitted
	sender) client-ip=209.85.220.182;
	envelope-from=drice@greenmangosystems.com;
	helo=mail-vc0-f182.google.com; 
Received: from mail-vc0-f182.google.com ([209.85.220.182])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WwZL2-0002JS-97
	for bitcoin-development@lists.sourceforge.net;
	Mon, 16 Jun 2014 16:00:54 +0000
Received: by mail-vc0-f182.google.com with SMTP id il7so5160121vcb.13
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 16 Jun 2014 09:00:46 -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=XCYy2bCAAuUjyURn3R93xkBiVctM9EUAH9GY0VQbZsI=;
	b=CPNSfGZG4aDwBRmJOWstDOj8GkwdAA4ZICDl+rOsD76zaQxhMbsKfbKi/wZO4GvLiX
	4apLrgIm1WhIVyhwN8vz3tKUzhWrWAAOqy631DeHvOuafvJxNEQeLEifUV16dY373bJm
	Ws+Kd7GA4NlrLK2ud1g/beK/V3joXZTOrMw7YKrIbT1sZnDZSJtmDjjRW2q5k5hDPNiy
	ul4qLk63WynMF8jEurtxpGA2pdkqYFSuTE2KksuzCzpoKL5UQ6RwmP4uWVnAR5CqmcHw
	Ws2mYgGKkIBNhjxOjv8Lz2OZ5hmArcZz8E78zVvm02meJUe3q1EoH74zftM/p9h8Y/Vd
	3gpA==
X-Gm-Message-State: ALoCoQkX8ni4QvNOOhxVW0HxjAo3PVDccX9SkmvkJltJR1Nbct3Dm3eZrsbtVj76pSgyS8T0HwGy
MIME-Version: 1.0
X-Received: by 10.52.184.164 with SMTP id ev4mr14083092vdc.15.1402934445861;
	Mon, 16 Jun 2014 09:00:45 -0700 (PDT)
Received: by 10.58.123.35 with HTTP; Mon, 16 Jun 2014 09:00:45 -0700 (PDT)
In-Reply-To: <loom.20140616T172412-752@post.gmane.org>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
	<CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com>
	<CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com>
	<loom.20140616T172412-752@post.gmane.org>
Date: Mon, 16 Jun 2014 09:00:45 -0700
Message-ID: <CAFDyEXgiZH-_zSftbKQRrPu385OwKEnYZo6-6NtWONX+V85awA@mail.gmail.com>
From: Daniel Rice <drice@greenmangosystems.com>
To: Lawrence Nahum <lawrence@greenaddress.it>
Content-Type: multipart/alternative; boundary=bcaec54865d84a05ed04fbf621eb
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: 1WwZL2-0002JS-97
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 16:00:54 -0000

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

> Any reason you think people will spread trust instead of consolidating of
a
bunch of instant transaction providers when time is critical?

Maybe you're right, but if you are, that's a huge reason not to implement
this. We should encourage proliferation of instant providers otherwise we
start becoming VISA all over again. That's a future for Bitcoin I'm not
excited about: "Use one of these 4 companies, or you need to wait an
impractical amount of time before your transaction will go through."

Come to think of it, is the payment protocol really the place to put this
instant provider signature or should it be in the actual Bitcoin
transaction? If we don't believe there is a valid practical solution to
doublespends (some people have already emailed me critical feedback on my
proposal) then we absolutely need a trust network, but we would also want
it to be part of the public ledger for everyone to see.


On Mon, Jun 16, 2014 at 8:26 AM, Lawrence Nahum <lawrence@greenaddress.it>
wrote:

> Daniel Rice <drice <at> greenmangosystems.com> writes:
>
> >  If double spends are not resolved, there will be a million instant
> providers in the long run and if double spends are resolved then this BIP
> extension is completely unnecessary.
>
> I am not sure if double spends can be resolved, at the moment they are not
> and I highly doubt you will see millions instant providers just like I
> don't
> see millions Certificate Authorities and I don't see Million Credit Card
> networks.
>
> Any reason you think people will spread trust instead of consolidating of a
> bunch of instant transaction providers when time is critical?
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-family:arial,sans-serif;font=
-size:13px">Any reason you think people will spread trust instead of consol=
idating of a</span><br style=3D"font-family:arial,sans-serif;font-size:13px=
"><span style=3D"font-family:arial,sans-serif;font-size:13px">bunch of inst=
ant transaction providers when time is critical?</span><div>
<span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></di=
v><div><span style=3D"font-family:arial,sans-serif;font-size:13px">Maybe yo=
u&#39;re right, but if you are, that&#39;s a huge reason not to implement t=
his. We should encourage proliferation of instant providers otherwise we st=
art becoming VISA all over again. That&#39;s a future for Bitcoin I&#39;m n=
ot excited about: &quot;Use one of these 4 companies, or you need to wait a=
n impractical amount of time before your transaction will go through.&quot;=
</span><br>
</div><div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>=
</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x">Come to think of it, is the payment protocol really the place to put thi=
s instant provider signature or should it be in the actual Bitcoin transact=
ion? If we don&#39;t believe there is a valid practical solution to doubles=
pends (some people have already emailed me critical feedback on my proposal=
) then we absolutely need a trust network, but we would also want it to be =
part of the public ledger for everyone to see.</span></div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon,=
 Jun 16, 2014 at 8:26 AM, Lawrence Nahum <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:lawrence@greenaddress.it" target=3D"_blank">lawrence@greenaddress.it<=
/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 class=3D"">Daniel Rice &lt;drice &lt;at=
&gt; <a href=3D"http://greenmangosystems.com" target=3D"_blank">greenmangos=
ystems.com</a>&gt; writes:<br>

<br>
&gt; =C2=A0If double spends are not resolved, there will be a million insta=
nt<br>
providers in the long run and if double spends are resolved then this BIP<b=
r>
extension is completely unnecessary.<br>
<br>
</div>I am not sure if double spends can be resolved, at the moment they ar=
e not<br>
and I highly doubt you will see millions instant providers just like I don&=
#39;t<br>
see millions Certificate Authorities and I don&#39;t see Million Credit Car=
d<br>
networks.<br>
<br>
Any reason you think people will spread trust instead of consolidating of a=
<br>
bunch of instant transaction providers when time is critical?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<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 &amp; 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>
_______________________________________________<br>
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>
</div></div></blockquote></div><br></div>

--bcaec54865d84a05ed04fbf621eb--