From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 80439895 for ; Tue, 18 Aug 2015 00:20:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE27D184 for ; Tue, 18 Aug 2015 00:20:06 +0000 (UTC) Received: by pabyb7 with SMTP id yb7so119007153pab.0 for ; Mon, 17 Aug 2015 17:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightning.network; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=3sma/77fTZrtiAs+dHj3kJP7akZW8P7vQMy9tzFONiM=; b=G6QUF5LG22YPzx+hhVY8YBdaUogcFrN/zMveCiXPSj+Le/DRnmuivceH4IG8qhcUOr iJUM5RRNTlh7cHYk4FESPzX8E9BIJy7YX8bkpyTDxxHgEbxjm8xCi76UoPdkAaNkh6lD EstYroOV6i8kruydzHUSIdW7CafLKI+PdB7AA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to; bh=3sma/77fTZrtiAs+dHj3kJP7akZW8P7vQMy9tzFONiM=; b=mlvNQYFdiqy7/sE+l8u66b4s8VKthPGMgLgr7uoV5wKtSPfulawbu66xgOZmDL9Nwf EP9gvFGe5rzD/Yq5QpMJwDjKcMONKacJiurzGoTdDHPRXjs4IWraU2UqKL6gGTd5eNXi q0TPJoLGtai0RjUyEcHRDwNU8kzYk3/SuB64tafT624lX50RmeNeKxTFCUWsibX+YBMw ktlUotRuWbm+BcnBoE+6Qc3IkWBCwN0p45KT+/BzHg/NHjTTtCsagV7B4ekV48QDTSmm KJH+QTkgWWbgJ/gBnI43wboF6wXigcAr6tANZjg+RZclFjtKs29srM6wKzoSVPzetcmi n2kA== X-Gm-Message-State: ALoCoQlaXOBMXSiehv9weyAd60YUbNxMvN5bn/a8Bk1Y2nhvQTrRqot8rftIPoW2b1ExWqou1zK0 X-Received: by 10.68.109.97 with SMTP id hr1mr7465017pbb.110.1439857206613; Mon, 17 Aug 2015 17:20:06 -0700 (PDT) Received: from localhost (199-230-11-50.PUBLIC.monkeybrains.net. [199.230.11.50]) by smtp.gmail.com with ESMTPSA id fx4sm15866832pbb.92.2015.08.17.17.20.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 17:20:06 -0700 (PDT) Date: Mon, 17 Aug 2015 17:20:02 -0700 From: Joseph Poon To: Chris Pacia Message-ID: <20150818002002.GA3048@lightning.network> References: <6EC9DDF352DC4838AE9B088AB372428A25E1F42A@DS04> <20150817212912.GA15817@muck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2015 00:20:07 -0000 Hi Chris, I don't speak for Peter, but here's my opinion on the matter anyway. On Mon, Aug 17, 2015 at 05:44:56PM -0400, Chris Pacia via bitcoin-dev wrote: > 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. With SPV, it is possible to create a transaction that spends from non-existent coins. With sufficient hashpower, you can construct an SPV proof which sends 1,000 bitcoin to the victim. The attack is "overloadable" in the sense that the attacker is never out of money (they never needed to have 1,000 BTC in the first place). Whereas if the victim is running a full node, the attacker must be signing and spending real outputs in their control, there is a possibility in a re-org that the victim will eventually get their money if it gets re-orged back. On a more fundamental level, the SPV attack isn't on re-orging real/live transactions, it's an attack on *how much money you currently have*. If the client is using SPV, they never had the money in the first place when attacked, irrespective of re-orgs. It is possible to attack thousands of people at once (everyone gets 1,000 bitcoin in false transactions) with a fraction of the hashpower (lie in wait until you get a sufficiently long chain of blocks). If you wished to attack a full-node, it requires you orphaning a chain of valid blocks *live*, meaning you have to send real coins in a real transaction to the victim first. With SPV validation, you only need to construct a chain of invalid blocks off the current blockheight *whenever*. This means you can attack with substantially less hashpower; you don't need 51% of the hashpower to attack SPV wallets. It may be economically unviable to attack a single victim with a full node within a very short timeframe, but it can be economically viable to attack thousands of victims doing SPV validation in a long timeframe. Note I'm not arguing that SPV should be compeletely avoided, I don't have a solid opinion on that (and some threats can definitely be mitigated in various ways, and I certainly like/appreciate the convenience of SPV), but the current SPV security model is definitely weaker than running a full node (if you're handling a lot of money, you should be running a full node), are these issues not well-known by all in the bitcoin community? -- Joseph Poon