Implement ADDRv2 support (part of BIP155) (
p2p) Jul 15, 2020
The PR branch HEAD was 2533ce0 at the time of this review club meeting.
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
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.
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
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
PR 19031 is a fairly large PR. For the purposes of this PR Review Club, here is a suggested approach for study and 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
Did you review the PR?
Concept ACK, approach ACK, tested ACK, or
You’re always encouraged to put your PR review on GitHub, even after it has
What are the differences between
addr and the new
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?
Do you agree with how
addrv2 support is being signaled? What are some alternatives?
Why is Tor v3 being considered?
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?
1 19:00 <troygiorshev> #startmeeting
11 19:00 <troygiorshev> welcome to review club everyone! today we'll be talking about implementing the addrv2 message
12 19:00 <michaelfolkson> hi
14 19:01 <troygiorshev> who's had a chance to review the pr? (y/n)
23 19:01 <michaelfolkson> y
25 19:02 <troygiorshev> great!
26 19:02 <troygiorshev> special thanks to vasild for being here :)
27 19:02 <ecurrencyhodler> Hallo
29 19:02 <troygiorshev> does anyone want to summarize 19360?
30 19:03 <michaelfolkson> Anyone here for the first time?
32 19:04 ⚡ dongcarl has review club set up on his calendar now
34 19:04 <michaelfolkson> Ok not what I meant :) So extending the existing P2P message type to allow for Tor v3 addresses etc
35 19: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
36 19:05 <tattered> limitations on size and address type are also addressed in the PR
37 19:05 <jnewbery> 19360 is allowing CService to be [de]serialized without accessing CNetAddr's protected members, specifically ip
38 19: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 :)
39 19:06 ⚡ tattered thumbs up
40 19:06 <troygiorshev> michaelfolkson: tattered: jnewbery: great!
41 19:07 <troygiorshev> we've just about covered this already, but on to the first question
42 19:07 <troygiorshev> What are the differences between addr and the new addrv2?
43 19:07 <ecurrencyhodler> Was there a reason why addr was restricted to 16 bytes only?
44 19:07 <michaelfolkson> Longer addresses, variable length addresses
45 19:08 <ecurrencyhodler> addr is restricted to 16 byte addresses. v2 address size is variable.
46 19:08 <sipa> ecurrencyhodler: it was restricted to IPv6 only
47 19:08 <sipa> ecurrencyhodler: which happens to be 16 bytes
48 19:08 <ecurrencyhodler> Was there a reason it was restricted to IPv6 only?
49 19:08 <sipa> and over time, everything just got hacked into a single IPv6 space
50 19:08 <sipa> ecurrencyhodler: ask satoshi :)
51 19:08 <michaelfolkson> Extensible too. So maybe we won't ever need addrv3?
52 19:09 <ecurrencyhodler> Thanks sipa.
53 19:09 <wumpus> I think because ipv6 seemed futuristic enough at the time, it was hard to imagine a network with larger addresses
54 19:09 <troygiorshev> ecurrencyhodler: michaelfolkson: exactly, note the addition of the NetworkID field
56 19: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
57 19:09 <wumpus> it's just that pubkey-based overlay networks need more
58 19:09 <tattered> ecurrencyhodler IIRC i2P was the only > 16 byte addressing at addr creation time -- but I may be wrong
59 19:10 <felixweis> the addresses get stored in peers.dat? does the file format allow for longer than 16 byte addresses?
60 19:10 <sipa> felixweis: no, it needs to change
61 19:11 <troygiorshev> felixweis: great observation!
62 19:11 <sipa> felixweis: and that's not really the right question
63 19: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 :)
64 19:12 <troygiorshev> ok next question
65 19: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?
66 19:12 <troygiorshev> there are no wrong answers :)
67 19:12 <dongcarl> there's a prelude to the larger commits in the PR
68 19:13 <wumpus> fwiw peers.dat also can't store anything *smaller* than 16 bytes, all IPv4 addresses are padded :)
69 19:13 <jnewbery> I like small PRs, as long as it's obvious that each PR is beneficial by itself
70 19: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
71 19:13 <felixweis> i think there is no general answer to this question. depends on the logical complexity of the PR.
72 19: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
73 19:14 <ecurrencyhodler> Having a large PR makes it more difficult to review and more likely less people will review it.
74 19:14 <troygiorshev> felixweis: agreed!
75 19: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
76 19:14 <michaelfolkson> And obviously not possible sometimes to break into smaller
77 19: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
78 19: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?
79 19:16 <wumpus> tattered: not really, the peers.dat format can change to support variable-length addresses just like the network protocol
80 19:16 <troygiorshev> great thoughts all around, it's important that we're deliberate when splitting things apart
81 19:16 <troygiorshev> Do you agree with how addrv2 support is being signaled? What are some alternatives?
82 19: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
83 19:17 <sipa> tattered: so for, "ip address" in bitcoin meant IPv6 address, and nothing else
84 19:17 <sipa> tattered: so everything, peers.dat, wire protocol, ... all just store IPv6 addresses
85 19:17 <sipa> which happen to be 16 bytes
87 19:18 <wumpus> i just mean, the peers.dat format is not an external interface, it can be changed any time
88 19: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.
89 19:18 <sipa> tattered: v2 hidden services are stored using the "onioncat" IPv6 range
90 19:18 <michaelfolkson> New message during handshake was chosen over alternatives of bumping protocol version and a new network service bit
91 19:18 <wumpus> michaelfolkson: +1
92 19:19 <ecurrencyhodler> Are changes in peers.dat included in this PR?
93 19:19 <troygiorshev> michaelfolkson: what do you think? is that what you would have picked?
94 19:19 <michaelfolkson> Although this does add complexity especially if message arrives after handshake
96 19:20 <michaelfolkson> I think it depends on how likely we'll need wider addresses in future?
97 19:21 <michaelfolkson> I don't really have any insight into that
98 19:21 <vasild> ecurrencyhodler: yes, the changes are in src/addrman.h
99 19: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
100 19:21 <wumpus> I don't think claiming a service bit for this makes sense, that's the only option I'd really disagree with
101 19: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
102 19:22 <troygiorshev> michaelfolkson: "...we'll need wider addresses..." do you mean new wider addresses that don't yet have a networkID assigned?
103 19:22 <michaelfolkson> Yup
104 19:22 <vasild> ecurrencyhodler: CAddrMan is what gets serialized into peers.dat
105 19: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
106 19:22 <ecurrencyhodler> ty
107 19:22 <michaelfolkson> The argument against bumping protocol version was strong and convincing
108 19: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
109 19:23 <michaelfolkson> Haven't decided between new network service bit and new message in my mind
110 19:23 <wumpus> michaelfolkson: yes, I don't think we'll bump the protocol version ever again
111 19:23 <wumpus> michaelfolkson: there's not really a sensible reason to require a certain combination of features
112 19:24 <dongcarl> vasild: I don't remember the conclusion to last discussion about -onlynet=torv3
113 19:24 <wumpus> only torv3 and I2P peers *really* care about this
114 19: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
115 19:24 <wumpus> IPv4 ones don't and don't need any threshold level to be forced to support it
116 19: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
117 19:25 <vasild> dongcarl: me neither
118 19: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?
119 19: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
120 19:27 <wumpus> jnewbery: in any case it's not a rquirement for addrv2
121 19: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)
122 19:27 <troygiorshev> what approach should we take if addrv2 needs to be expanded to inlude new networkIDs? should we plan for this now?
123 19:27 <wumpus> vasild: nice!
124 19:27 <wumpus> troygiorshev: it's mentioned in the BIP: this would need a new BIP per address type
125 19: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.
126 19: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?
127 19:28 <wumpus> troygiorshev: peers are not requried to store or forward unknown address types, but they should accept them (and may ignore them)
128 19:29 <wumpus> troygiorshev: to allow for forward compatibility they should NOT disconnect or ban on receiving unknown address types
129 19:30 <wumpus> there's no need to signal this to peers
130 19:30 <wumpus> either you accept them, or you throw them away, the peer doesn't care
131 19:30 <troygiorshev> wumpus: ah you're right! thanks!
133 19: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)
134 19:32 <michaelfolkson> And you only care about the one you are connected on right? You don't need to know the alternatives?
135 19: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
136 19:33 <vasild> some bogus data to his peers and may get banned.
137 19: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
138 19:33 <michaelfolkson> Maybe you are "multi-homed" and have a preference that isn't the one you are currently connected on?
139 19:34 <wumpus> yes, it's important to distinguish not being connected to a network and not knowing about a network here
140 19:34 <sipa> so the rules need to be clear that an invalid length known-type network should just be ignored
141 19:34 <sipa> and should not be treated as misbehavior
142 19:34 <wumpus> you can forward, say, I2P addresses if you know their format but are not on I2P
143 19:34 <sipa> and should not result in dropping the entire addrv2 message, just the one entry
144 19:34 <wumpus> but if there's an *unknown* network ID, which you don't know the formwat of, please ignore it
145 19:34 <vasild> sipa: ah!
146 19: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?
147 19:35 <wumpus> you don't know what should be the length or format etc
148 19:35 <wumpus> it could be total injected garbage
149 19:35 <vasild> sipa: I would say the other way around - don't forward something you can't validate :)
150 19: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
151 19:35 <sipa> vasild: yes, but that's not the point i'm making
152 19:35 <sipa> vasild: you should ignore things you can't validate, but you should NOT ignore the entire addrv2 message it's in
153 19:36 <sipa> or it could lead to a censorship attack on upgraded nodes
154 19:36 <wumpus> yes, banning or disconnected on invalid addresses is not described in the BIP at all
155 19:36 <sipa> vasild: even when you *know* they're invalid
156 19: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
157 19:36 <sipa> (and not just unknown)
158 19:37 <sipa> vasild: does that make sense?
159 19: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
160 19: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.
161 19: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
162 19:38 <sipa> vasild: that is wrong
163 19:38 <wumpus> there's a maximum allowed address length (512 byts) above which the entire addrv2 message is invalid
164 19:38 <sipa> a known-network with wrong length should equally be ignored
165 19:38 <fjahr> Is that not a DOS vector if we can send an addrv2 full of garbage and not get penalized for it?
166 19:39 <sipa> fjahr: you can send garbage any way you like
167 19:39 <wumpus> as this is not specific per network ID, it can't be used as a backward compatibility attack
168 19:39 <vasild> sipa: why? what sense does it make to receive IPv4 address with length 5?
169 19:39 <jnewbery> sipa: even if it's one of the 6 network types in the initial BIP?
170 19:39 <wumpus> fjahr: you can do the same for addr messages already
171 19:39 <sipa> vasild: read gmaxwell's comment, he explained the attack
172 19:39 <sipa> vasild: it's not about IPv4; it's about future networks that may be defined
173 19: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)
174 19:40 <vasild> sipa: but that is resolved by not forwarding unknown networks, no?
175 19:40 <sipa> vasild: no
178 19:40 ⚡ michaelfolkson waiting with anticipation
179 19:41 <wumpus> tattered: how do you define a 'decrease in network topology'?
180 19: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
181 19:42 <vasild> yes, the code does the former and the BIP will get some rewording
182 19:42 <vasild> ... to match the code
183 19:42 <jnewbery> yes, as long as we don't ever change validity rules for known network types
184 19: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
185 19:43 <felixweis> can't cross network type gossiping be used to identity relationships between a nodes on onion and clearnet announcements?
186 19:43 ⚡ troygiorshev thinks back to last week's PR review club
187 19:44 <sipa> felixweis: maybe... but hopefully the entire network is connected
188 19:44 <wumpus> felixweis: I don't think so, if nodes gossip other nodes' gossip, there doesn't need to be a direct connection
189 19:44 <wumpus> ah yes if not tne entire network is connected
190 19:45 <troygiorshev> please continue this conversation, just want to throw the next question into the mix
191 19:45 <troygiorshev> Why is Tor v3 being considered?
192 19:45 <instagibbs> troygiorshev, vs?
193 19:45 <troygiorshev> instagibbs: not upgrading to it :)
194 19:45 <wumpus> tor v3 hidden services have better security and privacy than v2
195 19:46 <dongcarl> v2 is being deprecated too
196 19: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
197 19:46 <felixweis> v2 is broken if facebook can have facebookcorewwwi.onion
198 19:46 <wumpus> a lot of work has been put into it by the Tor team
200 19:46 <troygiorshev> dongcarl: i was hoping someone had seen this!
201 19: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
202 19:46 <wumpus> (I don't have the link on hand, but they have an entire document describing the advantages of v3)
203 19: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)
206 19:47 <troygiorshev> (exactly one year today!)
207 19:47 <dongcarl> Right, this is why we should try to get a working,tested addrv2 in a release soon
208 19:47 <wumpus> tattered: I think that's a valid concern, it shouldn't becomew worse than with the current gossip system
209 19:47 <instagibbs> TIL dongcarl
211 19:48 <wumpus> yes TIL that v2 addresses are being deprecated
212 19:48 <tattered> wumpus ok, that's what I was wondering - is it marginal lower than presently. ty
213 19:48 <dongcarl> We should also discuss -onlynet bootstrapping at some point, if time permits
214 19:48 <wumpus> tattered: address gossip is really slow and lossy compared to transaction relay, this will not change
215 19:49 <dongcarl> I feel like I've visited this topic a few times, but never had the right people in the same place
216 19:49 <wumpus> dongcarl: you mean bootstrapping using hardcoded seeds is not enough?
217 19:49 <instagibbs> just connect to blockstream.info's v3 onion, Done.
218 19:50 <jnewbery> sipa: relaying to only one peer means that the address won't propogate very far in the network I imagine
219 19:50 <wumpus> dongcarl: this tended to work for me in the past, FWIW
220 19: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?
221 19:51 <tattered> torv2 addresses don't have the privacy level most people believe is present
222 19:51 <dongcarl> wumpus: You're saying in the next release, we'll include hardcoded v3 seeds which run nodes with addrv2 support?
223 19: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"...)
224 19:51 <dongcarl> s/which run nodes/which point to nodes/
225 19:52 <wumpus> dongcarl: we should, probably
226 19:52 <troygiorshev> tattered: great point, the improved crypto in v3 will help this
227 19: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
228 19:53 <wumpus> dongcarl: only a few (reliable) seed nodes would be enough
229 19:53 <wumpus> even if it's, say, only my node and instagibbs's :-)
230 19:53 <tattered> aka we should view supporting torv3 as not a "nice to have" but making node privacy more robust
231 19: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?
232 19:55 <troygiorshev> 5 minutes left!
233 19: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
234 19:55 <dongcarl> sipa: Is this guaranteed in the addr relay behaviour currently?
235 19:55 <wumpus> troygiorshev: my idea was that everything currently existing is compatible with addrv2 (I also asked around on twitter and such)
236 19:55 <wumpus> troygiorshev: this is one reason the absolute maximum length was increased to 512 bytes per address instead of 32
237 19:55 <sipa> dongcarl: define "guaranteed" ?)
238 19:56 <michaelfolkson> I had to look up what Cjdns was
239 19:56 <vasild> We will never need addrv3! (famous last words)
240 19: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
241 19:56 <wumpus> no one knows for sure of course
242 19:57 <wumpus> maybe quantumnet needs addresses that can't even be represented in classical bits :PPP
243 19:57 <troygiorshev> wumpus: haha
244 19:57 <sipa> wumpus: ooooh!
245 19: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?
247 19:57 <sipa> dongcarl: since torv3 support does not exist current, i don't know what you're asking about
248 19:58 <wumpus> troygiorshev: is this a new overlay network, or mesh network?
249 19:58 <tattered> wumpus lool
250 19:58 <vasild> well, torv2 and torv3 relaying will be the same, so I guess s/torv3/torv2/ in dongcarl's question
251 19: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
252 19:59 <troygiorshev> (bitcoin's p2p interface more modular)
253 19: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
254 20:00 <tattered> troygiorshev I think making p2p more modular is super cool! and critical for robustness :]]
255 20:00 <troygiorshev> that's time!
256 20:00 <troygiorshev> Thanks everyone!
257 20:00 <wumpus> thanks troygiorshev
258 20:00 <jnewbery> Thanks Troy!
259 20:00 <troygiorshev> And thanks especially to vasild for being here
261 20:00 <fodediop> Thank you!
262 20:00 <nehan> thanks troygiorshev!
263 20:00 <tattered> ty troygiorshev wumpus vasild
264 20:00 <vasild> troygiorshev: thanks for hosting!
265 20:01 <amiti> thanks troy! I learned a lot
266 20:01 <michaelfolkson> Nice work troygiorshev
267 20:01 <sipa> thanks troygiorshev !
268 20:01 <dongcarl> thanks!
270 20: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.
271 20:02 <troygiorshev> #endmeeting
273 20: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