Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qu5jb-0000UY-Jg for bitcoin-development@lists.sourceforge.net; Thu, 18 Aug 2011 16:46:23 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.47 as permitted sender) client-ip=209.85.216.47; envelope-from=gmaxwell@gmail.com; helo=mail-qw0-f47.google.com; Received: from mail-qw0-f47.google.com ([209.85.216.47]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Qu5ja-0007Db-T4 for bitcoin-development@lists.sourceforge.net; Thu, 18 Aug 2011 16:46:23 +0000 Received: by qwh5 with SMTP id 5so2059200qwh.34 for ; Thu, 18 Aug 2011 09:46:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.173.207 with SMTP id q15mr761012qaz.278.1313685977411; Thu, 18 Aug 2011 09:46:17 -0700 (PDT) Received: by 10.229.114.206 with HTTP; Thu, 18 Aug 2011 09:46:17 -0700 (PDT) In-Reply-To: References: <1313681783.14523.79.camel@mei> Date: Thu, 18 Aug 2011 12:46:17 -0400 Message-ID: From: Gregory Maxwell To: Gavin Andresen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Qu5ja-0007Db-T4 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] From the forums: one-confirmation attack X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 16:46:23 -0000 On Thu, Aug 18, 2011 at 12:16 PM, Gavin Andresen wrote: > We could start with an as simple-as-possible "confidence =3D=3D 0 if > confirmations < 2, otherwise confidence =3D function(#confirmations)" > and improve it from there. At the same time, if this causes people to wait less than the 6 blocks that the software currently waits for before leaving unconfirmed status then that would be sad. Simply waiting a number of blocks is an excellent metric and provides robustness against almost all attack patterns in a way that various one-off-heuristics can not as it equates to _real difficulty_ (and real expense (hashing computation, loss of income on the orphaned blocks)) in a way that can't be faked. A few weeks back when there was some rumor going around that mybitcoin lost coin based on some kind of one confirmation attack I described on IRC a similar attack pattern which had a useful improvement: * The attacker runs many widely distributed sybil nodes (e.g. using botnet drones as simple tcp proxies to appear at many addresses). He takes advantage of the fact the bitcoin won't connect to /16s that have already connected to it to further isolate nodes. * By creating normal looking probe transactions which his own nodes won't forward he detects network partitions which he is able to create. He searches for a cut which causes there to be at least two partitions which contain significant mining power. * He creates two accounts at MoronBank. He doesn't even bother identifying MoronBank's node. MoronBank will be in one partition or another. He makes deposits in both partitions, and conflicting transactions in the opposite partitions, while carefully filtering out these transactions from crossing the boundary. (Notably, the network doesn't appear partitioned to everyone else now because he's still forwarding blocks and transactions unrelated to his attack=E2=80=94 it only becomes visible once some of his evil transactions = are mined) * After the funds show up in MoronBank he withdraws and drops the partition= ing. Only if he has difficulty getting MoronBank into the smaller partition does he need to bother locating it and attacking it directly. The bad thing about this attack is that it doesn't require the attacker to have any hash power at all: he captures miners as unwilling (or willing but plausibly deniable) participants. The lost income from orphaned blocks is externalized to the victimized miners (and since most pools don't pay orphaned blocks out of pocket a pool operator would be inclined to help out). The good thing about it is that it's killed dead by nodes adding in a few manually configured peerings, they don't even really need to be trusted: You just need to trust that they don't all go to a single bad-guy conspiracy. At a minimum all major miners should be fully meshed. Unfortunately, We don't currently have software for this as addnode doesn't worry about keeping the links up... and the major pools also don't seem to be interested in participating.