Merge bitcoin#15759: p2p: Add 2 outbound block-relay-only connections#4862
Merged
PastaPastaPasta merged 15 commits intodashpay:developfrom Jun 19, 2022
Merged
Merge bitcoin#15759: p2p: Add 2 outbound block-relay-only connections#4862PastaPastaPasta merged 15 commits intodashpay:developfrom
PastaPastaPasta merged 15 commits intodashpay:developfrom
Conversation
Transaction relay is primarily optimized for balancing redundancy/robustness with bandwidth minimization -- as a result transaction relay leaks information that adversaries can use to infer the network topology. Network topology is better kept private for (at least) two reasons: (a) Knowledge of the network graph can make it easier to find the source IP of a given transaction. (b) Knowledge of the network graph could be used to split a target node or nodes from the honest network (eg by knowing which peers to attack in order to achieve a network split). We can eliminate the risks of (b) by separating block relay from transaction relay; inferring network connectivity from the relay of blocks/block headers is much more expensive for an adversary. After this commit, bitcoind will make 2 additional outbound connections that are only used for block relay. (In the future, we might consider rotating our transaction-relay peers to help limit the effects of (a).)
We don't want relay of addr messages to leak information about these network links.
If we set fRelay=false in our VERSION message, and a peer sends an INV or TX message anyway, disconnect. Since we use fRelay=false to minimize bandwidth, we should not tolerate remaining connected to a peer violating the protocol.
It's made to avoid possible typos with arguments, because some of them have default values and it's very high probability to make a mistake here.
…factor] Move tx relay state to separate structure`
|
This pull request has conflicts, please rebase. |
PastaPastaPasta
changed the title
PastaPastaPasta
approved these changes
Jun 19, 2022
Member
PastaPastaPasta
left a comment
PastaPastaPasta
left a comment
There was a problem hiding this comment.
utACK for squash merge
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
All commits there are actually a backport bitcoin#15759 but provided not squashed because it's easier to merge them one-by-one: changes are too big.
Before merge should be all squash except may be 94c99e0
Please, help to decide if need to have spare bloom filter for
vInventoryOtherToSendbecausefilterInventoryKnowncan't be used anymore for relay-only peers. Related merge request in past is #2292commit 189c19e
Merge: b5a8d0c 0ba0802
Author: fanquake [email protected]
Date: Sat Sep 7 17:24:05 2019 +0800