Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qu3Eh-0008F8-F1 for bitcoin-development@lists.sourceforge.net; Thu, 18 Aug 2011 14:06:19 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.47 as permitted sender) client-ip=209.85.215.47; envelope-from=gavinandresen@gmail.com; helo=mail-ew0-f47.google.com; Received: from mail-ew0-f47.google.com ([209.85.215.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Qu3Eg-0006DR-Eb for bitcoin-development@lists.sourceforge.net; Thu, 18 Aug 2011 14:06:19 +0000 Received: by ewy5 with SMTP id 5so1100308ewy.34 for ; Thu, 18 Aug 2011 07:06:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.68.5 with SMTP id q5mr426022wfa.107.1313676001449; Thu, 18 Aug 2011 07:00:01 -0700 (PDT) Received: by 10.142.133.12 with HTTP; Thu, 18 Aug 2011 07:00:01 -0700 (PDT) Date: Thu, 18 Aug 2011 10:00:01 -0400 Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.2 (-) 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 (gavinandresen[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.4 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Qu3Eg-0006DR-Eb Subject: [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 14:06:19 -0000 vector76 on the Forums posted this interesting variation on a 'Finney attack' : https://bitcointalk.org/index.php?topic=36788.msg463391#msg463391 "Let's say I observe the timing of when nodes are broadcasting transactions and how they are propagating through the network. By watching for which nodes are earliest to broadcast transactions from my target, I manage to establish a direct connection to my target. I use a similar method of watching block broadcasts to establish connections to most of the mining pools. Now I create a transaction making a valid, large deposit into my target. I do not broadcast this transaction but I add it to a block that I am attempting to mine. I mine solo, just like normal, except that I have an extra non-broadcasted tx that I am including. Eventually, I succeed in creating a valid block. I do not broadcast it immediately, but instead I wait until someone else mines a block, and when that happens, I immediately broadcast my block to my target. If my target sees my block before the other block, they will accept it, and my transaction will have one confirmation. The block chain has forked, and my target (and possibly other nodes, if my target relays quickly enough) will believe that my block is the correct one, while other nodes will believe that the other fork is the correct one. I immediately request a withdrawal, and my target generates a transaction sending the large amount of coins to an address I control. I also double-spend some of the inputs, sending the coins to myself. The part of the network that did not receive my block first (which hopefully is most of the miners) will accept this as valid and work to include it in the next block. If my block eventually "wins" because enough miners saw my block first and added onto it first, then I have just made a deposit and withdrawal, and I lose nothing. If my block eventually "loses", then the deposit is invalidated. If the deposit tx was not one of the inputs to the withdrawal transaction, then the withdrawal is still valid." ------------------------------- The lessons are "don't accept 1-confirmation transactions" and "try to be well-connected." But maybe the deeper lesson is "don't trust information you get from only one peer." Or maybe "watch for peers that are trying to fool you." -- -- Gavin Andresen