Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3C41BBC2 for ; 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 ; Thu, 16 Jul 2015 00:08:06 +0000 (UTC) Received: by ieik3 with SMTP id k3so45524630iei.3 for ; 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> <20150715155903.GC20029@savin.petertodd.org> <55A68668.6@bitcoins.info> <20150715193259.GC3064@muck> Date: Wed, 15 Jul 2015 17:08:05 -0700 Message-ID: From: Matthieu Riou 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
On W= ed, 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."<= br>

Our "identities" aren't p= seudonymous.

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 outgoing connections using up network resources.=C2=A0 Meanwhile, the defau= lt
is 8 outgoing connections - you're using about two orders of magnitude<= br> 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 bi= g
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<= br> 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 dist= inct nodes. Just a few well-tuned ones.
=C2=A0
What you are doing is inherently incompatible with decentralization.=

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. Either way, no one should = play the decentralization police or act as a gatekeeper.

=
Question: Do you have relationships with mining pool= s? 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,
M= atthieu
CTO and Founder, BlockCypher

--001a1135e91a9c0f3a051af2ddde--