From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 00672C088B for ; Thu, 14 Jan 2021 06:46:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id D7AAD87307 for ; Thu, 14 Jan 2021 06:46:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VizE+d5XLnP for ; Thu, 14 Jan 2021 06:46:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by hemlock.osuosl.org (Postfix) with ESMTPS id 85FD487236 for ; Thu, 14 Jan 2021 06:46:09 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1kzwOS-0008A2-2x; Thu, 14 Jan 2021 16:46:06 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 14 Jan 2021 16:46:00 +1000 Date: Thu, 14 Jan 2021 16:46:00 +1000 From: Anthony Towns To: Suhas Daftuar , Bitcoin Protocol Discussion Message-ID: <20210114064600.gu2qetgo5cw4tl5q@erisian.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score-int: -18 X-Spam-Bar: - Subject: Re: [bitcoin-dev] Proposal for new "disabletx" p2p message X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 06:46:11 -0000 On Wed, Jan 06, 2021 at 11:35:11AM -0500, Suhas Daftuar via bitcoin-dev wrote: > I'm proposing the addition of a new, optional p2p message to allow peers to > communicate that they do not want to send or receive (loose) transactions for > the lifetime of a connection.  > > The goal of this message is to help facilitate connections on the network over > which only block-related data (blocks/headers/compact blocks/etc) are relayed, > to create low-resource connections that help protect against partition attacks > on the network. I think we should separate these ideas -- ie, the protocol change to allow indicating that you don't want transactions, and the policy change to protect against partition attacks using that protocol addition. The idea (obviously?) being that the protocol should be simple and flexible enough to support many possible policies. > ==Specification== > # A new disabletx message is added, [...] > # A node that has sent or received a disabletx message to/from a peer MUST NOT send any of these messages to the peer: > ## inv messages for transactions > [...] > # It is RECOMMENDED that a node that has sent or received a disabletx message to/from a peer not send any of these messages to the peer: > ## addr/getaddr > ## addrv2 (BIP 155) In particular, I think combining these doesn't make sense for: * nodes running with -blocksonly (that want to stay up to date with the blockchain, but don't care about txes) - not sending disabletx reduces their potential connectivity, if nodes are willing to accept more disabletx peers due to the lower resource usage - sending disabletx means they can't maintain their addr db and find other nodes to connect to * non-listening nodes running with -connect to one/more preselected peers - they can't send disabletx generally because they want txes - they don't need addr information (since they only make connections to some known peers), and don't have many peers to relay addresses on to, so are essentially blackholes, so would like to disable addr relay for much the same reasons So to me that says the protocol part of the design's not as flexible as it should be, which suggests DISABLETX and DISABLEADDR. (I think I'm going to flesh out the "FEATURE" idea as an alternative way of dealing with this, but that can be its own thread) Cheers, aj