Return-Path: <ctpacia@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 71CF2FF for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 17 Aug 2015 21:44:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DC47817F for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 17 Aug 2015 21:44:56 +0000 (UTC) Received: by iodt126 with SMTP id t126so168246085iod.2 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 17 Aug 2015 14:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hezaFLE8BTDE0rc8KVpbSHb2UbuFpXl6Gi3jo/D4dyU=; b=QwTf/cgaHalrK/T5P9j7yIyvnitv4px34oca42S8LpZ55ULSgzQir8hOyGutZFT2ew Ht31OJwzCvCFHxDikECGs0RMdwmE6gLg7GwLmIiqgYIKj7R3AFT9R8XRhqdTxiHVp4s5 CBAf0FVJRG2gGCEMqClbj5MwjzFwjZi0fNBZsu9BRzKKWSlWs0RarvNqOwtjoRO2dDSl tbJkwOKfr4qvPoQO69oziIsi48z/wqh+1aii2A2+Kpw+LVpki6Z6nlusfYEnFMHZUjvC 2ezQqfmq3L7IcU0bVePUCCqciCei5ph1bHBx0zcCUSaFXMimzeVvLrpBsz1wjnbNsQ+C rYfQ== MIME-Version: 1.0 X-Received: by 10.107.137.208 with SMTP id t77mr3441505ioi.2.1439847896410; Mon, 17 Aug 2015 14:44:56 -0700 (PDT) Received: by 10.36.144.196 with HTTP; Mon, 17 Aug 2015 14:44:56 -0700 (PDT) Received: by 10.36.144.196 with HTTP; Mon, 17 Aug 2015 14:44:56 -0700 (PDT) In-Reply-To: <20150817212912.GA15817@muck> References: <6EC9DDF352DC4838AE9B088AB372428A25E1F42A@DS04> <20150817212912.GA15817@muck> Date: Mon, 17 Aug 2015 17:44:56 -0400 Message-ID: <CAB+qUq79BgiTGFS1yLxxogg8907jCUtNDmBhnikLWc1fqofNyg@mail.gmail.com> From: Chris Pacia <ctpacia@gmail.com> To: Peter Todd <pete@petertodd.org> Content-Type: multipart/alternative; boundary=001a113ed538657335051d88b699 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Incentives to run full nodes 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: Mon, 17 Aug 2015 21:44:57 -0000 --001a113ed538657335051d88b699 Content-Type: text/plain; charset=UTF-8 On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: From the point of view of a > wallet, it's not very secure to use Hearn-style SPV mode, and volunteers > running full nodes doesn't help things. Sybil attacking the IP address > space is pretty easy in comparison to aquiring hashing power sufficient > to create false confirmations, so any attacker able to do the former > will likely be running the full node you're connecting too anyway. > Ultimately, Hearn-style SPV is a close approximation to just trusting > anyone with a non-trivial amount of hashing power. (and getting that is > surprisingly easy, e.g. w/ SPV mining) Can you explain how the spv node fails against an attacker with a non-trivial amount of hash power where a full node doesn't? To attack an spv wallet that is waiting for 6 or 10 confirmations, you would not only need to Sybil them but also summon a massive amount of hashing power to create a chain of headers (while forgoing the opportunity to mine valid blocks with that hash power). But could someone with that much hash power not Sybil a full node and give them a chain for valid blocks (but on an orphan fork)? The failure model doesn't seem specific to spv to me. --001a113ed538657335051d88b699 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr"><br> On Aug 17, 2015 5:29 PM, "Peter Todd via bitcoin-dev" <<a href= =3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo= undation.org</a>> wrote:<br> From the point of view of a<br> > wallet, it's not very secure to use Hearn-style SPV mode, and volu= nteers<br> > running full nodes doesn't help things. Sybil attacking the IP add= ress<br> > space is pretty easy in comparison to aquiring hashing power sufficien= t<br> > to create false confirmations, so any attacker able to do the former<b= r> > will likely be running the full node you're connecting too anyway.= <br> > Ultimately, Hearn-style SPV is a close approximation to just trusting<= br> > anyone with a non-trivial amount of hashing power. (and getting that i= s<br> > surprisingly easy, e.g. w/ SPV mining)</p> <p dir=3D"ltr">Can you explain how the spv node fails against an attacker w= ith a non-trivial amount of hash power where a full node doesn't? To at= tack an spv wallet that is waiting for 6 or 10 confirmations, you would not= only need to Sybil them but also summon a massive amount of hashing power = to create a chain of headers (while forgoing the opportunity to mine valid = blocks with that hash power). </p> <p dir=3D"ltr">But could someone with that much hash power not Sybil a full= node and give them a chain for valid blocks (but on an orphan fork)? The f= ailure model doesn't seem specific to spv to me. </p> --001a113ed538657335051d88b699--