Implement ADDRv2 support (part of BIP155) (p2p)

https://github.com/bitcoin/bitcoin/pulls/19031

Host: troygiorshev  -  PR author: vasild

The PR branch HEAD was 2533ce0 at the time of this review club meeting.

Notes

  • PR 19031 is a proposed implementation of the BIP155 addrv2 message, a new p2p message format proposed in early 2019 by Wladimir J. van der Laan to gossip longer node addresses. The addrv2 message is required to support next-generation Tor v3 Onion addresses, the Invisible Internet Project (I2P), and potentially other networks that have longer endpoint addresses than fit in the 128 bits/16 bytes of the current addr message.

  • To ease review, PR 19031 was converted to a roadmap and separated into a series of smaller PRs. The first one in the series, PR 19351 “test: add an edge case test for CSubNet”, has been merged. PR 19360 “net: improve encapsulation of CNetAddr” is the second PR in the series and currently under review.

  • The addr message relays connection information, including IP addresses, for peers on the Bitcoin network. addr uses IPv6 addresses; IPv4 addresses are provided as IPv4-mapped IPv6 addresses. More information here.

  • The BIP155 addrv2 message would allow not only longer addresses, but also variable-length ones for future extensibility.

  • Bitcoin supports Tor v2, whose addresses are 10 characters long. Once encoded to the 16-byte onioncat space, they fit nicely in the 16 bytes needed for an IPv6 address. Tor v3 (meta issue here), aka Next Gen Onion Services, has been available since 2017. Tor v3 provides much better security and privacy using longer, 56-character addresses. Using Tor v3 on the Bitcoin network therefore requires implementation of addrv2.

  • PR 19031 is a fairly large PR. For the purposes of this PR Review Club, here is a suggested approach for study and review:

    • Review PR 19360 (this is also the first commit of PR 19031).
    • Read BIP155. There is ongoing discussion on BIP155 happening at BIPs PR 907. Because of this, please review BIP155 at any of the links in these notes as they reflect the current status of the BIP.
    • See this comment in BIPs PR 907 about how to signal support for addrv2. The current decision can be seen here.
    • Read through all of the conceptual comments in 19031.
    • Skim commits 2-4 of PR 19031. The goal should be to get context for what future PRs will cover and to see how the implementation of BIP155 matches the specification.

Questions

  1. Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? You’re always encouraged to put your PR review on GitHub, even after it has been merged.

  2. What are the differences between addr and the new addrv2?

  3. Do you agree with how PR 19031 is being split up into smaller PRs? Would you rather the “reviewable” PRs be larger and include more commits? What are the advantages and disadvantages of this choice?

  4. Do you agree with how addrv2 support is being signaled? What are some alternatives?

  5. Why is Tor v3 being considered?

  6. What are some other protocols that could be added here? Are they all compatible with addrv2, or will we need an addrv3 in the future?

Meeting Log

  119:00 <troygiorshev> #startmeeting
  219:00 <troygiorshev> hi
  319:00 <jnewbery> hi!
  419:00 <tattered> hi
  519:00 <fodediop> hi
  619:00 <felixweis> hi
  719:00 <emzy> hi
  819:00 <fjahr> hi
  919:00 <sipa> hi
 1019:00 <vasild> hi
 1119:00 <troygiorshev> welcome to review club everyone! today we'll be talking about implementing the addrv2 message
 1219:00 <michaelfolkson> hi
 1319:00 <troygiorshev> notes and questions in the usual spot: https://bitcoincore.reviews/19031.html
 1419:01 <troygiorshev> who's had a chance to review the pr? (y/n)
 1519:01 <tattered> y
 1619:01 <emzy> n
 1719:01 <fodediop> n
 1819:01 <felixweis> y
 1919:01 <jnewbery> y
 2019:01 <vasild> y :-D
 2119:01 <amiti> hi
 2219:01 <wumpus> hi
 2319:01 <michaelfolkson> y
 2419:02 <dongcarl> hi
 2519:02 <troygiorshev> great!
 2619:02 <troygiorshev> special thanks to vasild for being here :)
 2719:02 <ecurrencyhodler> Hallo
 2819:02 <nehan> hi
 2919:02 <troygiorshev> does anyone want to summarize 19360?
 3019:03 <michaelfolkson> Anyone here for the first time?
 3119:03 <dongcarl> me
 3219:04 ⚡ dongcarl has review club set up on his calendar now
 3319:04 <wumpus> y
 3419:04 <michaelfolkson> Ok not what I meant :) So extending the existing P2P message type to allow for Tor v3 addresses etc
 3519:04 <tattered> addr currently only supports 16 byte addresses which limit which endpoints nodes can connect to expanding addrv2 to 32 bytes enables tor v3 addresses and I2P plus yet-reserved addresses
 3619:05 <tattered> limitations on size and address type are also addressed in the PR
 3719:05 <jnewbery> 19360 is allowing CService to be [de]serialized without accessing CNetAddr's protected members, specifically ip
 3819:06 <vasild> tattered: right, notice that in addrv2 the address size is variable, so it can be 32 for torv3, or 363 for some-fancy-network, or just 4 for IPv4 :)
 3919:06 ⚡ tattered thumbs up
 4019:06 <troygiorshev> michaelfolkson: tattered: jnewbery: great!
 4119:07 <troygiorshev> we've just about covered this already, but on to the first question
 4219:07 <troygiorshev> What are the differences between addr and the new addrv2?
 4319:07 <ecurrencyhodler> Was there a reason why addr was restricted to 16 bytes only?
 4419:07 <michaelfolkson> Longer addresses, variable length addresses
 4519:08 <ecurrencyhodler> addr is restricted to 16 byte addresses. v2 address size is variable.
 4619:08 <sipa> ecurrencyhodler: it was restricted to IPv6 only
 4719:08 <sipa> ecurrencyhodler: which happens to be 16 bytes
 4819:08 <ecurrencyhodler> Was there a reason it was restricted to IPv6 only?
 4919:08 <sipa> and over time, everything just got hacked into a single IPv6 space
 5019:08 <sipa> ecurrencyhodler: ask satoshi :)
 5119:08 <michaelfolkson> Extensible too. So maybe we won't ever need addrv3?
 5219:09 <ecurrencyhodler> Thanks sipa.
 5319:09 <wumpus> I think because ipv6 seemed futuristic enough at the time, it was hard to imagine a network with larger addresses
 5419:09 <troygiorshev> ecurrencyhodler: michaelfolkson: exactly, note the addition of the NetworkID field
 5519:09 <vasild> addr looks like this: https://github.com/bitcoin/bitcoin/blob/cb85af83bb3476323367b480e48ce729714db996/src/test/netbase_tests.cpp#L464-L468, and addrv2 looks like this: https://github.com/bitcoin/bitcoin/blob/cb85af83bb3476323367b480e48ce729714db996/src/test/netbase_tests.cpp#L480-L485
 5619:09 <sipa> i'd say the biggest change in addrv2 is that it creates separate address spaces for separate networks... which implies also variable length
 5719:09 <wumpus> it's just that pubkey-based overlay networks need more
 5819:09 <tattered> ecurrencyhodler IIRC i2P was the only > 16 byte addressing at addr creation time -- but I may be wrong
 5919:10 <felixweis> the addresses get stored in peers.dat? does the file format allow for longer than 16 byte addresses?
 6019:10 <sipa> felixweis: no, it needs to change
 6119:11 <troygiorshev> felixweis: great observation!
 6219:11 <sipa> felixweis: and that's not really the right question
 6319:11 <sipa> the question is "does peers.dat permit storing anything else than IPv6 addresses", and the answer is no, because that's what addresses were in bitcoinland up to now :)
 6419:12 <troygiorshev> ok next question
 6519:12 <troygiorshev> Do you agree with how PR 19031 is being split up into smaller PRs? Would you rather the “reviewable” PRs be larger and include more commits? What are the advantages and disadvantages of this choice?
 6619:12 <troygiorshev> there are no wrong answers :)
 6719:12 <dongcarl> there's a prelude to the larger commits in the PR
 6819:13 <wumpus> fwiw peers.dat also can't store anything *smaller* than 16 bytes, all IPv4 addresses are padded :)
 6919:13 <jnewbery> I like small PRs, as long as it's obvious that each PR is beneficial by itself
 7019:13 <sipa> tattered: i believe so; i tried adding I2P support in 2012, but gave up due to it being very hard/impossible to pack into some ipv6 address space
 7119:13 <felixweis> i think there is no general answer to this question. depends on the logical complexity of the PR.
 7219:14 <dongcarl> the prelude commits might not be accepted on their own as pure-refactors, but does stand in this case given that they simplify later commits in the PR
 7319:14 <ecurrencyhodler> Having a large PR makes it more difficult to review and more likely less people will review it.
 7419:14 <troygiorshev> felixweis: agreed!
 7519:14 <michaelfolkson> Personally I like the smaller PRs approach and it works better for PR review clubs. I think Gleb's argument was that there should be cleaner mapping between a BIP and a PR
 7619:14 <michaelfolkson> And obviously not possible sometimes to break into smaller
 7719:15 <jnewbery> although it's getting better, we have a codebase organization that means PRs very often conflict. The larger the PR, the more often you need to rebase, which is painful for authors and reviewers
 7819:15 <tattered> sipa wumpus is it the case that peers.dat only stored ipv6 or that 16 bytes was the cap. meaing v2 onions are padded too in peers.dat, correct?
 7919:16 <wumpus> tattered: not really, the peers.dat format can change to support variable-length addresses just like the network protocol
 8019:16 <troygiorshev> great thoughts all around, it's important that we're deliberate when splitting things apart
 8119:16 <troygiorshev> Do you agree with how addrv2 support is being signaled? What are some alternatives?
 8219:17 <wumpus> tattered: it should be backward compatible (e.g. new code can still read old peers.dat files), there is no requirement to be compatible the other way around
 8319:17 <sipa> tattered: so for, "ip address" in bitcoin meant IPv6 address, and nothing else
 8419:17 <sipa> tattered: so everything, peers.dat, wire protocol, ... all just store IPv6 addresses
 8519:17 <sipa> which happen to be 16 bytes
 8619:18 <tattered> ty
 8719:18 <wumpus> i just mean, the peers.dat format is not an external interface, it can be changed any time
 8819:18 <vasild> tattered: the serialization code is the same, no matter whether the address is going to the disk or being sent over the network. In the current serialization we represent IPv4 and Torv2 addresses in 16 bytes, encoded as a "fake" IPv6 addresses from some reserved IPv6 networks.
 8919:18 <sipa> tattered: v2 hidden services are stored using the "onioncat" IPv6 range
 9019:18 <michaelfolkson> New message during handshake was chosen over alternatives of bumping protocol version and a new network service bit
 9119:18 <wumpus> michaelfolkson: +1
 9219:19 <ecurrencyhodler> Are changes in peers.dat included in this PR?
 9319:19 <troygiorshev> michaelfolkson: what do you think? is that what you would have picked?
 9419:19 <michaelfolkson> Although this does add complexity especially if message arrives after handshake
 9519:20 <dongcarl> ecurrencyhodler: yup https://github.com/bitcoin/bitcoin/pull/19031/commits/826e17b547a42d1359687a08b8701131c8aca365
 9619:20 <michaelfolkson> I think it depends on how likely we'll need wider addresses in future?
 9719:21 <michaelfolkson> I don't really have any insight into that
 9819:21 <vasild> ecurrencyhodler: yes, the changes are in src/addrman.h
 9919:21 <wumpus> I picked a protocol version bump first, because I saw it as a protocol update, but a lot of people disagreed with this, but I'm okay with signalling it with a message
10019:21 <wumpus> I don't think claiming a service bit for this makes sense, that's the only option I'd really disagree with
10119:21 <jnewbery> the latest BIP says that the sendaddrv2 message should be sent after the verack. That means there's a window between receiving the verack and sending the sendaddrv2 message where the peer will send you addr messages
10219:22 <troygiorshev> michaelfolkson: "...we'll need wider addresses..." do you mean new wider addresses that don't yet have a networkID assigned?
10319:22 <michaelfolkson> Yup
10419:22 <vasild> ecurrencyhodler: CAddrMan is what gets serialized into peers.dat
10519:22 <wumpus> there is only a limited number of version bits and they're generally used to find peers supporting a certain feature, which is not really relevant here
10619:22 <ecurrencyhodler> ty
10719:22 <michaelfolkson> The argument against bumping protocol version was strong and convincing
10819:22 <dongcarl> michaelfolkson: the bip can be extended to allow for wider addresses, addresses with unknown networkIDs are currently ignored, but there's a sanity check for an absurdly large address
10919:23 <michaelfolkson> Haven't decided between new network service bit and new message in my mind
11019:23 <wumpus> michaelfolkson: yes, I don't think we'll bump the protocol version ever again
11119:23 <wumpus> michaelfolkson: there's not really a sensible reason to require a certain combination of features
11219:24 <dongcarl> vasild: I don't remember the conclusion to last discussion about -onlynet=torv3
11319:24 <wumpus> only torv3 and I2P peers *really* care about this
11419:24 <jnewbery> I think it'd be great if the version message could be extended to include requested/supported features rather than have a new message type for every feature
11519:24 <wumpus> IPv4 ones don't and don't need any threshold level to be forced to support it
11619:25 <sipa> michaelfolkson: i don't think a service bit makes sense; the way to advertize you're listening on some other network... is by sending out addrv2 messages for your IP on that network; it doesn't need some flag to announce it
11719:25 <vasild> dongcarl: me neither
11819:26 <michaelfolkson> One of the arguments for new network service bit was SPV clients could find addrv2 nodes by service bit. But you're saying sipa that that would be obvious anyway?
11919:26 <wumpus> jnewbery: yes, something that uses named extensions instead of needint to allocate a limited number of extension bits would be nice, some things have been proposed in the past IIRC
12019:27 <wumpus> jnewbery: in any case it's not a rquirement for addrv2
12119:27 <vasild> fwiw the current implementation will also work if the sendaddrv2 message (which means "I support addrv2, please send me in that format") arrives in the middle of the communication (not necessary the first message after verack)
12219:27 <troygiorshev> what approach should we take if addrv2 needs to be expanded to inlude new networkIDs? should we plan for this now?
12319:27 <wumpus> vasild: nice!
12419:27 <wumpus> troygiorshev: it's mentioned in the BIP: this would need a new BIP per address type
12519:28 <vasild> we just flip a peer's flag "this guy supports addrv2" and later when we send to him, if that flag is on, then we use addrv2.
12619:28 <troygiorshev> wumpus: agreed, absolutely a new BIP. I mean to ask, how should we signal to peers that we're able to work with the new networkID?
12719:28 <wumpus> troygiorshev: peers are not requried to store or forward unknown address types, but they should accept them (and may ignore them)
12819:29 <wumpus> troygiorshev: to allow for forward compatibility they should NOT disconnect or ban on receiving unknown address types
12919:30 <wumpus> there's no need to signal this to peers
13019:30 <wumpus> either you accept them, or you throw them away, the peer doesn't care
13119:30 <troygiorshev> wumpus: ah you're right! thanks!
13219:30 <michaelfolkson> The arguments for and against the signaling methods were here for the log: https://github.com/bitcoin/bips/pull/907#issuecomment-611924492
13319:31 <wumpus> (though *if* you're connected using a certain method, say, I2P, you can implicitly assume the peer will accept addressses for that network)
13419:32 <michaelfolkson> And you only care about the one you are connected on right? You don't need to know the alternatives?
13519:33 <vasild> gmaxwell made an interesting observation at https://github.com/bitcoin/bips/pull/907 -- if a peer forwards (gossips) a network he does not know about (e.g. networkid=0x07, some obscure data with length=123), then that could be a problem if the node which does the forwarding is old and network 0x07 has actually been added with required length!=123. Then that old node will happen to forward
13619:33 <vasild> some bogus data to his peers and may get banned.
13719:33 <wumpus> I think that's true in general, though, it's not forbidden either to gossip addresses for networks you're not connected to
13819:33 <michaelfolkson> Maybe you are "multi-homed" and have a preference that isn't the one you are currently connected on?
13919:34 <wumpus> yes, it's important to distinguish not being connected to a network and not knowing about a network here
14019:34 <sipa> so the rules need to be clear that an invalid length known-type network should just be ignored
14119:34 <sipa> and should not be treated as misbehavior
14219:34 <wumpus> you can forward, say, I2P addresses if you know their format but are not on I2P
14319:34 <sipa> and should not result in dropping the entire addrv2 message, just the one entry
14419:34 <wumpus> but if there's an *unknown* network ID, which you don't know the formwat of, please ignore it
14519:34 <vasild> sipa: ah!
14619:35 <tattered> michaelfolkson "only care about the one you are connected on" is that right? Why wouldn't a node want to keep the most comprehensive peer list available?
14719:35 <wumpus> you don't know what should be the length or format etc
14819:35 <wumpus> it could be total injected garbage
14919:35 <vasild> sipa: I would say the other way around - don't forward something you can't validate :)
15019:35 <jnewbery> vasild: right, if there are new restrictions on message validity, we shouldn't ban/disconnect if those restrictions are violated, otherwise we end up banning old peers, and may split the network
15119:35 <sipa> vasild: yes, but that's not the point i'm making
15219:35 <sipa> vasild: you should ignore things you can't validate, but you should NOT ignore the entire addrv2 message it's in
15319:36 <sipa> or it could lead to a censorship attack on upgraded nodes
15419:36 <wumpus> yes, banning or disconnected on invalid addresses is not described in the BIP at all
15519:36 <sipa> vasild: even when you *know* they're invalid
15619:36 <michaelfolkson> tattered: I would guess it depends on your preference. If you only use Tor v3 and aren't interested in any of the alternatives? Others would be interested in alternatives I'd guess
15719:36 <sipa> (and not just unknown)
15819:37 <sipa> vasild: does that make sense?
15919:37 <jnewbery> one interesting thing here is that we gossip addresses without doing any validation of them, unlike transactions and blocks, which we'll only relay if we've validated them
16019:38 <vasild> yes, this is how the implementation works - it consumes an unknown network id messages and silently ignores them. But if it receives a known-network with wrong length then that is treated as misbehavior - the entire message is dropped (with all addresses) and maybe the peer banned.
16119:38 <michaelfolkson> tattered: But then this is an argument for not using message during handshake and using new network service bit instead? I didn't understand sipa's earlier point
16219:38 <sipa> vasild: that is wrong
16319:38 <wumpus> there's a maximum allowed address length (512 byts) above which the entire addrv2 message is invalid
16419:38 <sipa> a known-network with wrong length should equally be ignored
16519:38 <fjahr> Is that not a DOS vector if we can send an addrv2 full of garbage and not get penalized for it?
16619:39 <sipa> fjahr: you can send garbage any way you like
16719:39 <wumpus> as this is not specific per network ID, it can't be used as a backward compatibility attack
16819:39 <vasild> sipa: why? what sense does it make to receive IPv4 address with length 5?
16919:39 <jnewbery> sipa: even if it's one of the 6 network types in the initial BIP?
17019:39 <wumpus> fjahr: you can do the same for addr messages already
17119:39 <sipa> vasild: read gmaxwell's comment, he explained the attack
17219:39 <sipa> vasild: it's not about IPv4; it's about future networks that may be defined
17319:40 <tattered> Does the fact that networkid, and length being unspecified have any marginal decrease in network topology akin to txn relay topology? ( I guess we care more about txn-origination privacy more than peer topology)
17419:40 <vasild> sipa: but that is resolved by not forwarding unknown networks, no?
17519:40 <sipa> vasild: no
17619:40 <sipa> oh
17719:40 <sipa> wait!
17819:40 ⚡ michaelfolkson waiting with anticipation
17919:41 <wumpus> tattered: how do you define a 'decrease in network topology'?
18019:41 <sipa> i think that's right; either you don't relay unknown networks, or you don't punish for invalid known networks... either one is enough
18119:42 <vasild> yes, the code does the former and the BIP will get some rewording
18219:42 <vasild> ... to match the code
18319:42 <jnewbery> yes, as long as we don't ever change validity rules for known network types
18419:43 <sipa> i'm still a bit hesitant to treat known-but-invalid addr entries as misbehavior; i agree there is no transitive partition risk if unknown types don't get relayed... but it's still scary
18519:43 <felixweis> can't cross network type gossiping be used to identity relationships between a nodes on onion and clearnet announcements?
18619:43 ⚡ troygiorshev thinks back to last week's PR review club
18719:44 <sipa> felixweis: maybe... but hopefully the entire network is connected
18819:44 <wumpus> felixweis: I don't think so, if nodes gossip other nodes' gossip, there doesn't need to be a direct connection
18919:44 <wumpus> ah yes if not tne entire network is connected
19019:45 <troygiorshev> please continue this conversation, just want to throw the next question into the mix
19119:45 <troygiorshev> Why is Tor v3 being considered?
19219:45 <instagibbs> troygiorshev, vs?
19319:45 <troygiorshev> instagibbs: not upgrading to it :)
19419:45 <wumpus> tor v3 hidden services have better security and privacy than v2
19519:46 <dongcarl> v2 is being deprecated too
19619:46 <sipa> jnewbery: btw, perhaps the current code even relays not-our-network addresses too little (it relays them to 1 peer instead of 2), as it seems very hard to learn about onion addresses today if you're only connected to ipv4/ipv6
19719:46 <felixweis> v2 is broken if facebook can have facebookcorewwwi.onion
19819:46 <wumpus> a lot of work has been put into it by the Tor team
19919:46 <instagibbs> https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions
20019:46 <troygiorshev> dongcarl: i was hoping someone had seen this!
20119:46 <tattered> wumpus Sorry I didn't elaborate properly. "decrease in network-topology *privacy*" meaning if a Eve wants to discover more of peer topology she injects a tag into an unspecified peer netid and address and observes where that tag is relayed by other peers. Though it seems if peers strongly drop netid and lengths they don't know about, this topology won't leak out as easily
20219:46 <wumpus> (I don't have the link on hand, but they have an entire document describing the advantages of v3)
20319:46 <dongcarl> According to the tor-dev mailing list, Tor plans to deprecate v2 with 0.4.4.x (Sept. 15th, 2020) and obsolete it in 0.4.6.x (July 15th, 2021)
20419:46 <troygiorshev> the schedule is here https://blog.torproject.org/v2-deprecation-timeline
20519:47 <dongcarl> More details here: https://lists.torproject.org/pipermail/tor-dev/2020-June/014365.html
20619:47 <troygiorshev> (exactly one year today!)
20719:47 <dongcarl> Right, this is why we should try to get a working,tested addrv2 in a release soon
20819:47 <wumpus> tattered: I think that's a valid concern, it shouldn't becomew worse than with the current gossip system
20919:47 <instagibbs> TIL dongcarl
21019:47 <michaelfolkson> And this was shared on the PR review club page: https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions
21119:48 <wumpus> yes TIL that v2 addresses are being deprecated
21219:48 <tattered> wumpus ok, that's what I was wondering - is it marginal lower than presently. ty
21319:48 <dongcarl> We should also discuss -onlynet bootstrapping at some point, if time permits
21419:48 <wumpus> tattered: address gossip is really slow and lossy compared to transaction relay, this will not change
21519:49 <dongcarl> I feel like I've visited this topic a few times, but never had the right people in the same place
21619:49 <wumpus> dongcarl: you mean bootstrapping using hardcoded seeds is not enough?
21719:49 <instagibbs> just connect to blockstream.info's v3 onion, Done.
21819:50 <jnewbery> sipa: relaying to only one peer means that the address won't propogate very far in the network I imagine
21919:50 <wumpus> dongcarl: this tended to work for me in the past, FWIW
22019:50 <vasild> sipa: there is no strong reason to ban/misbehave a peer who sends us known-network, invalid length address. Other that he sent us something that does not make sense (e.g. IPv4 address with length 5). Maybe make distinction in networks 0x01..0x06 (as currently defined in BIP155) and networks 0x07.. (future ones) - ban on invalid len 1..6 networks and ignore/drop the address on 7.. networks?
22119:51 <tattered> torv2 addresses don't have the privacy level most people believe is present
22219:51 <dongcarl> wumpus: You're saying in the next release, we'll include hardcoded v3 seeds which run nodes with addrv2 support?
22319:51 <sipa> vasild: possibly; the alternative would mean that numbers 1-6 can be reused too if networkid space gets too crowded (who knows, maybe someone one day finds a use for "set top bit in network id to mean X"...)
22419:51 <dongcarl> s/which run nodes/which point to nodes/
22519:52 <wumpus> dongcarl: we should, probably
22619:52 <troygiorshev> tattered: great point, the improved crypto in v3 will help this
22719:53 <tattered> torv3 fixes some tenuous privacy centralization in that's present in torv2 service infrastructure -- meaning bitcoin nodes running tor v3 addressing cant be deanonymized as easily
22819:53 <wumpus> dongcarl: only a few (reliable) seed nodes would be enough
22919:53 <wumpus> even if it's, say, only my node and instagibbs's :-)
23019:53 <tattered> aka we should view supporting torv3 as not a "nice to have" but making node privacy more robust
23119:55 <troygiorshev> last question, What are some other protocols that could be added here? Are they all compatible with addrv2, or will we need an addrv3 in the future?
23219:55 <troygiorshev> 5 minutes left!
23319:55 <dongcarl> wumpus: Right... I guess once 2 nodes (other than the seeds) connect to the seeds, the seeds will connect them through addr relay
23419:55 <dongcarl> sipa: Is this guaranteed in the addr relay behaviour currently?
23519:55 <wumpus> troygiorshev: my idea was that everything currently existing is compatible with addrv2 (I also asked around on twitter and such)
23619:55 <wumpus> troygiorshev: this is one reason the absolute maximum length was increased to 512 bytes per address instead of 32
23719:55 <sipa> dongcarl: define "guaranteed" ?)
23819:56 <michaelfolkson> I had to look up what Cjdns was
23919:56 <vasild> We will never need addrv3! (famous last words)
24019:56 <troygiorshev> wumpus: i may or may not be using this question as an excuse to plug AltNet and discuss networks that don't bind well to sockets, etc. :D
24119:56 <wumpus> no one knows for sure of course
24219:57 <wumpus> maybe quantumnet needs addresses that can't even be represented in classical bits :PPP
24319:57 <troygiorshev> wumpus: haha
24419:57 <sipa> wumpus: ooooh!
24519:57 <dongcarl> sipa: Is there any case where 2 torv3 nodes both connect to a third torv3 node, and the third one doesn't tell the 2 initiators about each other?
24619:57 <troygiorshev> anyways, if you found this PR interesting, you'll probably also find ariard's AltNet proposal interesting! You can find it here: https://github.com/bitcoin/bitcoin/pull/18988
24719:57 <sipa> dongcarl: since torv3 support does not exist current, i don't know what you're asking about
24819:58 <wumpus> troygiorshev: is this a new overlay network, or mesh network?
24919:58 <tattered> wumpus lool
25019:58 <vasild> well, torv2 and torv3 relaying will be the same, so I guess s/torv3/torv2/ in dongcarl's question
25119:59 <troygiorshev> wumpus: it's an attempt to make bitcoin's p2p more modular, such that anyone can write "drivers" for their network that can easily be "plugged" into
25219:59 <troygiorshev> (bitcoin's p2p interface more modular)
25319:59 <wumpus> the only requirement that addrv2 makes is that addresses an be stored in 512 bytes of data, nothing more, even variable-length "route descriptions" would work (if they fit in that length), unless your network is so postmodern that addresses can't be desrcibed at all, I don't see what would be unsuppore
25420:00 <tattered> troygiorshev I think making p2p more modular is super cool! and critical for robustness :]]
25520:00 <troygiorshev> that's time!
25620:00 <troygiorshev> Thanks everyone!
25720:00 <wumpus> thanks troygiorshev
25820:00 <jnewbery> Thanks Troy!
25920:00 <troygiorshev> And thanks especially to vasild for being here
26020:00 <felixweis> ty
26120:00 <fodediop> Thank you!
26220:00 <nehan> thanks troygiorshev!
26320:00 <tattered> ty troygiorshev wumpus vasild
26420:00 <vasild> troygiorshev: thanks for hosting!
26520:01 <amiti> thanks troy! I learned a lot
26620:01 <michaelfolkson> Nice work troygiorshev
26720:01 <sipa> thanks troygiorshev !
26820:01 <dongcarl> thanks!
26920:01 <fjahr> ty
27020:02 <vasild> dongcarl: "Is there any case where 2 torv2 nodes both connect to a third torv2 node, and the third one doesn't tell the 2 initiators about each other?" -- yes, I think that is possible, but I have to look at the code to confirm.
27120:02 <troygiorshev> #endmeeting
27220:03 <emzy> ty
27320:03 <wumpus> so I guess protocols with relative addressing ("this is the list of transit sequences for routing decisions from me to you") would not work with this, but gossip in general only works for global address spaces