Adding a blocksonly option to addnode

ArmchairCryptologist commented at 2:42 pm on December 13, 2021: none

If a node is configured to only use Tor (onlynet=onion), it can be helpful to connect to one or more additional trusted IPv4/IPv6 nodes to ensure connectivity and provide hardening against eclipse attacks. However, if you do this today with addnode, all transactions created and relayed by your onion node will also be relayed to the trusted node over a plaintext connection, which of course is a potential privacy leak.

As far as I can tell, there is currently no way to make Bitcoin Core treat a specific node added with addnode as “blocksonly”. Adding this as an option would seemingly be a simple way to fix this problem.

While it would be possible to resolve this in other ways, say by adding a proxy node configured as blocksonly between the onion node and the trusted node which would relay blocks but no transactions, this both adds complexity and reduces the reliability of the setup by adding another point of failure. You could of course configure your trusted node to use Tor as well and use its onion address for addnode, but this would still cause the setup to fail if there are connectivity issues with Tor itself, say due to government censorship.

ArmchairCryptologist added the label Feature on Dec 13, 2021

bitcoin deleted a comment on Dec 13, 2021

jonatack commented at 6:03 pm on January 27, 2022: contributor

An easier way to ensure connectivity and eclipse resistance could be to run the node on both Tor and I2P (and CJDNS on current master and the upcoming v23 release), and use addnode to connect to peers from each of these networks.

jonatack commented at 6:05 pm on January 27, 2022: contributor

See doc/i2p.md for more info.

mzumsande commented at 11:02 pm on April 13, 2022: contributor

I implemented this in #24170. It does add some complexity to the networking code (another connection type that combines the properties of manual connections and block-relay-only connections) and the addnode RPC code, so I’d be interested in opinions whether the use case is strong enough.

www222fff commented at 2:27 am on April 28, 2022: none

@mzumsande Hi, just found you already checking out this issue in #24170. I want to know why code not merged and are you still ongoing this issue?

Right now already checkout this issue and drafting code, if you are still on going, please let me known so that suspend from my side.

fanquake commented at 8:18 am on April 28, 2022: member

I want to know why code not merged and are you still ongoing this issue?

PRs need to be reviewed before merge. That can take time. There is no rush. Given that the PR is still open, and review feedback is being addressed, I can’t see any reason to think @mzumsande is not still working on this change.

www222fff referenced this in commit 36d9686e3b on Apr 28, 2022

www222fff commented at 9:06 am on April 28, 2022: none

Seems https://github.com/NYDIG/bitcoin-task-bounty not updated. Already updated to avoid confliction furthur. @fanquake I also think @mzumsande should be still ongoing.

mzumsande commented at 9:07 am on April 28, 2022: contributor

Yes, I am still working on this. “Checking out” issues is not really a thing in bitcoin core, you just start working and open a PR. @www222fff you are probably referring to https://nydig.com/bounties (which is not officially related to bitcoin core) - I started working on this issue and opened the PR several weeks before that program was announced. I did notice the bounty from there, but I’m still a bit undecided whether I like the incentives of that (getting things merged), especially in light of conceptual questions such as #23763 (comment), so I hadn’t checked anything out there (cc @jamesob).

www222fff commented at 9:16 am on April 28, 2022: none

@mzumsande Understood, https://nydig.com/bounties makes me confused, please go on.

vasild commented at 4:25 am on May 7, 2022: contributor

What you actually want here is to avoid tx traffic over clearnet (IPv4 or IPv6). So, this is more about connection type and less about manual connections with -addnode.

What about limiting p2p traffic per connection type, using similar syntax like #24170’s -addnode=ipaddr=manual-blocks-only, but instead of -addnode hook that into -onlynet? For example: -onlynet=onion -onlynet=ipv4=blocks would connect automatically to IPv4 nodes but would only do “blocks” traffic with them. In the case with -addnode one would loose IPv4 connectivity if that particular node goes down.

Something like -onlynet=network=addr,blocks,tx so that one can use e.g. -onlynet=onion=addr,tx -onlynet=ipv4=blocks.

Does that make sense?

mzumsande commented at 8:12 pm on May 8, 2022: contributor

What you actually want here is to avoid tx traffic over clearnet (IPv4 or IPv6).

I think it’s less about reducing traffic, and more about avoiding the negative effects (privacy of own transactions, fingerprinting vectors etc.) that come with both tx and addr relay. But in addition to that, we also want to ensure hearing about new blocks over clearnet.

If we chose automatic connections for this, it would probably hard to ensure that. We probably wouldn’t want to sacrifice one of the 8 tx-relaying full outbound connections for this, so only the automatic 2 block-relay-only connections would be eligible. But then we’d need to make sure that these are actually filled by clearnet peers, and not by onion peers too. Also it would be harder to actually get good clearnet address into addrman if we only exchange addresses with onion nodes. With -addnode, we could specify up to 8 additional peers (that would be low-bandwidth) if we want to avoid the risk of one going offline.

jonatack commented at 5:49 am on May 9, 2022: contributor

If a node is configured to only use Tor (onlynet=onion), it can be helpful to connect to one or more additional trusted IPv4/IPv6 nodes to ensure connectivity and provide hardening against eclipse attacks. However, if you do this today with addnode, all transactions created and relayed by your onion node will also be relayed to the trusted node over a plaintext connection

See #24545 (BIP324) that covers the general case for this.

vasild commented at 2:28 pm on May 9, 2022: contributor

@mzumsande, yes, this is what I meant - to avoid tx traffic over clearnet because it is privacy-sensitive, not because of the volume of the traffic. Obviously, this is only concerning to somebody who runs a wallet and emits their own transactions from that node.

For the 8-automatic outbound connections, I guess, in a setup like -onlynet=onion -onlynet=ipv4=blocks, when opening an automatic full connection we would have to open it only to onion peers. For inbound connections over ipv4 we would have to be shy and not send tx traffic to the peer, or maybe not send own transactions to the peer, relaying foreign transactions should be fine wrt privacy.

Actually -addnode 1.2.3.4=blocks does not interfere or contradict with -onlynet=ipv4=blocks. We can have both features if desired. That is - filter blocks/addr/tx traffic based on specific manually added node or for automatic connections, based on network type.

vasild commented at 6:37 am on May 11, 2022: contributor

@sipa, what do you think about filtering p2p traffic based on network type, in addition to per-manual connection (addnode)? #23763 (comment)

willcl-ark commented at 3:17 pm on April 10, 2024: contributor

The feature request didn’t seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

If someone is interested in this feature they could pick up https://github.com/bitcoin/bitcoin/issues/24170

willcl-ark closed this on Apr 10, 2024

Adding a blocksonly option to addnode #23763