From: Amiti Uttarwar <amiti@uttarwar•org>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Proposed Improvements To addr Relay
Date: Wed, 14 Apr 2021 20:59:35 +0000 [thread overview]
Message-ID: <BD7C4E40-5304-4BD8-B2AC-6F72FF37AAB8@uttarwar.org> (raw)
Hi all,
I’m proposing a change to addr relay in Bitcoin Core with the intention of reducing “addr blackholes”. At the current stage, I am most interested in understanding whether this change would have negative consequences for other software on the network.
Exposure to a diverse set of addresses is important for nodes to be protected against network partitions or eclipse attacks. Ensuring addr messages propagate well is fundamental to the success of the network. In the Bitcoin p2p protocol, there are two main ways for nodes to communicate about addresses: addr gossip and getaddr requests.
Bitcoin Core will respond to a maximum of one getaddr message for each inbound peer. Thus, the main ongoing method for updating which addresses a node knows about is through addr gossip. Self-advertisements initiate a new addr message to each peer approximately once a day. When a Bitcoin Core node receives an addr message that contains 10 or fewer addresses, it will forward them to 1-2 peers. Forwarding addresses to peers who will not relay them further effectively “blackholes” the message, reducing the ability for the addr message to successfully propagate through the network.
Although we cannot prevent addr blackholes in malicious cases, we can improve it for the more common honest cases, and reduce the overall likelihood of occurrence. Two known instances in which an honest peer would not participate in addr relay are 1. If they have opened a block-relay-only connection or 2. If they are a light client. The current blackhole behavior with block-relay-only connections is acceptable since Bitcoin Core nodes have a maximum of 2 outbound block-relay-only connections. However, improving this behavior is a prerequisite to increasing that number.
My proposal for Bitcoin Core is to identify whether or not an inbound connection is a candidate for forwarding addrs based on whether it has sent an addr related message (addr, addrv2, getaddr, sendaddrv2) over the connection. The code for this proposal can be found here: https://github.com/bitcoin/bitcoin/pull/21528. This would allow nodes to avoid sending addresses to honest connections which never intended to participate in address relay on the link.
This proposed change in behavior could be problematic if there is software on the network that is relying on receiving addr messages, but never initiates an addr related message. (This could be easily remedied by updating the software to send a getaddr to its outbound connections.) If anyone is aware of software with this behavior, could you please point me towards it? This would be very helpful to identify if #21528 is a viable approach.
Thank you,
Amiti
reply other threads:[~2021-04-14 20:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BD7C4E40-5304-4BD8-B2AC-6F72FF37AAB8@uttarwar.org \
--to=amiti@uttarwar$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox