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 A46A89F2 for ; Fri, 10 Jul 2015 02:08:55 +0000 (UTC) X-Greylist: delayed 00:08:08 by SQLgrey-1.7.6 Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [96.114.154.167]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4B416157 for ; Fri, 10 Jul 2015 02:08:55 +0000 (UTC) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-08v.sys.comcast.net with comcast id qS0n1q0015E3ZMc01S0nmT; Fri, 10 Jul 2015 02:00:47 +0000 Received: from crushinator.localnet ([IPv6:2601:186:c000:825e:e9f4:8901:87c7:24a0]) by resomta-po-18v.sys.comcast.net with comcast id qS0m1q0014eLRLv01S0mMt; Fri, 10 Jul 2015 02:00:47 +0000 From: Matt Whitlock To: Tom Harding Date: Thu, 09 Jul 2015 22:00:45 -0400 Message-ID: <4333528.v2Hyrgt8Il@crushinator> User-Agent: KMail/4.14.10 (Linux/4.0.5-gentoo; KDE/4.14.10; x86_64; ; ) In-Reply-To: <559F2687.9080003@thinlink.com> References: <1828256.77UID9hUjK@crushinator> <559F2687.9080003@thinlink.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1436493647; bh=JeJmQzgoJ1fKabnXlc2JkQOhu7G0SoW+/Ogx4oIh5mI=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=PXisa8YLTcRscbzmLaNbkKdJMXE6RRjLOBTIcWbpvwW/A7hYHfwC+OuMpgN6LFybm 05Ohyq+7UZL3+tiH7WWYnIdS73S1snRWwd2D8MzcBVCUJDFUWUUH5iARgo6hrIjVtL uIQpgyjNq9nhj0gXbcWwE8NtuDSR2aajqdEsNoIWpvdwbBKeIWwS3xz1BvfffkbgZt wzh5UBqIp4/buPLoctJP2PBkE474CTQ4+O2pYbkNSikX86d9eKKHvZriu8bkxWMIk8 z8zHpKd01XQhD3p4SY4Cldh3vrPNN7+RiUTZNkHyF6w4yjFkj9afnUU2mF1f3ff6Gl GQ1reRZsr7m6g== X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE 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] Can we penalize peers who relay rejected replacement txs? 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: Fri, 10 Jul 2015 02:08:55 -0000 On Thursday, 9 July 2015, at 6:57 pm, Tom Harding wrote: > Replace-by-anything can only work if conflicts are relayed, so the > solution is not to act against the peer. > > Alex Morcos offered a suggestion on IRC -- track recently-rejected > txid's and don't getdata them. The idea sounds good to me. While that's probably a good idea, it wouldn't do much to reduce the load. I am not seeing many repeated transaction hashes among the "rejected replacement" messages in my log.