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
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alexy.kot.all@gmail.com>) id 1WwbFn-00034i-Fj
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 18:03:35 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.178 as permitted sender)
client-ip=209.85.220.178; envelope-from=alexy.kot.all@gmail.com;
helo=mail-vc0-f178.google.com;
Received: from mail-vc0-f178.google.com ([209.85.220.178])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WwbFl-0002ca-KF
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 18:03:35 +0000
Received: by mail-vc0-f178.google.com with SMTP id ij19so5259640vcb.23
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jun 2014 11:03:28 -0700 (PDT)
X-Received: by 10.52.252.4 with SMTP id zo4mr14768980vdc.20.1402941807967;
Mon, 16 Jun 2014 11:03:27 -0700 (PDT)
MIME-Version: 1.0
Sender: alexy.kot.all@gmail.com
Received: by 10.58.225.35 with HTTP; Mon, 16 Jun 2014 11:02:47 -0700 (PDT)
In-Reply-To: <loom.20140616T190550-931@post.gmane.org>
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>
From: Alex Kotenko <alexykot@gmail.com>
Date: Mon, 16 Jun 2014 19:02:47 +0100
X-Google-Sender-Auth: 8Ihc55DP6fgN63Yx9NooqkLDDyo
Message-ID: <CALDj+Bbvvs4rkrSOndk4rbt9JGwSwF1VeFk2XPjFy7Ro4O9heg@mail.gmail.com>
To: Lawrence Nahum <lawrence@greenaddress.it>
Content-Type: multipart/alternative; boundary=001a1133f7701ac4e204fbf7d892
X-Spam-Score: -0.3 (/)
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
(alexy.kot.all[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.3 HTML_FONT_FACE_BAD BODY: HTML font face is not a word
-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: 1WwbFl-0002ca-KF
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 18:03:35 -0000
--001a1133f7701ac4e204fbf7d892
Content-Type: text/plain; charset=UTF-8
Hi Lawrence/All
I'm afraid with this BIP for TTP of instant transactions we will end up in
VISA world again. As I see it - it's not about if the TTPs will centralize,
it's only when. Simply because if economy of scales makes growth profitable
and coming into this market is at least a little expensive - this
(centralization, VISA world) will happen, sooner rather than later.
And while some may argue that coming to market in Bitcoin world is cheap so
the crowd will always have a chance to come in and beat the monopolists -
think of one thing. Right now Bitcoin is not seen as money and not
regulated accordingly anywhere in the world, thanks God, but how many years
away we are from the point when it will start to be regulated that way? And
once it is - the monopolies will make sure that rules are restrictive
enough to prevent competition, especially in conjunction with economy of
scales playing against the small newcomers.
The "instant providers list" is susceptible to regulatory influence, and
once in place and widespread - it will be a timebomb under Bitcoin. We need
to solve the doublespend issue without TTP involvement, or at least without
even a slight chance of making this involvement regulateable. Otherwise I
think the Bitcoin experiment will fail.
Best regards,
Alex Kotenko
2014-06-16 18:16 GMT+01:00 Lawrence Nahum <lawrence@greenaddress.it>:
> Mike Hearn <mike <at> plan99.net> writes:
>
> > As long as miners stick to Satoshi's first seen rule, which is the
> default, it's useful:
> >
> >
> > https://bitcointalk.org/index.php?topic=423.msg3819#msg3819
> >
> >
> >
> >
> > (this is the famous "snack machine" thread from 2010)
> >
> > If they decide to change to something like highest-fee-always-wins, then
> they (again) centralise things by forcing all instant transactions to pay
> GreenAddress and its competitors money - much though I like your product
> Lawrence, let's hope they don't collectively lemming us all off a cliff by
> doing that ;)
>
>
> I assume we can't enforce to miners rules about which tx will go in and
> which won't and therefore whether this will cause more or less double
> spends.
>
>
> I mean, you can try but I would rather have to option to pick an third
> party
> instant provider explicitly than enforce bigger rules on mining which
> would
> IMHO lead to implicit centralization.
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
--001a1133f7701ac4e204fbf7d892
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:'cou=
rier new',monospace;color:rgb(0,51,0)">Hi Lawrence/All</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">
<div class=3D"gmail_default" style=3D"font-family:'courier new',mon=
ospace;color:rgb(0,51,0)">I'm afraid with this BIP for TTP of instant t=
ransactions we will end up in VISA world again. As I see it - it's not =
about if the TTPs will centralize, it's only when. Simply because if ec=
onomy of scales makes growth profitable and coming into this market is at l=
east a little expensive - this (centralization, VISA world) will happen, so=
oner rather than later.=C2=A0</div>
<div class=3D"gmail_default" style=3D"font-family:'courier new',mon=
ospace;color:rgb(0,51,0)">And while some may argue that coming to market in=
Bitcoin world is cheap so the crowd will always have a chance to come in a=
nd beat the monopolists - think of one thing. Right now Bitcoin is not seen=
as money and not regulated accordingly anywhere in the world, thanks God, =
but how many years away we are from the point when it will start to be regu=
lated that way? And once it is - the monopolies will make sure that rules a=
re restrictive enough to prevent competition, especially in conjunction wit=
h economy of scales playing against the small newcomers.=C2=A0</div>
<div class=3D"gmail_default" style=3D"font-family:'courier new',mon=
ospace;color:rgb(0,51,0)">The "instant providers list" is suscept=
ible to regulatory influence, and once in place and widespread - it will be=
a timebomb under Bitcoin. We need to solve the doublespend issue without T=
TP involvement, or at least without even a slight chance of making this inv=
olvement regulateable. Otherwise I think the Bitcoin experiment will fail.<=
/div>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br><=
/div><div class=3D"gmail_extra"><div><div dir=3D"ltr"><span style=3D"color:=
rgb(0,51,0);font-family:'courier new',monospace">Best regards,=C2=
=A0</span><div>
<div><div style=3D"text-align:left"><font color=3D"#003300" face=3D"'co=
urier new', monospace" style=3D"text-align:-webkit-auto">Alex Kotenko</=
font></div></div></div></div></div>
<br><br><div class=3D"gmail_quote">2014-06-16 18:16 GMT+01:00 Lawrence Nahu=
m <span dir=3D"ltr"><<a href=3D"mailto:lawrence@greenaddress.it" target=
=3D"_blank">lawrence@greenaddress.it</a>></span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=3D"">Mike Hearn <mike <at> <a href=3D"http://plan99.net=
" target=3D"_blank">plan99.net</a>> writes:<br>
<br>
</div><div class=3D"">> As long as miners stick to Satoshi's first s=
een rule, which is the<br>
default, it's useful:<br>
><br>
><br>
> <a href=3D"https://bitcointalk.org/index.php?topic=3D423.msg3819#msg38=
19" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D423.msg3819=
#msg3819</a><br>
><br>
><br>
><br>
><br>
> (this is the famous "snack machine" thread from 2010)<br>
><br>
> If they decide to change to something like highest-fee-always-wins, th=
en<br>
they (again) centralise things by forcing all instant transactions to pay<b=
r>
GreenAddress and its competitors money - much though I like your product<br=
>
Lawrence, let's hope they don't collectively lemming us all off a c=
liff by<br>
doing that ;)<br>
<br>
<br>
</div>I assume we can't enforce to miners rules about which tx will go =
in and<br>
which won't and therefore whether this will cause more or less double<b=
r>
spends.<br>
<br>
<br>
I mean, you can try but I would rather have to option to pick an third part=
y<br>
instant provider explicitly than =C2=A0enforce bigger rules on mining which=
would<br>
IMHO lead to implicit centralization.<br>
<div class=3D""><div class=3D"h5"><br>
<br>
<br>
<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 & 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></div>
--001a1133f7701ac4e204fbf7d892--
|
