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 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.


I don't think this is good practice ecosystem-wise. To understand tx-relay
opt-out from peers correctly, a _non_ Bitcoin Core client has to implement
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 messages
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 brief
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 for
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 on
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 might
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 à 16:07, John Newbery via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> 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=false 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 >= 70011. In PR 7708[8] (merged in March 2016) this
>   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=false` 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=false`, 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=true 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/e49117470b77fb7d53be122c6490ba163c6e304d/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/018347.html
> [13] https://github.com/jnewbery/bitcoin/tree/2021-02-lazy-init-peer
> [14]
> https://github.com/bitcoin/bitcoin/blob/e52ce9f2b312b3cf3b0837918e07d7603e241d63/src/net_processing.cpp#L1696-L1700
> [15] https://github.com/bitcoin/bitcoin/pull/15759#issuecomment-527012757
>
> > 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 adding
> a network message that communicates that transactions will not be relayed
> 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 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 peers
> 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 that this
> message is valid for peers advertising protocol version 70017 or higher.
> Software is free to implement this BIP or ignore this message and remain
> compatible with software that does implement it.
> >
> > Full text of the proposed BIP is below.
> >
> > Thanks,
> > Suhas
> >
> > ---------------------------------------------------
> >
> > <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>
> >
> > ==Abstract==
> >
> > 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.
> >
> > ==Motivation==
> >
> > 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 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 ignore
> 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 on a
> > connection, this BIP suggests that address messages not be sent on links
> where
> > tx-relay has been disabled.
> >
> > ==Specification==
> >
> > # A new disabletx message is added, which is defined as an empty message
> where pchCommand == "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 >= 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).
> >
> > ==Compatibility==
> >
> > Nodes with protocol version >= 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 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
> 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.
> >
> > ==Implementation==
> >
> > TBD
> >
> > ==References==
> >
> > # 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.
> >
> > ==Copyright==
> >
> > 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 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 adding a network
>> message that communicates that transactions will not be relayed 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 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 peers
>> 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 that this
>> message is valid for peers advertising protocol version 70017 or higher.
>> Software is free to implement this BIP or ignore this message and remain
>> compatible with software that does implement it.
>>
>> Full text of the proposed BIP is below.
>>
>> Thanks,
>> Suhas
>>
>> ---------------------------------------------------
>>
>> <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>
>>
>> ==Abstract==
>>
>> 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.
>>
>> ==Motivation==
>>
>> 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 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 ignore 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 on a
>> connection, this BIP suggests that address messages not be sent on links where
>> tx-relay has been disabled.
>>
>> ==Specification==
>>
>> # A new disabletx message is added, which is defined as an empty message where pchCommand == "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 >= 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).
>>
>> ==Compatibility==
>>
>> Nodes with protocol version >= 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 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 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.
>>
>> ==Implementation==
>>
>> TBD
>>
>> ==References==
>>
>> # 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.
>>
>> ==Copyright==
>>
>> 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
>