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
|
Return-Path: <matthieu@blockcypher.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3C41BBC2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jul 2015 00:08:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com
[209.85.223.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 863D0169
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Jul 2015 00:08:06 +0000 (UTC)
Received: by ieik3 with SMTP id k3so45524630iei.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 15 Jul 2015 17:08:06 -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:content-type;
bh=ZXcF3hpa7xCDP4TOy05w5DLeKm7Os9Up1NZdSS/Yqno=;
b=LkI3hSS6o4h/Yf2mnPWmGcga+LEfdggJhIWsX9yFI7gkmqmMTrsae9QXhDXeGxhHUw
ERdoLfK+xjuIr0mdO6eec0tLC+vr8t8p3U2kDir3ho2uNoy31rQyk5JECWnYbVPFYI7r
viMcrD+LXL0Iu2KIfJ2o18o+WB90t7wHZNA5oC0MrjqejGSeK2VoPL+zY+O7vEqPT3b1
Qq7D4CsRslBtMwIs55xT/c5MfeecowsuWG2KoPtYQm0usVeU051DbcUme6IXVUKOV1cC
WeML2xof9DBL191Ab/PdoszVSetFOQcSqPWxR1b1xApE7ri5LtgEKlNa6+5katsbW7+k
+2Lw==
X-Gm-Message-State: ALoCoQlb6wPw3Tx/w4ZwEgEunXUb6sMfGbL+TPJxDGI1l7FuFiKyEQQ42yjyOQNLGTkBIBe7A8rA
MIME-Version: 1.0
X-Received: by 10.50.143.43 with SMTP id sb11mr797345igb.69.1437005285940;
Wed, 15 Jul 2015 17:08:05 -0700 (PDT)
Received: by 10.107.176.208 with HTTP; Wed, 15 Jul 2015 17:08:05 -0700 (PDT)
In-Reply-To: <20150715193259.GC3064@muck>
References: <24662b038abc45da7f3990e12a649b8a@airmail.cc>
<55A66FA9.4010506@thinlink.com>
<20150715151825.GB20029@savin.petertodd.org>
<CDB5FC27-F3F0-44F7-BBC6-670ACAE740D2@gmail.com>
<20150715155903.GC20029@savin.petertodd.org>
<55A68668.6@bitcoins.info>
<CAHUNwMp3-jNc9g0shCUCR76WEA5Qp+JpxZGPmAuK5wuy4p1yEw@mail.gmail.com>
<20150715193259.GC3064@muck>
Date: Wed, 15 Jul 2015 17:08:05 -0700
Message-ID: <CAHUNwMowbrua=iY518SL4MBY1sszfQwoM3epCaZ-jVrb2qxghg@mail.gmail.com>
From: Matthieu Riou <matthieu@blockcypher.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1135e91a9c0f3a051af2ddde
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Significant losses by double-spending unconfirmed
transactions
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jul 2015 00:08:07 -0000
--001a1135e91a9c0f3a051af2ddde
Content-Type: text/plain; charset=UTF-8
On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd <pete@petertodd.org> wrote:
>
> "In a Sybil attack the attacker subverts the reputation system of a
> peer-to-peer network by creating a large number of pseudonymous
> identities, using them to gain a disproportionately large influence."
>
Our "identities" aren't pseudonymous.
In the case of Bitcoin, there's something like 6,000 nodes, so if that
> 20% is achived via outgoing connections you'd have 600 to 1200 active
> outgoing connections using up network resources. Meanwhile, the default
> is 8 outgoing connections - you're using about two orders of magnitude
> more resources.
>
You're not talking about a Sybil attack anymore, just resource use. We do
know how to change default configurations to offer more connections.
If you are achieving that via incoming connections, you're placing a big
> part of the relay network under central control. As we've seen in the
> case of Chainalysis's sybil attack, even unintentional confirguation
> screwups can cause serious and widespread issues due to the large number
> of nodes that can fail in one go. (note how Chainalysis's actions were
> described(1) as a sybil attack by multiple Bitcoin devs, including
> Gregory Maxwell, Wladimir van der Laan, and myself)
>
We're not Chainanalysis and we do not run hundreds of distinct nodes. Just
a few well-tuned ones.
> What you are doing is inherently incompatible with decentralization.
>
That's a matter of opinion. One could argue your actions and control
attempts hurt decentralization. Either way, no one should play the
decentralization police or act as a gatekeeper.
Question: Do you have relationships with mining pools? For instance, are
> you looking at contracts to have transactions mined to guarantee
> confirmations?
>
No, we do not. We do not know anyone else having such contracts. As you
know, Coinbase also denied having such contracts in place [1]. But you seem
to have more relationships with mining pools than we do.
Thanks,
Matthieu
CTO and Founder, BlockCypher
[1]
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008864.html
--001a1135e91a9c0f3a051af2ddde
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 W=
ed, Jul 15, 2015 at 12:32 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"m=
ailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><span><br>
</span>"In a Sybil attack the attacker subverts the reputation system =
of a<br>
peer-to-peer network by creating a large number of pseudonymous<br>
identities, using them to gain a disproportionately large influence."<=
br></blockquote><div><br></div><div>Our "identities" aren't p=
seudonymous.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex">
In the case of Bitcoin, there's something like 6,000 nodes, so if that<=
br>
20% is achived via outgoing connections you'd have 600 to 1200 active<b=
r>
outgoing connections using up network resources.=C2=A0 Meanwhile, the defau=
lt<br>
is 8 outgoing connections - you're using about two orders of magnitude<=
br>
more resources.<br></blockquote><div><br></div><div><span style=3D"font-siz=
e:12.8000001907349px">You're not talking about a Sybil attack anymore, =
just resource use. We do know how to change default configurations to offer=
more connections.</span><br></div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If you are achieving that via incoming connections, you're placing a bi=
g<br>
part of the relay network under central control. As we've seen in the<b=
r>
case of Chainalysis's sybil attack, even unintentional confirguation<br=
>
screwups can cause serious and widespread issues due to the large number<br=
>
of nodes that can fail in one go. (note how Chainalysis's actions were<=
br>
described(1) as a sybil attack by multiple Bitcoin devs, including<br>
Gregory Maxwell, Wladimir van der Laan, and myself)<br></blockquote><div><b=
r></div><div>We're not Chainanalysis and we do not run hundreds of dist=
inct nodes. Just a few well-tuned ones.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex"><span>
</span>What you are doing is inherently incompatible with decentralization.=
<br></blockquote><div><br></div><div>That's a matter of opinion.=C2=A0<=
span style=3D"font-size:12.8000001907349px">One could argue your actions an=
d control attempts hurt decentralization</span>. Either way, no one should =
play the decentralization police or act as a gatekeeper.<br></div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex">Question: Do you have relationships with mining pool=
s? For instance, are<br>
you looking at contracts to have transactions mined to guarantee<br>
confirmations?<br></blockquote><div><br></div><div>No, we do not. We do not=
know anyone else having such contracts. As you know, Coinbase also denied =
having such contracts in place [1]. But you seem to have more relationships=
with mining pools than we do.</div><div><br></div><div>Thanks,</div><div>M=
atthieu</div><div>CTO and Founder, BlockCypher</div><div><br></div><div>[1]=
=C2=A0<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
5-June/008864.html" target=3D"_blank">http://lists.linuxfoundation.org/pipe=
rmail/bitcoin-dev/2015-June/008864.html</a></div></div></div></div>
--001a1135e91a9c0f3a051af2ddde--
|
