The PR branch HEAD was 629a6f4 at the time of this review club meeting.
Notes
Using Bitcoin Core on privacy networks such as Tor is good for enhancing the privacy of
own transactions and not revealing identity in general. However, Tor-only mode
is not without risks: Tor-only nodes may be susceptible to eclipse
attacks, man-in-the-middle attacks and other types of attacks
(see e.g. Biryukov, Pustogarov: Bitcoin over Tor isn’t a good idea (2015)).
To counter these downsides, some node operators might want to mainly be on a
privacy network, but still have a few manually picked clearnet peers that help
them stay on the best chain.
Currently, this would lead to transactions and addresses being relayed over
these connections and would also open up the
possibility of fingerprinting attacks, e.g. connecting a node’s onion address
to its clearnet IP.
Manual connections are additional outbound connections handpicked by the
node operator. They are regarded as trusted, so that a misbehaving manual
peer is not punished or disconnected in certain situations where an automatic
peer would be.
After Issue #23763 was
opened requesting this, PR
#24170 introduces the option of
specifying manual connections that are block-relay-only, i.e. don’t
participate in transaction or address relay.
Why could peers that are only active on privacy networks such as Tor be more
susceptible to eclipse attacks compared to clearnet-only peers?
What is the difference between the onetry and add modes in the addnode RPC?
What are the different options of adding a manual-block-relay peer that this PR
introduces? Did you try one out?
The PR introduces a new connection
typeMANUAL_BLOCK_RELAY that combines the
properties of MANUAL and BLOCK_RELAY peers. What are the advantages and
disadvantages of having an extra connection type, as opposed to combining the
logic of the existing ones?
BIP324, encrypted p2p traffic, is another privacy-enhancing
feature currently under development and review. What types of attacks that this PR
tries to mitigate are fixed by BIP324? Which ones aren’t?
<larryruane> I can't think that I would actually use it, because for one thing, I don't know what node IP I would add ... but I would think power users would find this useful
<larryruane> I did have one quick question related to it being optional ... If a node is running Tor-enabled, would it be a good idea to automatically make one of the outbound block-relay-only nodes non-tor
<lightlike> larryruane: that would be another option. however, it might not be what people expect who specify "onlynet=tor" (and maybe don't care that much about eclipse attacks)
<vnprc> lightlike: I like to run multiple nodes and bridge the various networks. I am definitely interested in this feature for improved privacy between these nodes.
<lightlike> schmidty: I'm not sure about the state of bitcoin on additional privacy networks such as I2P or Tor. They seem to have a rather small userbase so far.
<larryruane> at a very general level, I've noticed it's difficult for us to know how many users would use a new feature, or after it's released, how many are using it ... as compared to traditional corporate closed-source software (that i'm more used to), where the company has a customer list that they can just poll
<lightlike> also, I think that there may be some inherent weaknesses that privacy network share as opposed to clearnet - which brings us to the first question:
<lightlike> Why could peers that are only active on privacy networks such as Tor be more susceptible to eclipse attacks compared to clearnet-only peers?
<larryruane> lightlike: With clearnet, a node can choose peers that it knows are "far apart" based on their IP addresses. With tor, we have no idea where our peers are, they could all be colocated and belong to an attacker.
<lightlike> larryruane: yes, exactly. The connection making logic is based on the fact that we can establish some sort of "variety" by choosing peers from different netgroups. Onion addresses don't have that.
<stickies-v> I also read that it seems quite trivial to make a node blacklist non-attacker exit nodes, so that with sufficient iterations only/mostly attacker exit nodes remain - is that understanding correct?
<larryruane> yeah I'm running a RPi mynode, and have tor enabled ... (I tried to have tor enabled during IBD but it was super slow, so turned it off until it synced)
<stickies-v> lightlike would you agree that if the 2015 paper attack vector is not applicable anymore, the eclipse attack vector for tor-only connections seems quite limited, since it doesn't allow for a *targeted* attack?
<larryruane> lightlike: the mynode that I'm running is tor-only, but to test this PR, I added a manual block-relay-only, and it's clearnet (not tor), so the PR is working! (I'm running the PR branch on the RPi mynode)
<lightlike> Right. It's a bit strange that "addnode" is both a RPC and a command line arg, because you can't just add additional parameters to it and need to do some string parsing instead...
<lightlike> On the other hand, the startup option is probably more important than the RPC, because people might want to have a fixed list of manually added peers in their bitcoin.conf
<lightlike> Next question: The PR introduces a new connection type MANUAL_BLOCK_RELAY that combines the properties of MANUAL and BLOCK_RELAY peers. What are the advantages and disadvantages of having an extra connection type, as opposed to combining the logic of the existing ones?
<larryruane> I think an advantage of having a type, instead of just a bool (to enable block-relay) is that having a type makes it more extensible, in case we want to add more manual connection types in the future
<lightlike> yashraj: Yes, that's correct. But that could have been coded in as well, without extending the ConnectionType Enum, just by combining the features of the existing MANUAL and BLOCK RELAY connection types.
<lightlike> My reason was that this makes the code easier to read and argue about. The "flattened" enum of connection types was introduced in https://github.com/bitcoin/bitcoin/pull/19316 , which simplified the logic a lot (it was really convoluted before, if I remember correctly).
<lightlike> I think one downside is that if we decide to combine more connection types over time, this enum could become too long (there are many combinatorial possibilities, even if most don't make sense).
<sipa> I think the underlying theory behind that enum is exactly that we expect that newly added features in the connection logic will not result in combinatorial explosions in it.
<stickies-v> I think John summarizes the essence of the problem quite well in #19316: "I think we definitely don't want a bitmask of different connection capabilities. That leads to an combinatorial explosion of connection types that you need to either test or explicitly disallow."
<larryruane> I think flatter is better in general! even if (I guess this is the disadvantage) you have to test for (for example) `MANUAL` _or_ `MANUAL_BLOCK_RELAY` in many places ... but you can hide that in a single function (which I think you did)
<lightlike> BIP324, encrypted p2p traffic, is another privacy-enhancing feature currently under development and review. What types of attacks that this PR tries to mitigate are fixed by BIP324? Which ones aren’t?
<larryruane> just so I'm clear, the alternative would have been to _not_ add `MANUAL_BLOCK_RELAY` but instead store a "block-relay" boolean with the connection object (which is only meaningful if the type is `MANUAL`?
<lightlike> larryruane: yes, something like this was my first idea. But it seemed to go against the spirit of the #19316 refactoring, so I decided against it.
<vnprc> I'm not very familiar with BIP324 but it looks like it might prevent an attacker from eavesdropping on ADDR messages, which can be used to draw a P2P connection graph. ADDR messages are not relayed over block-relay-only connections so this mitigation would be redundant over an encrypted block-relay-only connection.
<sipa> also just to make sure this isn't misunderstood: the advantage of encryption as such is very limited, as attackers can just spin up their own nodes
<lightlike> While manual nodes are "trusted" I think that even if I trust a node not to DOS me or withhold blocks, I may still don't want them to send my transactions over clearnet.
<larryruane> sipa: so I understand... with BIP324, an attacker who watches the traffic in and out of a node doesn't know what's being sent and received, but if the attacker connects to that node as a normal peer, then he gets a pretty good idea
<sipa> right exactly; bip324 is opportunistic encryption with whomever you're connected to, preventing others from reading the traffic. It doesn't (by itself) have any means of ascertaining that who you're talking is (a) who you intend to talk to or (b) is honest