The PR branch HEAD was 3eef1e6 at the time of this review club meeting.
Notes
Motivation
Today’s PR 19845 is part of PR
19031, a proposed
implementation of the
BIP155addrv2 message.
addrv2 is a new p2p message format proposed in early 2019 by Wladimir J. van
der Laan to support networks that have longer endpoint addresses than fit in
the 128 bits/16 bytes of the current addr message.
This work is urgent because Tor v2 was deprecated yesterday (September 15,
2020) with 0.4.4.x and will be obsoleted in 0.4.6.x (July 15, 2021). Tor v2 is
expected to be completely disabled in Tor client stable versions on October
15, 2021 as announced
here: “From today (July
2nd, 2020), the Internet has around 16 months to migrate from onion services
v2 to v3 once and for all.”
Why is Tor v2 EOL? According to this Tor mailing list
post:
“To very quickly summarize why we are deprecating, in one word: Safety. Onion
service v2 uses RSA1024 and 80 bit SHA1 (truncated) addresses. It also still
uses the TAP handshake which has been entirely removed from Tor for many years
now except v2 services. Its simplistic directory system exposes it to a
variety of enumeration and location-prediction attacks that give HSDir relays
too much power to enumerate or even block v2 services. Finally, v2 services
are not being developed nor maintained anymore. Only the most severe security
issues are being addressed.”
Network address types newly recognized by PR 19845
Next-generation Tor v3 Onion
addresses -
“Better crypto (replaced SHA1/DH/RSA1024 with SHA3/ed25519/curve25519),
improved directory protocol leaking much less information to directory
servers, a smaller surface for targeted attacks, better onion address
security against impersonation, and a more extensible introduction/rendezvous
protocol.”
Invisible Internet Project (I2P) - “The I2P network
provides strong privacy protections for communication over the
Internet. Many activities that would risk your privacy on the public
Internet can be conducted anonymously inside I2P.”
Cjdns - “Cjdns implements an encrypted
IPv6 network using public-key cryptography for address allocation and a
distributed hash table for routing. This provides near-zero-configuration
networking, and prevents many of the security and scalability issues that
plague existing networks.”
With PR 19845, you can make peer connections to these network address types
by using the addnode RPC or the -addnode / -connect configuration
options. Here’s how:
For rumouring these address types, more is needed. For instance, PR
19954—the remaining step of 19031—enables running bitcoind as a Tor v3
service.
Technical Notes
Today’s PR 19845 adds the ability to serialize and deserialize internet
addresses in addrv2 format. It also adds Tor v3 address parsing and builds
on just-merged PR 19841,
“Implement Keccak and SHA3_256”. The latter is needed for Tor v3 support, as
the conversion from BIP155 encoding to .onion notation uses an SHA3-based
checksum.
The addrv2 feature is enabled by OR-ing an integer flag, ADDRV2_FORMAT
(code),
into the stream version.
The PR makes use of the custom Span type, which was introduced into Bitcoin
Core in PR 12886 and
represents a vector-like view to a range of contiguous elements in memory
analogous to std::span in C++20. If you are not familiar with Span, it was
discussed in a recent review club meeting.
Tor v3 address parsing should follow this
spec,
which is also summarized
here
in the BIP.
Questions
Warm-up question #1: Visually, how can you tell the difference between a Tor
v2 and v3 address?
Warm-up question #2: List all the network address types that Bitcoin Core
can support after this PR. What is the size in bytes (address length) for
each of them? What is the maximum address length Bitcoin Core will be able to
support?
Warm-up question #3: Is addrv2 deserialization faster or slower than v1? By
roughly how much?
Did you review the PR? Bonus: Did anyone also review PR
19841, “Implement Keccak and
SHA3_256”?
What steps did you take to review this PR? Did you review on GitHub, or in
your local dev environment? Did you review commit-by-commit, or the whole
diff? What did you review first: the code, the tests, or
BIP155?
Did you verify that the code corresponds to the spec for each network address
type? Any thoughts on the test coverage? Do you see anything that is not tested or
could also be tested?
When should the new sendaddrv2 message type, aka “send me addrv2”, be sent?
What does this implementation do if an unknown or non-validateable network
address type is encountered? How about a known network with wrong length? Are
these considered misbehavior? Discouraged? Not relayed? Ignored? Why?
What is meant by “variable-length addresses” in BIP155 and when referring to
addrv2?
How will the new address formats be saved in peers.dat, which currently
persists addresses in 16-byte IPv6 format?
Why was the boolean pad parameter added to EncodeBase32()?
How do you think Bitcoin Core should make the transition from Tor v2 to v3?
All at once, or v3 first opt-in, then default (and v2 opt-in or deprecated)?
In which releases?
<jonatack> Warm-up question #2: List all the network address types that Bitcoin Core can support after this PR. What is the size in bytes (address length) for each of them? hint: src/netaddress.h::95-114
<sipa> wiz: indeed, but on the other hand... if you're using tor you probably don't want to use DNS seeds (directly) in the first place (and bitcoin core doesn't)
<sipa> instead we ask an exit node to do the resolving, connect to one of the seed's results, send it a getaddr, and disconnect when the response comes back
<wumpus> urethane: they are not usable through Tor. You can do DNS lookups through Tor (through a SOCKS5 extension), in principle, but not the kind of query that returns multiple results.
<pinheadmz> sure bc theres no IPs in tor anyway really - but see what im getting at? could there be a bitcoin core tor directory that served bootstrapping nodes over tor?
<jonatack> pinheadmz: "directory" node... just to recap, irc there are 3 basic types of tor nodes: bridge/gate, relays and exit; often a tor node has more than one of those roles
<pinheadmz> thats how i like to review. but on github it only shows you the blbos that are different, i prefer to be able to scroll up and down the file (witihout clickthe expansion buttons)
<wumpus> jonatack: don't know why it's not precise enough; you can't quote say "before any other messages" because other BIPs might also introduce these kind of upgrade messages
<vasild> 907 started being a moving target, invalidating ACKs all the time, so I decided to not update it with the stuff from 967, also 907 contains mods which have been agreed on. While 967 has got zero discussion so far. I did not want to add some controversal stuff to the settled 907
<wumpus> as said, I had the impression that everything was in one PR, which tracked the new version of the BIP, which we'd merge when there was agreement on the implementation
<vasild> I guess the decode must be prepare to see non-multiple-of-8 input and pad it itself with = before decoding (once we start parsing i2p addresses)
<jonatack> BHow do you think Bitcoin Core should make the transition from Tor v2 to v3? All at once, or v3 first opt-in, then default (and v2 opt-in or deprecated)?
<wumpus> jonatack: there should be no reason why you'd not want v3 but want v2, but I can see a reason for keeping the v2 open for now, for older nodes
<vasild> michaelfolkson: hmm, given that tor relays through some random tor nodes, I don't know what will happen if you run an old tor node that insists on doing v2 stuff and newer ones have dropped support for it
<wumpus> in any case if you're still running those Tor versions by the time addrv2 is removed (and I suppose, the directories and such shut down), they won't be able to use hidden services at all I think
<vasild> sipa: my take on "gossip i2p in 0.21 is that, because only 22% run latest version, when we add i2p supprt in e.g. 0.22 then old nodes (0.21) will also gossip it
<vasild> sipa: "more worried about garbage in addrmans" currently for a node to be able to protect itself from this it must have connectivity to all 3: ip4, ip6 and tor, right?