summaryrefslogtreecommitdiff
path: root/05/5d3e9133ad874a7bc7ebbefda8126a687da523
blob: 60d09e797db1f507154c0b6968ed903a47f01f58 (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
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C01DF279
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 11:59:29 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149112.authsmtp.co.uk (outmail149112.authsmtp.co.uk
	[62.13.149.112])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3A6F91D5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 11:59:27 +0000 (UTC)
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6HBxOhv054203;
	Fri, 17 Jul 2015 12:59:24 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
	[75.119.251.161]) (authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6HBxL3F041696
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Fri, 17 Jul 2015 12:59:23 +0100 (BST)
Date: Fri, 17 Jul 2015 07:59:20 -0400
From: Peter Todd <pete@petertodd.org>
To: Matthieu Riou <matthieu@blockcypher.com>
Message-ID: <20150717115920.GA19616@savin.petertodd.org>
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>
	<CAHUNwMowbrua=iY518SL4MBY1sszfQwoM3epCaZ-jVrb2qxghg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS"
Content-Disposition: inline
In-Reply-To: <CAHUNwMowbrua=iY518SL4MBY1sszfQwoM3epCaZ-jVrb2qxghg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 442b9cbb-2c7b-11e5-9f75-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdwUUEkAYAgsB AmMbWlZeVVR7W2c7 bA9PbARUfEhLXhtr
	VklWR1pVCwQmRRp5 dFZiUW9ycwRAcXg+ ZEFkW3IVWEB4J08u
	EBxJFz4BN3phaTUa TUkOcAZJcANIexZF O1F8UScOLwdSbGoL
	FQ4vNDcwO3BTJTpg CjoMIlQTT0cAFzgg DxQFBi4iBgUPVm0/
	KAEsLlNZB14cNEkz N1RpRFQTNBkcCxdb Ek0vSDNDLl8aTiE3 DARcRiYA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_05,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
Cc: bitcoin-dev@lists.linuxfoundation.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: Fri, 17 Jul 2015 11:59:29 -0000


--qMm9M+Fa2AknHoGS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 15, 2015 at 05:08:05PM -0700, Matthieu Riou via bitcoin-dev wro=
te:
> On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd <pete@petertodd.org> wrote:
>=20
> >
> > "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."
> >
>=20
> Our "identities" aren't pseudonymous.

Then are you willing to tell us what IP addresses your nodes connect
=66rom? This is important network stability information due to how nodes
prevent a lack of diversity in their outgoing connections.

> 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.
> >
>=20
> You're not talking about a Sybil attack anymore, just resource use. We do
> know how to change default configurations to offer more connections.

The Bitcoin P2P network's primary concern is reliability through
diversity; you are harming that resource.

So to be clear, you have both a high level of outgoing and incoming
connections? Given that Bitcoin nodes only connect to eight outgoing
peers, how do you manage to connect to your claimed 10%-20% of all
reachable nodes? Obviously you can't be doing that with just incoming
connections, unless you're running hundreds of nodes, or doing an addr
spamming attack.

> 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)
> >
>=20
> We're not Chainanalysis and we do not run hundreds of distinct nodes. Just
> a few well-tuned ones.

It's actually marginally better for the network if you're using hundreds
of distinct nodes rather than just a few to do this sybil attack - the
chance of your small number of nodes suddenly going off-line and causing
propagation issues is more than hundreds of nodes all going off-line
suddenly. Additionally it's easier for bad actors to survail your few
internet connections to easily get tx propagation information from the
network than it is to survail Chainalysis's setup. (ironic I know)

> > What you are doing is inherently incompatible with decentralization.
> >
>=20
> 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.

"Control attempts"? Care to explain?

Re: "gatekeeping" - fact is your business model and technology can only
be succesfully run by a small number of entities at once, resulting in a
situation where those few companies act as gatekeepers for access to
zeroconf confirmation probability information.

> Question: Do you have relationships with mining pools? For instance, are
> > you looking at contracts to have transactions mined to guarantee
> > confirmations?
> >
>=20
> 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 se=
em
> to have more relationships with mining pools than we do.

Nice cheap shot there. My "relationships" are nothing more than people
being willing to talk to me, ask me for advice, and warn me about
possible threats. They're not legal contracts.

--=20
'peter'[:-1]@petertodd.org
0000000000000000138147be90db48b8338de6d58cc6b60e6ad360f6ef486d8c

--qMm9M+Fa2AknHoGS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVqO4UXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwYjMyNzY3YjU2OWUzNzQyMzM0YTk0NTQwMjEzYjk4MDkx
MTUwYzgyZWVmMDM3ZDIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuESgf7BCD6rtmcDlShgOQTDVAAQr+1
+0iYXFR/864Y3BgztHSnsXYleSYRWdZtA4yDjNfqDr+OM9EbmBkf+7S3epKFc7N+
YrW33cvfzlR/wbiKDLu2BmP/b/dcEJKBv9zns5sbdF/CwuqraEBlf8oFReedYt33
YYnf9yVYMJQcwxFPcCQcogXk1po/igEnOm6XD7RhvYF0d013mG06xPtroLNj4xuG
Ax0qR0uJh6i3aohtBToFFAMDcNM2Dwqvk3guTRrO/XMnMPp2KlKCTu36y7bHhJFj
ZTp6e41eqDoV89+j1MtKsmpdRdJ9x3qZdAlp06wO6Iyi34t0V/jABvTEQ1KffA==
=dWL9
-----END PGP SIGNATURE-----

--qMm9M+Fa2AknHoGS--