Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9AED7C000A for ; Tue, 2 Mar 2021 12:19:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 802FF83ED4 for ; Tue, 2 Mar 2021 12:19:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URI_DOTEDU=0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=johnnewbery-com.20150623.gappssmtp.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRCEDUXEln2w for ; Tue, 2 Mar 2021 12:19:31 +0000 (UTC) X-Greylist: delayed 00:07:53 by SQLgrey-1.8.0 Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) by smtp1.osuosl.org (Postfix) with ESMTPS id 3B3CC83EA6 for ; Tue, 2 Mar 2021 12:19:31 +0000 (UTC) Received: by mail-lf1-f52.google.com with SMTP id k9so11024370lfo.12 for ; Tue, 02 Mar 2021 04:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=johnnewbery-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1fSK3s23WRtNAouf12QEtSyJFO0yi0p8j9ilI2qAc0w=; b=Yev3a1hMVilVGCRSkQHMUTq6tPMEP0Yh0x2fvW+Ft47187Ba3c+dFcafA/oyP0k0nf zrcb0w1Zlt+bzE+LHI5bgCQHi1LWNVUu0b1JmCrmwK7NG7OSZh/EuXbVOZh1EFfcjOPw XiPPnbINAYNd0zW723e9VR8i+yNlbvYW9x3HVLqbjpPZz0cf29XRJ9r2sySTi19YpWlZ sPS4IEr8N+6i14qIb0X/qIuLTZRrY4T0NEF3HRmOMNJIlzFnXZqvbYXGIHoOT1VFaqBR rE9iS2Y1pmZyYu/vfflCWeHHxlltU+z5sUwoGflyiL0oIM/zYpirujQLZLbLs/ydIZx4 O5Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1fSK3s23WRtNAouf12QEtSyJFO0yi0p8j9ilI2qAc0w=; b=Z/aC0JDhsVz4GbKkeAeQ1Q8rmlenriwd/g0bAJnfNobQMFvVu6ictiNFOxe+FGWtSr BoIExH/TVg/KeQ+jGhI1Hq6HgJdOR7FEGP+CcmSUX30AjILffoQXN+wvUkcr/+rPie3G x3zOgCJIv99FFOSYlwzQ4zQNgMZKT25bOXuNgwA+PkbUZqZsAb7ndz3g12mzuuDUXsx9 +1tHO1kvmIEwRRPgrDbaHGnoimWIxqgHkwtq4cwMpP8xc2uzMC7RPSblNFnoF8p/Irbf CPJvXLsjMdcQGFqO6kNnACebxw4/fMJuQywv/GvjJHabBX2kbMNzpTQ5uqPxZdKA+Prh BmRw== X-Gm-Message-State: AOAM531Dswa+olHonrOn/DkOZufxUPEEE+IbN/KL3KXJvrpbIiixvfwD aUSAIg5gQox03dRE4poBSrLLY/NFQWFapLlh X-Google-Smtp-Source: ABdhPJzElH/+IdK1lHJ/UITBVrb5ySU4BCiKxIUIBmRrwkRS5M6A5PLwWDjbU4jUE2N3Q++mJVxvDg== X-Received: by 2002:a05:6512:1053:: with SMTP id c19mr11804901lfb.518.1614687095549; Tue, 02 Mar 2021 04:11:35 -0800 (PST) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id c16sm2598982lfb.302.2021.03.02.04.11.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Mar 2021 04:11:34 -0800 (PST) Received: by mail-lf1-f46.google.com with SMTP id 18so22334603lff.6 for ; Tue, 02 Mar 2021 04:11:34 -0800 (PST) X-Received: by 2002:a19:80c9:: with SMTP id b192mr12646086lfd.130.1614687094322; Tue, 02 Mar 2021 04:11:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: John Newbery Date: Tue, 2 Mar 2021 12:11:23 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000ae39b105bc8ca229" X-Mailman-Approved-At: Tue, 02 Mar 2021 12:22:23 +0000 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: Tue, 02 Mar 2021 12:19:35 -0000 --000000000000ae39b105bc8ca229 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Antoine, Nothing in my proposal below precludes introducing a more comprehensive feature negotiation mechanism at some later date. The only changes I'm proposing are to Bitcoin Core's policy for how it treats its peer connections. > If we don't want to introduce a new message and > corresponding code changes, it would be wise at least to extract VERSION'= s > `fRelay` and how Core handles it in its own BIP. I believe this is what BIP 60 does, or did you have something else in mind? > Explicit addr-relay negotiation will offer more > flexibility I agree! > (and more hygienic code paths rather than triggering data > structures initialization in few different locations). Not sure what you mean by hygienic here. This seems like a code style preference. > Given inbound connections might be attacker-controlled and tx-relay opt-out > signaling is also attacker-controlled, wouldn't this give a bias toward a= n > attacker in occupying our inbound slots ? Compared to honest inbound peers, > which in average are going to be full-relay. Sorry - I meant that Bitcoin Core should allow a certain number of inbound peers that do not relay txs. This would be in addition to the full-relay inbound peers. John On Mon, Mar 1, 2021 at 11:11 PM Antoine Riard wrote: > Hi John, > > > I think a good counter-argument against simply using `fRelay` for this > > purpose is that we shouldn't reuse a protocol feature designed for one > > function to achieve a totally different aim. However, we know that node= s > > on the network have been using `fRelay` to disable transaction relay > > since Bitcoin Core version 0.12 (when `-blocksonly` was added), and tha= t > > usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or > > later (when block-relay-only connections were introduced), so using > > `fRelay` to disable transaction relay is now de facto part of the p2p > > protocol. > > > I don't think this is good practice ecosystem-wise. To understand tx-rela= y > opt-out from peers correctly, a _non_ Bitcoin Core client has to implemen= t > the `fRelay` subset of BIP37, but ignore the wider part around FILTER* > messages. Or implement those messages, only to disconnect peers sending > them, thus following BIP111 requirements. > > Thus, future developers of bitcoin software have the choice between > implementing a standard in a non-compliant way or implementing p2p messag= es > for a light client protocol in a way of deprecation ? Even further, an > interpretation of BIP 37 ("Being able to opt-out of _inv_ messages until > the filter is set prevents a client being flooded with traffic in the bri= ef > window of time") would make it okay to send TX messages to your inbound > block-relay-only peers. And that your client shouldn't be disconnected fo= r > such behavior. > > On the long-term, IMHO, better to have a well-defined standard with a > clean negotiation mechanism rather than relying on code specifics of a > given Bitcoin client. If we don't want to introduce a new message and > corresponding code changes, it would be wise at least to extract VERSION'= s > `fRelay` and how Core handles it in its own BIP. > > > I think a better approach would be for Bitcoin Core to only relay addr > > records to an inbound peer if it has previously received an `addr` or > > `addrv2` message from that peer, since that indicates definitively that > > the peer actively gossips `addr` records. This approach was first > > suggested by AJ in the original block-relay-only PR[15]. > > If a node is willingly to opt-out from addr-relay from one of its inbound > peers, how is it supposed to do ? Of course, you can drop such messages o= n > the floor, your peer is just going to waste bandwidth for nothing. IIRC > from past irc p2p meetings, we're really unclear about what a > good-propagation-and-privacy-preserving addr-relay strategy should look > like. Note, that distrusting your inbound peers with your addr-relay migh= t > be a sane direction. Explicit addr-relay negotiation will offer more > flexibility (and more hygienic code paths rather than triggering data > structures initialization in few different locations). > > > - update the inbound eviction logic to protect more inbound peers which > > do not have transaction relay data structures. > > Given inbound connections might be attacker-controlled and tx-relay > opt-out signaling is also attacker-controlled, wouldn't this give a bias > toward an attacker in occupying our inbound slots ? Compared to honest > inbound peers, which in average are going to be full-relay. > > Cheers, > Antoine > > > > Le lun. 1 mars 2021 =C3=A0 16:07, John Newbery via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > >> Hi Suhas, >> >> Thank you for this proposal. I agree with your aims, but I think a new >> P2P message isn't necessary to achieve them. >> >> # Motivation >> >> There are two distinct (but interacting) motivations: >> >> 1. Allow a node to accept more incoming connections which will only be >> used for block propagation (no transaction relay or addr gossip), >> while minimizing resource requirements. >> >> 2. Prevent `addr` gossip messages from being sent to peers which will >> 'black hole' those addrs (i.e. not relay them further). >> >> These motivations interact because if we simply increase the number of >> block-relay-only connections that nodes make without making any >> allowance for the fact those connections won't gossip addr records, then >> we'll increase the number of addr black holes and worsen addr gossip. >> >> # Using fRelay=3Dfalse to signal no transaction relay. >> >> `fRelay` is an optional field in the `version` message. There are three >> BIPs concerned with `fRelay`: >> >> - BIP 37[1] introduced the `fRelay` field to indicate to the recipient >> that they must not relay transactions over the connection until a >> `filteradd` message has been received. >> >> - BIP 60[2] aimed to make the `fRelay` field mandatory. It is not clear >> how widely this BIP has been adopted by implementations. >> >> - BIP 111[3] introduced a `NODE_BLOOM` service bit to indicate that >> bloom filters are served by this node. According to this BIP, "If a >> node does not support bloom filters but receives a "filterload", >> "filteradd", or "filterclear" message from a peer the node should >> disconnect that peer immediately." >> >> Within Bitcoin Core: >> >> - PR 1795[4] (merged in January 2013) added support for BIP 37 Bloom >> filters. >> >> - Since PR 2763[5] (merged in June 2013), Bitcoin Core will _always_ >> include the `fRelay` flag in `version` messages that it sends. Bitcoin >> Core will tolerate the `fRelay` field being present or absent in any >> `version` message that it receives[6]. >> >> - PR 6579[7] (merged in August 2015) implemented BIP 111. From that >> point on, a Bitcoin Core node would disconnect peers that sent it >> `filter*` messages if it hadn't enabled `NODE_BLOOM`, provided the >> peer's version was >=3D 70011. In PR 7708[8] (merged in March 2016) th= is >> was extended to disconnect any peer that sends a `filter*` message, >> regardless of its version (in general, a 'polite disconnect' for any >> peer that requests an unsupported service is probably the best >> behaviour). In PR 16152[9] (merged in July 2019), serving Bloom >> filters was disabled by default, due to potential denial-of-service >> attacks being possible against nodes which serve bloom filters on >> public connections. >> >> - PR 6993[10] (merged in November 2015) started reusing the `fRelay` >> field for the new `-blocksonly` mode. If Bitcoin Core is started with >> `-blocksonly` configured, then it includes `fRelay=3Dfalse` in all of >> the `version` messages it sends. In PR 15759[11] (merged in September >> 2019), this usage of `fRelay` to permanently disable tx relay was >> extended for use by the new block-relay only connection type. >> >> The net effect is that `fRelay` is already being used to indicate that >> transactions should not be relayed over a connection. In the motivation >> for your BIP, you write: >> >> > The low-bandwidth / minimal-resource nature of these connections is >> > currently known only by the initiator of the connection; this is >> > because the transaction relay field in the version message is not a >> > permanent setting for the lifetime of the connection. Consequently, a >> > node receiving an inbound connection with transaction relay disabled >> > cannot distinguish between a peer that will never enable transaction >> > relay (as described in BIP 37) and one that will... >> >> However, as AJ points out in his response [12], the Bitcoin Core node >> _does_ know whether transaction relay can be supported as soon as the >> `version` message is received: >> >> > [...] you either set m_tx_relay->fRelayTxes to true via the VERSION >> > message (either explicitly or by not setting fRelay), or you enable it >> > later with FILTERLOAD or FILTERCLEAR, both of which will cause a >> > disconnect if bloom filters aren't supported. Bloom filter support is >> > (optionally?) indicated via a service bit (BIP 111), so you could >> > assume you know whether they're supported as soon as you receive the >> > VERSION line. >> >> i.e. if Bitcoin Core node is running under normal configuration with >> bloom filters disabled for public connections (which is both the default >> setting and highly recommended due to DoS concerns), then as soon as it >> receives a `version` message with `fRelay=3Dfalse`, it can be sure that >> there will never be any transaction relay with that peer. If the peer >> later tries to enable transaction relay by sending a `filterload` >> message, then the node will disconnect that peer immediately. >> >> In summary, we can continue using the `fRelay` field to indicate that >> no transaction relay can happen for the entire lifetime of the >> connection. Bitcoin Core can postpone allocating resources for >> transaction relay data structures until after the version message has >> been received to minimize resource usage for incoming block-relay-only >> connections. A rough implementation is here[13]. Obviously, a node that >> has been configured to serve bloom filters on public connections would >> not be able to take advantage of this and accept additional incoming >> block-relay-only peers, but I think that's fine - we already discourage >> that configuration. >> >> I think a good counter-argument against simply using `fRelay` for this >> purpose is that we shouldn't reuse a protocol feature designed for one >> function to achieve a totally different aim. However, we know that nodes >> on the network have been using `fRelay` to disable transaction relay >> since Bitcoin Core version 0.12 (when `-blocksonly` was added), and that >> usage was expanded to _all_ nodes running Bitcoin Core version 0.19 or >> later (when block-relay-only connections were introduced), so using >> `fRelay` to disable transaction relay is now de facto part of the p2p >> protocol. >> >> # Preventing addr black holes >> >> Addresses of potential peers are gossiped around the p2p network using >> `addr` messages. When a Bitcoin Core node learns of a new `addr` record, >> it will relay that record to one or two of its peers, chosen at >> random[14]. The idea is that eventually the `addr` record will reach >> most of the nodes on the network. >> >> If there are too many nodes on the network that receive `addr` records >> and do not relay those records on to their peers (termed _addr black >> hole_ nodes), then propagation of those `addr` records suffers -- any >> individual `addr` record is unlikely to reach a large proportion of >> nodes on the network. >> >> Since a motivation for block-relay-only connections is to protect >> against eclipse attacks and thwart network topology analysis, Bitcoin >> Core will not relay `addr` records on those connections, and will ignore >> any `addr` record received over those connections. Therefore, increasing >> the number of block-relay-only connections without changing the `addr` >> gossip logic is likely to increase the prevalence of addr black holes, >> and negatively impact addr propagation. This is why BIP 338 includes: >> >> > 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) >> >> I think a better approach would be for Bitcoin Core to only relay addr >> records to an inbound peer if it has previously received an `addr` or >> `addrv2` message from that peer, since that indicates definitively that >> the peer actively gossips `addr` records. This approach was first >> suggested by AJ in the original block-relay-only PR[15]. >> >> An advantage of this approach is that it will improve addr propagation >> immediately and without any change to the P2P protocol, and will prevent >> sending `addr` records to all addr black holes (such as light clients), >> not just incoming block-relay-only connections. >> >> # Conclusion >> >> We can increase the permitted number of inbound block-relay-only peers >> while minimizing resource requirement _and_ improving addr record >> propagation, without any changes to the p2p protocol required. >> >> I propose that for Bitcoin Core version 22.0: >> >> - only initialize the transaction relay data structures after the >> `version` message is received, and only if fRelay=3Dtrue and >> `NODE_BLOOM` is not offered on this connection. >> - only initialize the addr data structures for inbound connections when >> an `addr`, `addrv2` or `getaddr` message is received on the >> connection, and only consider a connection for addr relay if its addr >> data structures are initialized. >> - update the inbound eviction logic to protect more inbound peers which >> do not have transaction relay data structures. >> >> Then, in version 23.0: >> >> - modestly increase the number of outbound block-relay-only connections. >> >> John >> >> [1] https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki >> [2] https://github.com/bitcoin/bips/blob/master/bip-0060.mediawiki >> [3] https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki >> [4] https://github.com/bitcoin/bitcoin/pull/1795 >> [5] https://github.com/bitcoin/bitcoin/pull/2763 >> [6] >> https://github.com/bitcoin/bitcoin/blob/e49117470b77fb7d53be122c6490ba16= 3c6e304d/src/net_processing.cpp#L2582-L2583 >> [7] https://github.com/bitcoin/bitcoin/pull/6579 >> [8] https://github.com/bitcoin/bitcoin/pull/7708 >> [9] https://github.com/bitcoin/bitcoin/pull/16152 >> [10] https://github.com/bitcoin/bitcoin/pull/6993 >> [11] https://github.com/bitcoin/bitcoin/pull/15759 >> [12] >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018= 347.html >> [13] https://github.com/jnewbery/bitcoin/tree/2021-02-lazy-init-peer >> [14] >> https://github.com/bitcoin/bitcoin/blob/e52ce9f2b312b3cf3b0837918e07d760= 3e241d63/src/net_processing.cpp#L1696-L1700 >> [15] https://github.com/bitcoin/bitcoin/pull/15759#issuecomment-52701275= 7 >> >> > Hi, >> > >> > 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. In particular, by add= ing >> a network message that communicates that transactions will not be relaye= d >> for the life of the connection, we ease the implementation of software t= hat >> could have increased inbound connection limits for such peers, which in >> turn will make it easier to add additional persistent block-relay-only >> connections on the network -- strengthening network security for little >> additional bandwidth. >> > >> > Software has been deployed for over a year now which makes such >> connections, using the BIP37/BIP60 "fRelay" field in the version message= to >> signal that transactions should not be sent initially. However, BIP37 >> allows for transaction relay to be enabled later in the connection's >> lifetime, complicating software that would try to distinguish inbound pe= ers >> that will never relay transactions from those that might. >> > >> > This proposal would add a single new p2p message, "disabletx", which >> (if used at all) must be sent between version and verack. I propose tha= t >> this message is valid for peers advertising protocol version 70017 or >> higher. Software is free to implement this BIP or ignore this message a= nd >> remain compatible with software that does implement it. >> > >> > Full text of the proposed BIP is below. >> > >> > Thanks, >> > Suhas >> > >> > --------------------------------------------------- >> > >> > 
>> >   BIP: XXX
>> >   Layer: Peer Services
>> >   Title: Disable transaction relay message
>> >   Author: Suhas Daftuar 
>> >   Comments-Summary: No comments yet.
>> >   Comments-URI:
>> >   Status: Draft
>> >   Type: Standards Track
>> >   Created: 2020-09-03
>> >   License: BSD-2-Clause
>> >
>> > >> > =3D=3DAbstract=3D=3D >> > >> > This BIP describes a change to the p2p protocol to allow a node to tel= l >> a peer >> > that a connection will not be used for transaction relay, to support >> > block-relay-only connections that are currently in use on the network. >> > >> > =3D=3DMotivation=3D=3D >> > >> > For nearly the past year, software has been deployed[1] which initiate= s >> > connections on the Bitcoin network and sets the transaction relay fiel= d >> > (introduced by BIP 37 and also defined in BIP 60) to false, to prevent >> > transaction relay from occurring on the connection. Additionally, addr >> messages >> > received from the peer are ignored by this software. >> > >> > The purpose of these connections is two-fold: by making additional >> > low-bandwidth connections on which blocks can propagate, the robustnes= s >> of a >> > node to network partitioning attacks is strengthened. Additionally, b= y >> not >> > relaying transactions and ignoring received addresses, the ability of = an >> > adversary to learn the complete network graph (or a subgraph) is >> reduced[2], >> > which in turn increases the cost or difficulty to an attacker seeking >> to carry >> > out a network partitioning attack (when compared with having such >> knowledge). >> > >> > The low-bandwidth / minimal-resource nature of these connections is >> currently >> > known only by the initiator of the connection; this is because the >> transaction >> > relay field in the version message is not a permanent setting for the >> lifetime >> > of the connection. Consequently, a node receiving an inbound >> connection with >> > transaction relay disabled cannot distinguish between a peer that will >> never >> > enable transaction relay (as described in BIP 37) and one that will. >> Moreover, >> > the node also cannot determine that the incoming connection will ignor= e >> relayed >> > addresses; with that knowledge a node would likely choose other peers = to >> > receive announced addresses instead. >> > >> > This proposal adds a new, optional message that a node can send a peer >> when >> > initiating a connection to that peer, to indicate that connection >> should not be >> > used for transaction-relay for the connection's lifetime. In addition, >> without >> > a current mechanism to negotiate whether addresses should be relayed o= n >> a >> > connection, this BIP suggests that address messages not be sent on >> links where >> > tx-relay has been disabled. >> > >> > =3D=3DSpecification=3D=3D >> > >> > # A new disabletx message is added, which is defined as an empty >> message where pchCommand =3D=3D "disabletx". >> > # The protocol version of nodes implementing this BIP must be set to >> 70017 or higher. >> > # If a node sets the transaction relay field in the version message to >> a peer to false, then the disabletx message MAY also be sent in response= to >> a version message from that peer if the peer's protocol version is >=3D >> 70017. If sent, the disabletx message MUST be sent prior to sending a >> verack. >> > # 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 >> > ## getdata messages for transactions >> > ## getdata messages for merkleblock (BIP 37) >> > ## filteradd/filterload/filterclear (BIP 37) >> > ## mempool (BIP 35) >> > # 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) >> > # The behavior regarding sending or processing other message types is >> not specified by this BIP. >> > # Nodes MAY decide to not remain connected to peers that send this >> message (for example, if trying to find a peer that will relay >> transactions). >> > >> > =3D=3DCompatibility=3D=3D >> > >> > Nodes with protocol version >=3D 70017 that do not implement this BIP, >> and nodes >> > with protocol version < 70017, will continue to remain compatible with >> > implementing software: transactions would not be relayed to peers >> sending the >> > disabletx message (provided that BIP 37 or BIP 60 has been >> implemented), and while >> > periodic address relay may still take place, software implementing thi= s >> BIP >> > should not be disconnecting such peers solely for that reason. >> > >> > Disabling address relay is suggested but not required by this BIP, to >> allow for >> > future protocol extensions that might specify more carefully how >> address relay >> > is to be negotiated. This BIP's recommendations for software to not >> relay >> > addresses is intended to be interpreted as guidance in the absence of >> any such >> > future protocol extension, to accommodate existing software behavior. >> > >> > Note that all messages specified in BIP 152, including blocktxn and >> > getblocktxn, are permitted between peers that have sent/received a >> disabletx >> > message, subject to the feature negotiation of BIP 152. >> > >> > =3D=3DImplementation=3D=3D >> > >> > TBD >> > >> > =3D=3DReferences=3D=3D >> > >> > # Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 >> implemented this functionality] since version 0.19.0.1, released in >> November 2019. >> > # For example, see >> https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and >> https://arxiv.org/pdf/1812.00942.pdf. >> > >> > =3D=3DCopyright=3D=3D >> > >> > This BIP is licensed under the 2-clause BSD license. >> >> On Wed, Jan 6, 2021 at 4:35 PM Suhas Daftuar via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> Hi, >>> >>> I'm proposing the addition of a new, optional p2p message to allow peer= s >>> 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. In particular, by ad= ding >>> a network message that communicates that transactions will not be relay= ed >>> for the life of the connection, we ease the implementation of software = that >>> could have increased inbound connection limits for such peers, which in >>> turn will make it easier to add additional persistent block-relay-only >>> connections on the network -- strengthening network security for little >>> additional bandwidth. >>> >>> Software has been deployed for over a year now which makes such >>> connections, using the BIP37/BIP60 "fRelay" field in the version messag= e to >>> signal that transactions should not be sent initially. However, BIP37 >>> allows for transaction relay to be enabled later in the connection's >>> lifetime, complicating software that would try to distinguish inbound p= eers >>> that will never relay transactions from those that might. >>> >>> This proposal would add a single new p2p message, "disabletx", which (i= f >>> used at all) must be sent between version and verack. I propose that t= his >>> message is valid for peers advertising protocol version 70017 or higher= . >>> Software is free to implement this BIP or ignore this message and remai= n >>> compatible with software that does implement it. >>> >>> Full text of the proposed BIP is below. >>> >>> Thanks, >>> Suhas >>> >>> --------------------------------------------------- >>> >>> 
>>>   BIP: XXX
>>>   Layer: Peer Services
>>>   Title: Disable transaction relay message
>>>   Author: Suhas Daftuar 
>>>   Comments-Summary: No comments yet.
>>>   Comments-URI:
>>>   Status: Draft
>>>   Type: Standards Track
>>>   Created: 2020-09-03
>>>   License: BSD-2-Clause
>>>
>>> >>> =3D=3DAbstract=3D=3D >>> >>> This BIP describes a change to the p2p protocol to allow a node to tell= a peer >>> that a connection will not be used for transaction relay, to support >>> block-relay-only connections that are currently in use on the network. >>> >>> =3D=3DMotivation=3D=3D >>> >>> For nearly the past year, software has been deployed[1] which initiates >>> connections on the Bitcoin network and sets the transaction relay field >>> (introduced by BIP 37 and also defined in BIP 60) to false, to prevent >>> transaction relay from occurring on the connection. Additionally, addr = messages >>> received from the peer are ignored by this software. >>> >>> The purpose of these connections is two-fold: by making additional >>> low-bandwidth connections on which blocks can propagate, the robustness= of a >>> node to network partitioning attacks is strengthened. Additionally, by= not >>> relaying transactions and ignoring received addresses, the ability of a= n >>> adversary to learn the complete network graph (or a subgraph) is reduce= d[2], >>> which in turn increases the cost or difficulty to an attacker seeking t= o carry >>> out a network partitioning attack (when compared with having such knowl= edge). >>> >>> The low-bandwidth / minimal-resource nature of these connections is cur= rently >>> known only by the initiator of the connection; this is because the tran= saction >>> relay field in the version message is not a permanent setting for the l= ifetime >>> of the connection. Consequently, a node receiving an inbound connectio= n with >>> transaction relay disabled cannot distinguish between a peer that will = never >>> enable transaction relay (as described in BIP 37) and one that will. M= oreover, >>> the node also cannot determine that the incoming connection will ignore= relayed >>> addresses; with that knowledge a node would likely choose other peers t= o >>> receive announced addresses instead. >>> >>> This proposal adds a new, optional message that a node can send a peer = when >>> initiating a connection to that peer, to indicate that connection shoul= d not be >>> used for transaction-relay for the connection's lifetime. In addition, = without >>> a current mechanism to negotiate whether addresses should be relayed on= a >>> connection, this BIP suggests that address messages not be sent on link= s where >>> tx-relay has been disabled. >>> >>> =3D=3DSpecification=3D=3D >>> >>> # A new disabletx message is added, which is defined as an empty messag= e where pchCommand =3D=3D "disabletx". >>> # The protocol version of nodes implementing this BIP must be set to 70= 017 or higher. >>> # If a node sets the transaction relay field in the version message to = a peer to false, then the disabletx message MAY also be sent in response to= a version message from that peer if the peer's protocol version is >=3D 70= 017. If sent, the disabletx message MUST be sent prior to sending a verack. >>> # A node that has sent or received a disabletx message to/from a peer M= UST NOT send any of these messages to the peer: >>> ## inv messages for transactions >>> ## getdata messages for transactions >>> ## getdata messages for merkleblock (BIP 37) >>> ## filteradd/filterload/filterclear (BIP 37) >>> ## mempool (BIP 35) >>> # It is RECOMMENDED that a node that has sent or received a disabletx m= essage to/from a peer not send any of these messages to the peer: >>> ## addr/getaddr >>> ## addrv2 (BIP 155) >>> # The behavior regarding sending or processing other message types is n= ot specified by this BIP. >>> # Nodes MAY decide to not remain connected to peers that send this mess= age (for example, if trying to find a peer that will relay transactions). >>> >>> =3D=3DCompatibility=3D=3D >>> >>> Nodes with protocol version >=3D 70017 that do not implement this BIP, = and nodes >>> with protocol version < 70017, will continue to remain compatible with >>> implementing software: transactions would not be relayed to peers sendi= ng the >>> disabletx message (provided that BIP 37 or BIP 60 has been implemented)= , and while >>> periodic address relay may still take place, software implementing this= BIP >>> should not be disconnecting such peers solely for that reason. >>> >>> Disabling address relay is suggested but not required by this BIP, to a= llow for >>> future protocol extensions that might specify more carefully how addres= s relay >>> is to be negotiated. This BIP's recommendations for software to not rel= ay >>> addresses is intended to be interpreted as guidance in the absence of a= ny such >>> future protocol extension, to accommodate existing software behavior. >>> >>> Note that all messages specified in BIP 152, including blocktxn and >>> getblocktxn, are permitted between peers that have sent/received a disa= bletx >>> message, subject to the feature negotiation of BIP 152. >>> >>> =3D=3DImplementation=3D=3D >>> >>> TBD >>> >>> =3D=3DReferences=3D=3D >>> >>> # Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 imple= mented this functionality] since version 0.19.0.1, released in November 201= 9. >>> # For example, see https://www.cs.umd.edu/projects/coinscope/coinscope.= pdf and https://arxiv.org/pdf/1812.00942.pdf. >>> >>> =3D=3DCopyright=3D=3D >>> >>> This BIP is licensed under the 2-clause BSD license. >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --000000000000ae39b105bc8ca229 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Antoine,

Nothing in my proposal be= low precludes introducing a more comprehensive
feature negotiation mecha= nism at some later date. The only changes I'm
proposing are to Bitco= in Core's policy for how it treats its peer
connections.

>= If we don't want to introduce a new message and
> corresponding = code changes, it would be wise at least to extract VERSION's
> `f= Relay` and how Core handles it in its own BIP.

I believe this is wha= t BIP 60 does, or did you have something else in
mind?

> Expli= cit addr-relay negotiation will offer more
> flexibility

I agr= ee!

> (and more hygienic code paths rather than triggering data> structures initialization in few different locations).

Not su= re what you mean by hygienic here. This seems like a code style
preferen= ce.

> Given inbound connections might be attacker-controlled and = tx-relay opt-out
> signaling is also attacker-controlled, wouldn'= t this give a bias toward an
> attacker in occupying our inbound slot= s ? Compared to honest inbound peers,
> which in average are going to= be full-relay.

Sorry - I meant that Bitcoin Core should allow a cer= tain number of
inbound peers that do not relay txs. This would be in add= ition to the
full-relay inbound peers.

John

On Mon, Mar 1, 202= 1 at 11:11 PM Antoine Riard <= antoine.riard@gmail.com> wrote:
Hi John,
> I think a good counter-argument against simply using `fRelay` for th= is
> purpose is that we shouldn't reuse a protocol feature design= ed for one
> function to achieve a totally different aim. However, we= know that nodes
> on the network have been using `fRelay` to disable= transaction relay
> since Bitcoin Core version 0.12 (when `-blockson= ly` was added), and that
> usage was expanded to _all_ nodes running = Bitcoin Core version 0.19 or
> later (when block-relay-only connectio= ns were introduced), so using
> `fRelay` to disable transaction relay= is now de facto part of the p2p
> protocol.


I don't t= hink this is good practice ecosystem-wise. To understand tx-relay opt-out f= rom peers correctly, a _non_ Bitcoin Core client has to implement the `fRel= ay` subset of BIP37, but ignore the wider part around FILTER* messages. Or = implement those messages, only to disconnect peers sending them, thus follo= wing BIP111 requirements.

Thus, future developers of bitcoin softwar= e have the choice between implementing a standard in a non-compliant way or= implementing p2p messages for a light client protocol in a way of deprecat= ion ? Even further, an interpretation of BIP 37 ("Being able to opt-ou= t of _inv_ messages until the filter is set prevents a client being flooded= with traffic in the brief window of time") would make it okay to send= TX messages to your inbound block-relay-only peers. And that your client s= houldn't be disconnected for such behavior.

On the long-term, IM= HO, better to have a well-defined standard with a clean negotiation mechani= sm rather than relying on code specifics of a given Bitcoin client. If we d= on't want to introduce a new message and corresponding code changes, it= would be wise at least to extract VERSION's `fRelay` and how Core hand= les it in its own BIP.

> I think a better approach would be for B= itcoin Core to only relay addr
> records to an inbound peer if it has= previously received an `addr` or
> `addrv2` message from that peer, = since that indicates definitively that
> the peer actively gossips `a= ddr` records. This approach was first
> suggested by AJ in the origin= al block-relay-only PR[15].

If a node is willingly to opt= -out from addr-relay from one of its inbound peers, how is it supposed to d= o ? Of course, you can drop such messages on the floor, your peer is just g= oing to waste bandwidth for nothing. IIRC from past irc p2p meetings, we= 9;re really unclear about what a good-propagation-and-privacy-preserving ad= dr-relay strategy should look like. Note, that distrusting your inbound pee= rs with your addr-relay might be a sane direction. Explicit addr-relay nego= tiation will offer more flexibility (and more hygienic code paths rather th= an triggering data structures initialization in few different locations).

> - update the inbound eviction logic to protect more i= nbound peers which
> do not have transaction relay data structures.
Given inbound connections might be attacker-controlled and= tx-relay opt-out signaling is also attacker-controlled, wouldn't this = give a bias toward an attacker in occupying our inbound slots ? Compared to= honest inbound peers, which in average are going to be full-relay.

Cheers,
Antoine


=

= Le=C2=A0lun. 1 mars 2021 =C3=A0=C2=A016:07, John Newbery via bitcoin-dev &l= t;bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit=C2=A0:
Hi Suh= as,

Thank you for this proposal. I agree with your aims, but I think= a new
P2P message isn't necessary to achieve them.

# Motivat= ion

There are two distinct (but interacting) motivations:

1. = Allow a node to accept more incoming connections which will only be
=C2= =A0 =C2=A0used for block propagation (no transaction relay or addr gossip),=
=C2=A0 =C2=A0while minimizing resource requirements.

2. Prevent = `addr` gossip messages from being sent to peers which will
=C2=A0 =C2=A0= 'black hole' those addrs (i.e. not relay them further).

Thes= e motivations interact because if we simply increase the number of
block= -relay-only connections that nodes make without making any
allowance for= the fact those connections won't gossip addr records, then
we'l= l increase the number of addr black holes and worsen addr gossip.

# = Using fRelay=3Dfalse to signal no transaction relay.

`fRelay` is an = optional field in the `version` message. There are three
BIPs concerned = with `fRelay`:

- BIP 37[1] introduced the `fRelay` field to indicate= to the recipient
=C2=A0 that they must not relay transactions over the = connection until a
=C2=A0 `filteradd` message has been received.

= - BIP 60[2] aimed to make the `fRelay` field mandatory. It is not clear
= =C2=A0 how widely this BIP has been adopted by implementations.

- BI= P 111[3] introduced a `NODE_BLOOM` service bit to indicate that
=C2=A0 b= loom filters are served by this node. According to this BIP, "If a
= =C2=A0 node does not support bloom filters but receives a "filterload&= quot;,
=C2=A0 "filteradd", or "filterclear" message = from a peer the node should
=C2=A0 disconnect that peer immediately.&quo= t;

Within Bitcoin Core:

- PR 1795[4] (merged in January 2013)= added support for BIP 37 Bloom
=C2=A0 filters.

- Since PR 2763[5= ] (merged in June 2013), Bitcoin Core will _always_
=C2=A0 include the `= fRelay` flag in `version` messages that it sends. Bitcoin
=C2=A0 Core wi= ll tolerate the `fRelay` field being present or absent in any
=C2=A0 `ve= rsion` message that it receives[6].

- PR 6579[7] (merged in August 2= 015) implemented BIP 111. From that
=C2=A0 point on, a Bitcoin Core node= would disconnect peers that sent it
=C2=A0 `filter*` messages if it had= n't enabled `NODE_BLOOM`, provided the
=C2=A0 peer's version was= >=3D 70011. In PR 7708[8] (merged in March 2016) this
=C2=A0 was ext= ended to disconnect any peer that sends a `filter*` message,
=C2=A0 rega= rdless of its version (in general, a 'polite disconnect' for any=C2=A0 peer that requests an unsupported service is probably the best
= =C2=A0 behaviour). In PR 16152[9] (merged in July 2019), serving Bloom
= =C2=A0 filters was disabled by default, due to potential denial-of-service<= br>=C2=A0 attacks being possible against nodes which serve bloom filters on=
=C2=A0 public connections.

- PR 6993[10] (merged in November 201= 5) started reusing the `fRelay`
=C2=A0 field for the new `-blocksonly` m= ode. If Bitcoin Core is started with
=C2=A0 `-blocksonly` configured, th= en it includes `fRelay=3Dfalse` in all of
=C2=A0 the `version` messages = it sends. In PR 15759[11] (merged =C2=A0in September
=C2=A0 2019), this = usage of `fRelay` to permanently disable tx relay was
=C2=A0 extended fo= r use by the new block-relay only connection type.

The net effect is= that `fRelay` is already being used to indicate that
transactions shoul= d not be relayed over a connection. In the motivation
for your BIP, you = write:

> The low-bandwidth / minimal-resource nature of these con= nections is
> currently known only by the initiator of the connection= ; this is
> because the transaction relay field in the version messag= e is not a
> permanent setting for the lifetime of the connection.=C2= =A0 Consequently, a
> node receiving an inbound connection with trans= action relay disabled
> cannot distinguish between a peer that will n= ever enable transaction
> relay (as described in BIP 37) and one that= will...

However, as AJ points out in his response [12], the Bitcoin= Core node
_does_ know whether transaction relay can be supported as soo= n as the
`version` message is received:

> [...] you either set= m_tx_relay->fRelayTxes to true via the VERSION
> message (either = explicitly or by not setting fRelay), or you enable it
> later with F= ILTERLOAD or FILTERCLEAR, both of which will cause a
> disconnect if = bloom filters aren't supported. Bloom filter support is
> (option= ally?) indicated via a service bit (BIP 111), so you could
> assume y= ou know whether they're supported as soon as you receive the
> VE= RSION line.

i.e. if Bitcoin Core node is running under normal config= uration with
bloom filters disabled for public connections (which is bot= h the default
setting and highly recommended due to DoS concerns), then = as soon as it
receives a `version` message with `fRelay=3Dfalse`, it can= be sure that
there will never be any transaction relay with that peer. = If the peer
later tries to enable transaction relay by sending a `filter= load`
message, then the node will disconnect that peer immediately.
<= br>In summary, we can continue using the `fRelay` field to indicate thatno transaction relay can happen for the entire lifetime of the
connecti= on.=C2=A0 Bitcoin Core can postpone allocating resources for
transaction= relay data structures until after the version message has
been received= to minimize resource usage for incoming block-relay-only
connections. A= rough implementation is here[13]. Obviously, a node that
has been confi= gured to serve bloom filters on public connections would
not be able to = take advantage of this and accept additional incoming
block-relay-only p= eers, but I think that's fine - we already discourage
that configura= tion.

I think a good counter-argument against simply using `fRelay` = for this
purpose is that we shouldn't reuse a protocol feature desig= ned for one
function to achieve a totally different aim. However, we kno= w that nodes
on the network have been using `fRelay` to disable transact= ion relay
since Bitcoin Core version 0.12 (when `-blocksonly` was added)= , and that
usage was expanded to _all_ nodes running Bitcoin Core versio= n 0.19 or
later (when block-relay-only connections were introduced), so = using
`fRelay` to disable transaction relay is now de facto part of the = p2p
protocol.

# Preventing addr black holes

Addresses of p= otential peers are gossiped around the p2p network using
`addr` messages= . When a Bitcoin Core node learns of a new `addr` record,
it will relay = that record to one or two of its peers, chosen at
random[14]. The idea i= s that eventually the `addr` record will reach
most of the nodes on the = network.

If there are too many nodes on the network that receive `ad= dr` records
and do not relay those records on to their peers (termed _ad= dr black
hole_ nodes), then propagation of those `addr` records suffers = -- any
individual `addr` record is unlikely to reach a large proportion = of
nodes on the network.

Since a motivation for block-relay-only = connections is to protect
against eclipse attacks and thwart network top= ology analysis, Bitcoin
Core will not relay `addr` records on those conn= ections, and will ignore
any `addr` record received over those connectio= ns. Therefore, increasing
the number of block-relay-only connections wit= hout changing the `addr`
gossip logic is likely to increase the prevalen= ce of addr black holes,
and negatively impact addr propagation. This is = why BIP 338 includes:

> It is RECOMMENDED that a node that has se= nt or received a disabletx
> message to/from a peer not send any of t= hese messages to the peer:
>
> - addr/getaddr
> - addrv2= (BIP 155)

I think a better approach would be for Bitcoin Core to on= ly relay addr
records to an inbound peer if it has previously received a= n `addr` or
`addrv2` message from that peer, since that indicates defini= tively that
the peer actively gossips `addr` records. This approach was = first
suggested by AJ in the original block-relay-only PR[15].

An= advantage of this approach is that it will improve addr propagation
imm= ediately and without any change to the P2P protocol, and will prevent
se= nding `addr` records to all addr black holes (such as light clients),
no= t just incoming block-relay-only connections.

# Conclusion

We= can increase the permitted number of inbound block-relay-only peers
whi= le minimizing resource requirement _and_ improving addr record
propagati= on, without any changes to the p2p protocol required.

I propose that= for Bitcoin Core version 22.0:

- only initialize the transaction re= lay data structures after the
=C2=A0 `version` message is received, and = only if fRelay=3Dtrue and
=C2=A0 `NODE_BLOOM` is not offered on this con= nection.
- only initialize the addr data structures for inbound connecti= ons when
=C2=A0 an `addr`, `addrv2` or `getaddr` message is received on = the
=C2=A0 connection, and only consider a connection for addr relay if = its addr
=C2=A0 data structures are initialized.
- update the inbound= eviction logic to protect more inbound peers which
=C2=A0 do not have t= ransaction relay data structures.

Then, in version 23.0:

- mo= destly increase the number of outbound block-relay-only connections.
John

[1] https://github.com/bitcoin/bips/blob/mas= ter/bip-0037.mediawiki
[2] https://github.com/bitc= oin/bips/blob/master/bip-0060.mediawiki
[3] https:= //github.com/bitcoin/bips/blob/master/bip-0111.mediawiki
[4] https:/= /github.com/bitcoin/bitcoin/pull/1795
[5] https://github.com/bitcoin= /bitcoin/pull/2763
[6] https://github.com/bitcoin/bitcoin/blob/e49117470= b77fb7d53be122c6490ba163c6e304d/src/net_processing.cpp#L2582-L2583
[= 7] https://github.com/bitcoin/bitcoin/pull/6579
[8] https://github.c= om/bitcoin/bitcoin/pull/7708
[9] https://github.com/bitcoin/bitcoin= /pull/16152
[10] https://github.com/bitcoin/bitcoin/pull/6993[11] https://github.com/bitcoin/bitcoin/pull/15759
[12] https://lists.linuxfoundation.org/pipermail/bitco= in-dev/2021-January/018347.html
[13] https://gith= ub.com/jnewbery/bitcoin/tree/2021-02-lazy-init-peer
[14] https://github.= com/bitcoin/bitcoin/blob/e52ce9f2b312b3cf3b0837918e07d7603e241d63/src/net_p= rocessing.cpp#L1696-L1700
[15] https://githu= b.com/bitcoin/bitcoin/pull/15759#issuecomment-527012757

> Hi,=
>
> I'm proposing the addition of a new, optional p2p mes= sage to allow peers to communicate that they do not want to send or receive= (loose) transactions for the lifetime of a connection.
>
> T= he goal of this message is to help facilitate connections on the network ov= er which only block-related data (blocks/headers/compact blocks/etc) are re= layed, to create low-resource connections that help protect against partiti= on attacks on the network.=C2=A0 In particular, by adding a network message= that communicates that transactions will not be relayed for the life of th= e connection, we ease the implementation of software that could have increa= sed inbound connection limits for such peers, which in turn will make it ea= sier to add additional persistent block-relay-only connections on the netwo= rk -- strengthening network security for little additional bandwidth.
&g= t;
> Software has been deployed for over a year now which makes such= connections, using the BIP37/BIP60 "fRelay" field in the version= message to signal that transactions should not be sent initially.=C2=A0 Ho= wever, BIP37 allows for transaction relay to be enabled later in the connec= tion's lifetime, complicating software that would try to distinguish in= bound peers that will never relay transactions from those that might.
&g= t;
> This proposal would add a single new p2p message, "disable= tx", which (if used at all) must be sent between version and verack.= =C2=A0 I propose that this message is valid for peers advertising protocol = version 70017 or higher.=C2=A0 Software is free to implement this BIP or ig= nore this message and remain compatible with software that does implement i= t.
>
> Full text of the proposed BIP is below.
>
>= ; Thanks,
> Suhas
>
> ----------------------------------= -----------------
>
> <pre>
> =C2=A0 BIP: XXX
&= gt; =C2=A0 Layer: Peer Services
> =C2=A0 Title: Disable transaction r= elay message
> =C2=A0 Author: Suhas Daftuar <sdaftuar@chaincode.com>
&g= t; =C2=A0 Comments-Summary: No comments yet.
> =C2=A0 Comments-URI:> =C2=A0 Status: Draft
> =C2=A0 Type: Standards Track
> = =C2=A0 Created: 2020-09-03
> =C2=A0 License: BSD-2-Clause
> <= ;/pre>
>
> =3D=3DAbstract=3D=3D
>
> This BIP d= escribes a change to the p2p protocol to allow a node to tell a peer
>= ; that a connection will not be used for transaction relay, to support
&= gt; block-relay-only connections that are currently in use on the network.<= br>>
> =3D=3DMotivation=3D=3D
>
> For nearly the pas= t year, software has been deployed[1] which initiates
> connections o= n the Bitcoin network and sets the transaction relay field
> (introdu= ced by BIP 37 and also defined in BIP 60) to false, to prevent
> tran= saction relay from occurring on the connection. Additionally, addr messages=
> received from the peer are ignored by this software.
>
&= gt; The purpose of these connections is two-fold: by making additional
&= gt; low-bandwidth connections on which blocks can propagate, the robustness= of a
> node to network partitioning attacks is strengthened.=C2=A0 A= dditionally, by not
> relaying transactions and ignoring received add= resses, the ability of an
> adversary to learn the complete network g= raph (or a subgraph) is reduced[2],
> which in turn increases the cos= t or difficulty to an attacker seeking to carry
> out a network parti= tioning attack (when compared with having such knowledge).
>
>= The low-bandwidth / minimal-resource nature of these connections is curren= tly
> known only by the initiator of the connection; this is because = the transaction
> relay field in the version message is not a permane= nt setting for the lifetime
> of the connection.=C2=A0 Consequently, = a node receiving an inbound connection with
> transaction relay disab= led cannot distinguish between a peer that will never
> enable transa= ction relay (as described in BIP 37) and one that will.=C2=A0 Moreover,
= > the node also cannot determine that the incoming connection will ignor= e relayed
> addresses; with that knowledge a node would likely choose= other peers to
> receive announced addresses instead.
>
&g= t; This proposal adds a new, optional message that a node can send a peer w= hen
> initiating a connection to that peer, to indicate that connecti= on should not be
> used for transaction-relay for the connection'= s lifetime. In addition, without
> a current mechanism to negotiate w= hether addresses should be relayed on a
> connection, this BIP sugges= ts that address messages not be sent on links where
> tx-relay has be= en disabled.
>
> =3D=3DSpecification=3D=3D
>
> # = A new disabletx message is added, which is defined as an empty message wher= e pchCommand =3D=3D "disabletx".
> # The protocol version o= f nodes implementing this BIP must be set to 70017 or higher.
> # If = a node sets the transaction relay field in the version message to a peer to= false, then the disabletx message MAY also be sent in response to a versio= n message from that peer if the peer's protocol version is >=3D 7001= 7. If sent, the disabletx message MUST be sent prior to sending a verack.> # A node that has sent or received a disabletx message to/from a pee= r MUST NOT send any of these messages to the peer:
> ## inv messages = for transactions
> ## getdata messages for transactions
> ## ge= tdata messages for merkleblock (BIP 37)
> ## filteradd/filterload/fil= terclear (BIP 37)
> ## mempool (BIP 35)
> # It is RECOMMENDED t= hat 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)
> # The behavior regarding sending or processing ot= her message types is not specified by this BIP.
> # Nodes MAY decide = to not remain connected to peers that send this message (for example, if tr= ying to find a peer that will relay transactions).
>
> =3D=3DC= ompatibility=3D=3D
>
> Nodes with protocol version >=3D 700= 17 that do not implement this BIP, and nodes
> with protocol version = < 70017, will continue to remain compatible with
> implementing so= ftware: transactions would not be relayed to peers sending the
> disa= bletx message (provided that BIP 37 or BIP 60 has been implemented), and wh= ile
> periodic address relay may still take place, software implement= ing this BIP
> should not be disconnecting such peers solely for that= reason.
>
> Disabling address relay is suggested but not requ= ired by this BIP, to allow for
> future protocol extensions that migh= t specify more carefully how address relay
> is to be negotiated. Thi= s BIP's recommendations for software to not relay
> addresses is = intended to be interpreted as guidance in the absence of any such
> f= uture protocol extension, to accommodate existing software behavior.
>= ;
> Note that all messages specified in BIP 152, including blocktxn = and
> getblocktxn, are permitted between peers that have sent/receive= d a disabletx
> message, subject to the feature negotiation of BIP 15= 2.
>
> =3D=3DImplementation=3D=3D
>
> TBD
>=
> =3D=3DReferences=3D=3D
>
> # Bitcoin Core has [http= s://github.com/bitcoin/bitcoin/pull/15759 implemented this functionalit= y] since version 0.19.0.1, released in November 2019.
> # For example= , see https://www.cs.umd.edu/projects/coinscope/coinscope.pdf and ht= tps://arxiv.org/pdf/1812.00942.pdf.
>
> =3D=3DCopyright=3D= =3D
>
> This BIP is licensed under the 2-clause BSD license.

On Wed, Jan 6, 2021 at 4:35 PM Suhas Daftuar via bitcoin-dev <bitcoin= -dev@lists.linuxfoundation.org> wrote:
Hi,

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 f= or the lifetime of a connection.=C2=A0

The goal of= this message is to help facilitate=C2=A0connections on the network over wh= ich only block-related data (blocks/headers/compact blocks/etc) are relayed= , to create low-resource connections that help protect against partition at= tacks on the network.=C2=A0 In particular, by adding a network message that= communicates that transactions will not be relayed for the life of the con= nection, we ease the implementation of software that could have increased i= nbound connection limits for such peers, which in turn will make it easier = to add additional persistent block-relay-only connections on the network --= strengthening network security for little additional bandwidth.
=
Software has been deployed for over a year now which makes s= uch connections, using the BIP37/BIP60 "fRelay" field in the vers= ion message to signal that transactions should not be sent initially.=C2=A0= However, BIP37 allows for transaction relay to be enabled=C2=A0later in th= e connection's lifetime, complicating software that would try to distin= guish inbound peers that will never relay transactions from those that migh= t.

This proposal would add a single new p2p messag= e, "disabletx", which (if used at all) must be sent between versi= on and verack.=C2=A0 I propose that this message is valid for peers adverti= sing protocol version 70017 or higher.=C2=A0 Software=C2=A0is free to imple= ment this BIP or ignore this message and remain compatible with software th= at does implement it.

Full text of the proposed BI= P is below.

Thanks,
Suhas
<= div>
---------------------------------------------------

&=
lt;pre>
  BIP: XXX
  Layer: Peer Services
  Title: Disable transaction relay message
  Author: Suhas Daftuar <sdaftuar@chaincode.com>
  Comments-Summary: No comments yet.
  Comments-URI:
  Status: Draft
  Type: Standards Track
  Created: 2020-09-03
  License: BSD-2-Clause
</pre>

=3D=3DAbstract=3D=3D

This BIP describes a change to the p2p protocol to allow a node to tell a p=
eer
that a connection will not be used for transaction relay, to support
block-relay-only connections that are currently in use on the network.

=3D=3DMotivation=3D=3D

For nearly the past year, software has been deployed[1] which initiates
connections on the Bitcoin network and sets the transaction relay field
(introduced by BIP 37 and also defined in BIP 60) to false, to prevent
transaction relay from occurring on the connection. Additionally, addr mess=
ages
received from the peer are ignored by this software.

The purpose of these connections is two-fold: by making additional
low-bandwidth connections on which blocks can propagate, the robustness of =
a
node to network partitioning attacks is strengthened.  Additionally, by not
relaying transactions and ignoring received addresses, the ability of an
adversary to learn the complete network graph (or a subgraph) is reduced[2]=
,
which in turn increases the cost or difficulty to an attacker seeking to ca=
rry
out a network partitioning attack (when compared with having such knowledge=
).

The low-bandwidth / minimal-resource nature of these connections is current=
ly
known only by the initiator of the connection; this is because the transact=
ion
relay field in the version message is not a permanent setting for the lifet=
ime
of the connection.  Consequently, a node receiving an inbound connection wi=
th
transaction relay disabled cannot distinguish between a peer that will neve=
r
enable transaction relay (as described in BIP 37) and one that will.  Moreo=
ver,
the node also cannot determine that the incoming connection will ignore rel=
ayed
addresses; with that knowledge a node would likely choose other peers to
receive announced addresses instead.

This proposal adds a new, optional message that a node can send a peer when
initiating a connection to that peer, to indicate that connection should no=
t be
used for transaction-relay for the connection's lifetime. In addition, =
without
a current mechanism to negotiate whether addresses should be relayed on a
connection, this BIP suggests that address messages not be sent on links wh=
ere
tx-relay has been disabled.

=3D=3DSpecification=3D=3D

# A new disabletx message is added, which is defined as an empty message wh=
ere pchCommand =3D=3D "disabletx".
# The protocol version of nodes implementing this BIP must be set to 70017 =
or higher.
# If a node sets the transaction relay field in the version message to a pe=
er to false, then the disabletx message MAY also be sent in response to a v=
ersion message from that peer if the peer's protocol version is >=3D=
 70017. If sent, the disabletx message MUST be sent prior to sending a vera=
ck.
# 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
## getdata messages for transactions
## getdata messages for merkleblock (BIP 37)
## filteradd/filterload/filterclear (BIP 37)
## mempool (BIP 35)
# It is RECOMMENDED that a node that has sent or received a disabletx messa=
ge to/from a peer not send any of these messages to the peer:
## addr/getaddr
## addrv2 (BIP 155)
# The behavior regarding sending or processing other message types is not s=
pecified by this BIP.
# Nodes MAY decide to not remain connected to peers that send this message =
(for example, if trying to find a peer that will relay transactions).

=3D=3DCompatibility=3D=3D

Nodes with protocol version >=3D 70017 that do not implement this BIP, a=
nd nodes
with protocol version < 70017, will continue to remain compatible with
implementing software: transactions would not be relayed to peers sending t=
he
disabletx message (provided that BIP 37 or BIP 60 has been implemented), an=
d while
periodic address relay may still take place, software implementing this BIP
should not be disconnecting such peers solely for that reason.

Disabling address relay is suggested but not required by this BIP, to allow=
 for
future protocol extensions that might specify more carefully how address re=
lay
is to be negotiated. This BIP's recommendations for software to not rel=
ay
addresses is intended to be interpreted as guidance in the absence of any s=
uch
future protocol extension, to accommodate existing software behavior.

Note that all messages specified in BIP 152, including blocktxn and
getblocktxn, are permitted between peers that have sent/received a disablet=
x
message, subject to the feature negotiation of BIP 152.

=3D=3DImplementation=3D=3D

TBD

=3D=3DReferences=3D=3D

# Bitcoin Core has [https://github.com/bitcoin/bitcoin/pull/15759 impl=
emented this functionality] since version 0.19.0.1, released in November 20=
19.
# For example, see https://www.cs.umd.edu/projects/coinscope/coi=
nscope.pdf and https://arxiv.org/pdf/1812.00942.pdf.

=3D=3DCopyright=3D=3D

This BIP is licensed under the 2-clause BSD license.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000ae39b105bc8ca229--