Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C01DF279 for ; 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 ; 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 To: Matthieu Riou Message-ID: <20150717115920.GA19616@savin.petertodd.org> References: <24662b038abc45da7f3990e12a649b8a@airmail.cc> <55A66FA9.4010506@thinlink.com> <20150715151825.GB20029@savin.petertodd.org> <20150715155903.GC20029@savin.petertodd.org> <55A68668.6@bitcoins.info> <20150715193259.GC3064@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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--