From mboxrd@z Thu Jan 1 00:00:00 1970 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 1XXL9h-0002Zo-7L for bitcoin-development@lists.sourceforge.net; Fri, 26 Sep 2014 02:21:09 +0000 X-ACL-Warn: Received: from resqmta-po-12v.sys.comcast.net ([96.114.154.171]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) id 1XXL9f-0007qD-Gq for bitcoin-development@lists.sourceforge.net; Fri, 26 Sep 2014 02:21:09 +0000 Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-12v.sys.comcast.net with comcast id ve7X1o00654zqzk01e7XFZ; Fri, 26 Sep 2014 02:07:31 +0000 Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:1e4e:1f4d:332c:3bf6]) by resomta-po-11v.sys.comcast.net with comcast id ve7V1o0092JF60R01e7XJZ; Fri, 26 Sep 2014 02:07:31 +0000 From: Matt Whitlock To: Aaron Voisine Date: Thu, 25 Sep 2014 22:07:28 -0400 Message-ID: <1447373.AzvO89eGJS@crushinator> User-Agent: KMail/4.14.1 (Linux/3.14.14-gentoo; KDE/4.14.1; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [96.114.154.171 listed in list.dnswl.org] 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 X-Headers-End: 1XXL9f-0007qD-Gq Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] SPV clients and relaying double spends 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: Fri, 26 Sep 2014 02:21:09 -0000 What's to stop an attacker from broadcasting millions of spends of the same output(s) and overwhelming nodes with slower connections? Might it be a better strategy not to relay the actual transactions (after the first) but rather only propagate (once) some kind of double-spend alert? On Thursday, 25 September 2014, at 7:02 pm, Aaron Voisine wrote: > There was some discussion of having nodes relay double-spends in order > to alert the network about double spend attempts. > > A lot more users will be using SPV wallets in the future, and one of > the techniques SPV clients use to judge how likely a transaction is to > be confirmed is if it propagates across the network. I wonder if and > when double-spend relaying is introduced, if nodes should also send > BIP61 reject messages or something along those lines to indicate which > transactions those nodes believe to be invalid, but are relaying > anyway. > > This would be subject to sybil attacks, as is monitoring propagation, > however it does still increase the cost of performing a 0 confirmation > double spend attack on an SPV client above just relaying double-spends > without indicating if a node believes the transaction to be valid. > > Aaron Voisine > breadwallet.com