Refactoring and minor improvement for self-advertisements (p2p)

Host: amitiuttarwar  -  PR author: naumenkogs

The PR branch HEAD was 25e674e at the time of this review club meeting.


  • The Bitcoin network uses addr messages to communicate addresses (the locations of nodes). To read more about the P2P message, you can see these docs.

  • Sometimes, we send our own address to our peers so it can be propagated to new nodes on the network. It can be hard to get new peers if nobody knows about you :)

  • Keep in mind that connections are asymmetric. We distinguish between inbound and outbound peers based on who initiated the connection. Think about what that entails for address discovery. If Node A initiates a connection to Node B, do they both necessarily know each others addresses?

  • There are two code paths for checking & potentially relaying our address:

    1. When we are processing the version message from a new connection,

    2. When we are starting the SendMessages loop for a peer.

  • Prior to this PR, these two code paths had similar but slightly different logic for advertising their addresses. This PR unifies the logical flows, which also entails some slight behavioral changes. Reviewing this PR requires understanding those differences to ensure they are safe. In some cases, we might have multiple addresses we can use to refer to ourselves. We’ll dig into why that is during review club!


  1. Why do we advertise our own address? Is this necessary? When?

  2. How often do we advertise our address? Why is this on a Poisson timer? Does this frequency make sense?

  3. Why might we have multiple addresses for ourselves? Where do they come from?

  4. What are the behavioral changes in this PR?

  5. When you PushAddress, will this necessarily send an addr P2P message?

  6. When you relay an addr out to a peer, what does the receiving peer do with the message? What would you anticipate occurring on the network as a whole?

Meeting Log

  119:00 <amiti> #startmeeting
  219:00 <spiral_> hello
  319:00 <willcl_ark> hi
  419:00 <elle> hi!
  519:00 <pinheadmz> hi
  619:00 <emzy> hi
  719:00 <stacie> hi
  819:00 <amiti> hi everyone!
  919:00 <felixweis> hi
 1019:00 <nehan> hi
 1119:00 <robot-dreams> hi
 1219:00 <gloriazhao> hi!
 1319:00 <lightlike> hi
 1419:00 <@jnewbery> hi!
 1519:00 <amiti> anyone here for the first time?
 1619:01 <ajonas> hi
 1719:01 <dhruvm> hi
 1819:01 <Murch> Hai
 1919:01 <amiti> welcome all :)
 2019:02 <sipa> hi
 2119:02 <amiti> this week, we’ll be chatting about ✨ addr relay ✨
 2219:02 <pinheadmz> hooray! thats a great kind of relay!
 2319:02 <amiti> propagating node addresses is crucial for nodes find one another to open connections. I find this a really interesting area of the p2p network, and one that I’m just starting to learn about. So just want to be clear that I’m not an expert & I might not have all the answers, but I’ve been digging in and I’m excited to have this sesh to learn together!
 2419:02 <sipa> about time that we *address* this issue
 2519:02 <amiti> 😂
 2619:02 ⚡ spiral_ ba dum tsh
 2719:02 <felixweis> announce all the peers!
 2819:03 <amiti> let's get started!
 2919:03 <@jnewbery> are you relay going to make that joke, sipa?
 3019:03 <amiti> who's had the chance to look at the PR? y/n
 3119:03 <Murch> y
 3219:03 <robot-dreams> y
 3319:03 <spiral_> y
 3419:03 <felixweis> y
 3519:03 <elle> y
 3619:03 <@jnewbery> y
 3719:03 <stacie> y
 3819:03 <willcl_ark> y
 3919:03 <emzy> y
 4019:03 <nehan> n
 4119:03 <lightlike> y
 4219:03 <amiti> ( but to be clear, these puns are great. keep em coming )
 4319:04 <amiti> wow nice! lots of review
 4419:04 <Murch> peering over the verge :)
 4519:04 <amiti> ok, so lets start with the fundamentals- why do we advertise our own address?
 4619:04 <Murch> Cuz we want more friends :'(
 4719:05 <stacie> because outbound peers do not necessarily have your address, and like Murch said, you want more friends :)
 4819:05 <willcl_ark> We want to get new inbound connections and populate addrman
 4919:05 <dhruvm> So we can have incoming connections which can help us discover transactions and blocks faster
 5019:05 <emzy> So that others know us.
 5119:05 <spiral_> announce a concrete location to the network where we can be located
 5219:05 <gloriazhao> do we do it even if inbounds aren't enabled?
 5319:05 <amiti> yup! exactly. its to make sure other nodes know how to find us
 5419:05 <Murch> gloriazhao: Excellent question.
 5519:06 <gloriazhao> thank u very murch
 5619:06 <amiti> anybody know the answer to gloriazhao's question?
 5719:06 <Murch> No, but I'm curious as well ^^
 5819:06 <dhruvm> @gloriazhao: i know that addr gossip continues even in -connect mode without -listen
 5919:06 <pinheadmz> instinct is no
 6019:06 <robot-dreams> I think we don't if inbounds aren't enabled or if we're in IDB?
 6119:07 <dhruvm> but i do not know if we will advertise ourselves without -listen
 6219:07 <robot-dreams> (though I'm not sure if I'm interpreting the `fListen` condition correctly)
 6319:07 <Murch> dhruvm: But `-connect` only regulates outbound, right?
 6419:07 <@jnewbery> the gloval fListen is relevant here
 6519:07 <@jnewbery> *global
 6619:07 <jrawsthorne> hi
 6719:07 <amiti> hi! welcome
 6819:08 <jrawsthorne> Thanks amiti
 6919:08 <willcl_ark> Looks like we don't, if -listen is disabled?
 7019:08 <amiti> yeah, I believe `fListen` indicates if the node should accept connections from the outside, and is checked when we are deciding whether to attempt self advertisement
 7119:08 <dhruvm> Murch: yes. with -connect, without -listen, there's no point to growing addrman for ourselves but we still make getaddr calls to the -connect peer
 7219:08 <lightlike> I don't understand completely why this way of advertising was chosen, considering that our peer knows our address already - wouldn't it work as well if a given node regularly sends the address of some of its peers to other peers?
 7319:09 <sipa> lightlike: not if we connected out to them
 7419:09 <amiti> great question lightlike!
 7519:09 <@jnewbery> (fListen is checked for self-advertisement before and after this PR)
 7619:09 <robot-dreams> Related to lightlike's question: do we include our own address in the `version` message when initiating an outbound connection? Alternatively, is that address available to the receiver due to some lower-level network details (e.g. in the TCP header, which I don't know the details of)?
 7719:09 <dhruvm> lightlike: even if they know our address, nodes only share 23% of their addrman with their peers
 7819:09 <pinheadmz> robot-dreams its not in the version message
 7919:10 <pinheadmz> but we can send an ADDR message right after handshake
 8019:10 <sipa> jnewbery: you knew i had to make that joke if nobody else did
 8119:10 <felixweis> dhruvm: don't advertise all the peers!
 8219:10 <spiral_> addr documentation:
 8319:11 <amiti> ok, so to dig in- what address information is contained in the version message?
 8419:11 <@jnewbery> dhruvm: that 23% is specifically for getaddr responses. The other way of sharing addresses is through gossiping them periodically, which isn't affected by the 23% constant
 8519:11 <pinheadmz> amiti robot-dreams my bad! there is an address in there
 8619:11 <dhruvm> @jnewbery: I see.
 8719:11 <sipa> jnewbery: the period gossip is only for new addresses; it's not from addrman at all
 8819:11 <sipa> afaik?
 8919:12 <@jnewbery> sipa: correct
 9019:12 <amiti> ok, so there's two concepts being discussed here: 1. do outbound connections know our address? 2. what is the difference between GETADDR and other ADDR relay?
 9119:13 <pinheadmz> amiti there is a net_addr for both sender and receiver in version
 9219:13 <amiti> lets start with #2, because its essentially been answered. can someone summarize the difference between these two methods for sharing addresses?
 9319:13 <@jnewbery> sipa: oops, yes. What I said was confusing.
 9419:13 <amiti> pinheadmz: yup :)
 9519:13 <Murch> Re 1.: sipa seems to indicate above that they might not, but if it's in the VER message, that would seem incorrect?
 9619:13 <dhruvm> @jnewbery: sipa: Does that mean addr relay is unaffected by the 23% constraint? But getaddr is. If so, out node must initiate the addr, else there's a small chance it's never talked about.
 9719:13 <sipa> CAddress addrMe = CAddress(CService(), nLocalNodeServices);
 9819:13 <sipa> connman.PushMessage(&pnode, CNetMsgMaker(INIT_PROTO_VERSION).Make(NetMsgType::VERSION, PROTOCOL_VERSION, (uint64_t)nLocalNodeServices, nTime, addrYou, addrMe,
 9919:13 <Murch> Or is the joke that we could lie?
10019:13 <sipa> nonce, strSubVersion, nNodeStartingHeight, ::g_relay_txes && pnode.m_tx_relay != nullptr));
10119:14 <sipa> ^ i believe the "our address" in the version message is a dummy these days
10219:15 <felixweis> so during handshake we learn about our own IP
10319:15 <amiti> sipa: wait, what? so you're saying the version message has fields for "my address" and "your address", but the first is a dummy, so really we're just sending over "your address"?
10419:15 <willcl_ark> I also came across this issue during my research, which i thought was interesting:
10519:15 <lightlike> but no matter what we put in the version message - shouldn't our outbound peer have some idea of what our address is, considering it communicates with us via p2p?
10619:16 <pinheadmz> lightlike could be wrong but i think thats kinda handled by the OS- like the handle for the tcp connection
10719:16 <sipa> amiti: indeed
10819:16 <pinheadmz> you might see localAddr in getpeerinfo
10919:16 <sipa> amiti: let me find the change that did that, it's ancient
11019:16 <robot-dreams> amiti: if we receive a `getaddr`, we respond immediately with an `addr`; there's also a separate loop that sends an `addr` on average every 30 seconds
11119:16 <amiti> sipa: oh wow, interesting.
11219:17 <Murch> willcl_ark: looks very relevant.
11319:17 <willcl_ark> Each bitcoind (presumably) just sees "new connection from (local) port xxxx". It's only "sure" of addresses for outbound connections it makes?
11419:17 <amiti> robot-dreams: def yes to getaddr/addr response. didn't realize that we send out an addr every ~30 seconds. where is that ?
11519:17 <sipa> amiti: PR 8740
11619:17 <willcl_ark> Murch: the older linked issue too (#3088) also had some additional context
11719:18 <robot-dreams> amiti: I'm looking at `AVG_ADDRESS_BROADCAST_INTERVAL`
11819:18 <amiti> robot-dreams, sipa: thanks! looks like I'll have lots more to dig into after this session :)
11919:19 <sipa> in any case, the "my address" function is fullfilled by just sending out addr messages for our own IP
12019:19 <felixweis> external IP resolution services were the main way to get the IP to announce in the IRC channels?
12119:19 <gloriazhao> I find it interesting that we don't respond to getaddrs from outbounds (if i'm reading this correctly)
12219:20 <willcl_ark> Seems like sometimes an outbound might have a better idea of our address than we do ourselves
12319:20 <felixweis> willcl_ark: almost always at least for anything that uses NAT
12419:20 <willcl_ark> no wait, inbounds ...
12519:20 ⚡ spiral_ fantasizes about all these address-discovery challenges going away with onion addressing
12619:20 <willcl_ark> yeah
12719:21 <amiti> but lets keep moving forward. the aspect I wanted to highlight was whether or not advertising our own address is actually necessary. since the peer must have some info about our address whether they are outbound or inbound, seems like there's a possibility of an alternate announcement method. I've thought about tradeoffs of each, maybe we can loop back to this question and dig in more if we have time
12819:21 <amiti> so- how often do we advertise our address?
12919:21 <emzy> willcl_ark: Also IPv6 fixes this :)
13019:21 <Murch> gloriazhao: As in, if my node's outbound peer asks me for my address, I don't tell him? Could be a privacy protection.
13119:21 <robot-dreams> sipa: If the `addr_from` field of version isn't used, how do we discover "peer's view of our address, which might be more useful than our own view"?
13219:21 <Murch> gloriazhao: To prevent outbound peers from eclipse attacking easily
13319:21 <willcl_ark> emzy: hooray! Now if only my ISP would move forward with it...
13419:22 <sipa> // This asymmetric behavior for inbound and outbound connections was introduced
13519:22 <sipa> // to prevent a fingerprinting attack: an attacker can send specific fake addresses
13619:22 <sipa> // to users' AddrMan and later request them by sending getaddr messages.
13719:22 <sipa> // Making nodes which are behind NAT and can only make outgoing connections ignore
13819:22 <sipa> // the getaddr message mitigates the attack.
13919:22 <ajonas> murch: yeah, I think that coinscope protection and what not
14019:22 <gloriazhao> i think it's to protect the outbound actually, yes?
14119:22 <gloriazhao> owait no, jk
14219:23 <sipa> robot-dreams: eh, terminology is confusing... the sender of the version message does not report their address, but does include the address they are using for the peer... so the receiver of the version message learns how they were reached
14319:23 <ajonas> if I recall correctly, exploiting the getaddr timestamps was used to infer network topology
14419:24 <sipa> ajonas: indeed
14519:24 <amiti> ajonas: yeah
14619:24 <amiti> anyone? how often do we advertise our address?
14719:24 <lightlike> amiti: on average we advertise once in 24 hours (AVG_LOCAL_ADDRESS_BROADCAST_INTERVAL)
14819:24 <amiti> lightlike: thanks!
14919:25 <Murch> That seems like a fairly long interval in an age where a lot of home connections are connected at least once per day
15019:25 <Murch> s/connected/disconnected
15119:25 <amiti> and also, its on a Poisson timer
15219:25 <amiti> does this frequency make sense? why is it on a poisson timer?
15319:25 <amiti> (two separate questions)
15419:26 <sipa> it's also filtered by addr_known, so the exact timer probably doesn't matter much
15519:26 <ares_> if we use the information of a received version message as our own IP, doesn't that make us susceptible to attacks if a peer deliberately announces a wrong IP?
15619:26 <felixweis> is auto dis/reconnect common for ISPs in the US/other countries too? new IP every 24 hours
15719:26 <robot-dreams> sipa: Thanks! Now it makes sense what `addrMe` means in `ProcessMessage` when processing an incoming `version`.
15819:26 <amiti> ares_ : good question!
15919:26 <lightlike> Murch: but we advertise on the beginning of each connection (not only after 24 hours). That's why m_next_local_addr_send needs to be initialized to 0.
16019:27 <sipa> ares_: there is a list of known "local IP" values; we only use the reported ones inside version messages to score those relative to each other
16119:27 <Murch> lightlike: Thnaks, that makes sense
16219:27 <willcl_ark> Perhaps we want the frequency to be _close_ to every 24h, but also to defeat any possible fingerprinting of exactly 24h?
16319:27 <sipa> ares_: we don't use it to learn what our own IP(s) are in the first place
16419:28 <sipa> i forgot, is the local relay timer per connection or not?
16519:28 <ares_> sipa: oh, okay. then that's not a concern
16619:28 <Murch> amiti: to prevent that announcements can be used to infer topology via timing?
16719:28 <felixweis> willcl_ark: i think thats correct, makes it harder to guess when exactly we came online
16819:28 <robot-dreams> ares_: Yeah, good point. Does the `IsPeerAddrLocalGood` check protect us against the "deliberately announces a wrong IP" attack?
16919:29 <amiti> oh right, I want to clarify there are two methods that trigger us to self advertise: 1. when we are processing a VERSION message a peer sent (so right after opening a new connection) 2. on an ongoing basis, ~1 / day
17019:29 <@jnewbery> sipa: local relay timer is per-peer
17119:29 <amiti> willcl_ark, murch: yeah, I think generally poisson is used for privacy benefits, but I was wondering what is trying to be kept private here. we're literally announcing our address which is public information
17219:30 <sipa> jnewbery: thanks... in that case i don't think the poisson timing does anything, as the peer knows when the connection was established anyway
17319:30 <gloriazhao> what can someone do with information about when we came online?
17419:30 <amiti> as murch said, there might be the possibility of topology inference
17519:30 <sipa> no, i think it may have just have been added as a "poisson all the things!" change
17619:30 <amiti> but another element is trying to prevent any synchronized network events to make sure there aren't random bandwidth spikes
17719:30 <sipa> i don't see the benefit in this case
17819:30 <willcl_ark> "In bitcoin we like pseudo-randomness?"
17919:30 <felixweis> poisson processes are cool tho...
18019:30 <Murch> Sounds fishy anyway.
18119:31 <gloriazhao> murch just won best pun of the day
18219:31 <willcl_ark> Another way of looking at the question; "why not poisson things?" :)
18319:31 <spiral_> gloriazhao I agree, seems like obfuscating our start time has a privacy benefit
18419:31 <sipa> well it's actually an exponential distribution, not a poisson one ;)
18519:31 <ares_> robot-dreams: just looking at the function for the first time. not sure which of those checks corresponds to what sipa was saying (i.e., comparing to a list of known IPs)
18619:31 <@jnewbery> I think that the default distribution for any randomized timer that results in network messages should be poisson, and we should only use a non-poisson distribution if there's a good reason to.
18719:31 <Murch> spiral_: but we seem to announce/advertise to each of our peers when coming online anyway
18819:31 <robot-dreams> amiti: Would it make sense to apply Poisson timing to "send out `addr`" but NOT apply Poisson timing "add our own address to the next `addr` to be sent"?
18919:32 <willcl_ark> sipa: are you saying `PoissonNextSend(current_time, AVG_LOCAL_ADDRESS_BROADCAST_INTERVAL)` is lying to me?
19019:32 <spiral_> Murch e.g. your point being it's not total obfuscation?
19119:32 <amiti> robot-dreams: good question! seems like one for the floor rather than me specifically :)
19219:32 <sipa> willcl_ark: it simulates a poisson process, by generating intervals that are exponentiall distribution :)
19319:32 <willcl_ark> oh no; a fake poisson
19419:32 <sipa> *exponentially *distributed
19519:32 <felixweis> simulation theory confirmed
19619:33 <Murch> spiral_: I mean, if we're still online after 24h, they can just use the IP to collect the two events. If we have a new IP, we do a new announcement anyway.
19719:33 <sipa> willcl_ark: no no, that is literally how poisson processes work; i'm just commenting on the fact that the name may imply it generates poisson-distributed values, which is not the case
19819:33 <emzy> felixweis: :D
19919:33 <spiral_> Murch I see your point now :]
20019:33 <Murch> spiral_: So, I'm starting to see why sipa said that he isn't aware of a privacy benefit
20119:33 <willcl_ark> sipa: phew
20219:34 <stacie> robot-dreams - earlier you mentioned the separate loop that sends an `addr` every 30 seconds (via AVG_ADDRESS_BROADCAST_INTERVAL), how is that different from the advertising that is done once every ~24 hrs (AVG_LOCAL_ADDRESS_BROADCAST_INTERVAL)?
20319:34 <lightlike> Does anyone know why is method 1 (advertising during VERSION only for outbounds) is necessary - if we just skipped that, wouldn't we self-advertise via SendMessages a few milliseconds later anyway, considering that m_next_local_addr_send is initialized to 0?
20419:34 ⚡ spiral_ just now got the "fishy" joke
20519:34 <robot-dreams> stacie: yeah, great point. My understanding was that `AVG_LOCAL_ADDRESS_BROADCAST_INTERVAL` is for "add our address to the next outgoing batch" but not for actually doing any sending
20619:34 <sipa> lightlike: i believe it may be pointless
20719:35 <stacie> ah, got it
20819:35 <@jnewbery> is it important that we send our own addr to addr_fetch peers?
20919:35 <sipa> robot-dreams: that's my belief too
21019:35 <willcl_ark> lightlike: looks like a good PR
21119:36 <Murch> Breaking: Bitcoin Core to reduce advertising by 50%
21219:36 <sipa> Murch: also there is a addr_known filter where we remember which addrs the peer is already aware of, and won't send a second time
21319:36 <amiti> jnewbery: for those unfamiliar, can you share what an addr_fetch peer is?
21419:36 <Murch> sipa: I see.
21519:36 <amiti> or, can anybody else answer? :)
21619:36 <sipa> so i think even the 24h-poisson delay may result in it not being sent a second time, as the old address may still be in the addr known filter
21719:37 <amiti> sipa: agreed.
21819:37 <spiral_> sipa would that be a performance-degrading facet of the code?
21919:37 <sipa> spiral_: no, how?
22019:38 <@jnewbery> addr_fetch are short-lived connections that we make to peers where we send a getaddr, wait for the addr response (this is the one that may contain up to 23% of addresses from the peer's addrman) and then disconnect
22119:38 <amiti> I didn't do the math, but I imagine the time is takes the filter to roll would be very variable based on eg. if you are accepting inbounds (even though its a per-peer filter, you would have more address traffic you send out)
22219:38 <sipa> amiti: indeed
22319:38 <amiti> okay, 38 minutes in, time for question 3 😛
22419:38 <amiti> why might we have multiple addresses for ourselves?
22519:39 <amiti> where do they come from?
22619:39 <Murch> jnewbery: Sounds very enabling to topology crawlers like bitnodes :p
22719:39 <@jnewbery> I ask whether it's important to send our own address to them because if so, then having the PushAddress() call inside the VERSION message processing might affect whether we send them our address or not
22819:39 <Murch> amiti: Because we might live in a weird internal network, where we think we have a different address than the global ip
22919:39 <spiral_> sipa I was thinking that if the address was unintentionally stale it might cause some errors -- more so from ignorant speculation on my part ;)
23019:40 <Murch> And some of our peers could be in the same sub network
23119:40 <felixweis> different interfaces? if we connect to a peer on the local network they might see a different address than one on the global internet
23219:40 <robot-dreams> Is there any IPv4 / IPv6 stuff thrown in there as well?
23319:40 <Murch> Or, Onion, IPv4, IPv6?
23419:40 <amiti> murch, felixweis: yup, those are def some use cases
23519:41 <amiti> I found it interesting to compare what my computer thinks my ip address is (using `ifconfig | grep inet` vs what googling "what is my ip address" returns. very different!
23619:41 <Murch> We could even have more than one internet connection!
23719:41 <jrawsthorne> Can we listen on multiple hosts/ports at the same time?
23819:41 <sipa> jrawsthorne: sure
23919:41 <felixweis> we can listen on v4 and v6 simulataneous
24019:42 <sipa> you can specify -listen multiple times too, if you have multiple ipv4/ipv6 addresses you're reachable on
24119:42 <felixweis> i believe by default we listen on all the interfaces
24219:42 <sipa> right
24319:42 <amiti> there's also the `-bind` command line arg where users can give addresses they want to listen to
24419:42 <emzy> In IPv6 you could have more then one Internet connection at home and use both.
24519:43 <emzy> Ok. Maybe nearly nobody uses this feature.
24619:44 <amiti> hahahha, so there are lots of reasons we might have multiple local addresses!
24719:44 <spiral_> amiti: wouldn't it be the case that `ifconfig | grep inet` is always going to list a different IP than a IP-query service unless you're connected right to the ISP modem, aka if there's a gateway in front of you `ifconfig | grep inet` is just your ip from a router?
24819:44 <emzy> Already outed myself as IPv6 fanboy.
24919:44 <sipa> amiti: yeah, it probably means you're behind a local NAT?
25019:44 <Murch> amiti: I'd say that's why we want to know how other peers see us in the first place. Cuz we often don't even know.
25119:44 <willcl_ark> Your router could also forward multiple ports to your bitcoind machine
25219:45 <sipa> emzy: aren't we all?
25319:45 <sipa> Murch: no, it's not used for that (too easy to lie)
25419:45 <emzy> sipa: I hope so. IPv4 is deprecated.
25519:45 <Murch> sipa: It is used for our self-advertisement via that peer.
25619:46 <Murch> to clarify "cuz we often don't know _how they see us_"
25719:46 <sipa> Murch: yes, but we determine what our local addresses are through a different mechanism (-externalip, upnp, local interface if it's public, ...)
25819:46 <amiti> spiral_, sipa: right, makes sense. was just cool to see a specific example :) my impression is that the majority of the time its going to be different?
25919:46 <Murch> yeah, I was not clear
26019:46 <sipa> Murch: then we use "how they see us" to score those list of addresses
26119:47 <amiti> sipa: are you talking about the weighting logic of `mapLocalHost` and `nScore`?
26219:47 <spiral_> Are there any defensive benefits of our peers telling us *what they believe is our network location*? E.g. if all peers are honest with our reported location, if an accurate message makes it to us, and one peer has an aberrant address, our node might learn of a MITM interference
26319:47 <sipa> amiti: yes
26419:47 <felixweis> whats the rationale for switching form * to &
26519:47 <amiti> sipa: I found it a bit hard to parse, do you have a high level overview of how the scores work that you could share?
26619:48 <@jnewbery> sipa: oh, so if a peer tells us our address and we don't already know the address through one of those other mechanisms, we'll never use that as our self-advertised address to other peers?
26719:48 <sipa> jnewbery: correct
26819:48 <sipa> amiti: it depends on how you define "majority of the time"... for home users, sure
26919:48 <amiti> sipa, jnewbery: ooooo
27019:48 <amiti> wow! this stuff is wild!
27119:49 <sipa> amiti: if you run a bitcoind as an internet service, on a server in datacenter somewhere your local interface will have a publicly routable IP usually
27219:49 <amiti> sipa: ah, I see
27319:50 <spiral_> +1
27419:50 <sipa> if you use bitcoind behind a NAT you need to use -externalip to configure your public IP, or use UPnP (which makes bitcoind talk to your router and ask it for its public IP)
27519:50 <amiti> oh snap, we only have 11 minutes left. umm maybe we should talk about the changes in this PR 😂
27619:50 <sipa> amiti: actually, which PR is it?
27719:50 <sipa> i don't think you mentioned that ;)
27819:50 <amiti> can anyone overview what this PR is doing, and what are the behavioral changes
27919:50 <felixweis> amiti: or if you come to chaos communication congress
28019:50 <@jnewbery> felixweis: since gleb was basically touching every line of the function I suggested he change the signature. I think the only reasons to use a raw pointer instead of a reference are (1) if you want to be able to pass null; or (2) if you want to reseat the pointer (point it at something else). Neither of those are the case here, so pass-by-reference communicates intent better
28119:50 <amiti> sipa: lolol 19843
28219:50 <amiti> sipa: gotcha! thanks thats very helpful
28319:51 <sipa> felixweis: is 37c3 happening?
28419:51 <felixweis> every laptop/smarphone/raspiblitz gets a publicly routable address at europes biggest hacker conference
28519:51 <amiti> felixweis: I have no idea what chaos communication congress is, but I like it. I'm definitely in.
28619:51 <Murch> felixweis, jnewbery: Thanks, I was wondering as well.
28719:51 <robot-dreams> amiti: PR overview: there used to be two different code paths for adding our own address to the "addresses to be sent on next `addr`" list, and this PR consolidates them.
28819:52 <felixweis> sipa: certainly not :(
28919:52 <robot-dreams> As for behavior change, now we might randomly override our local address with the peer's view of us when responding to the peer's initial `version`.
29019:52 <emzy> sipa: 37C3 will be online.
29119:52 <amiti> robot-dreams: yeah! thats my understanding as well
29219:52 <robot-dreams> However, my guess is this could only happen if we connect to an outbound peer who already knew about us?
29319:53 <felixweis> jnewbery: thanks. looked like a c++ style quesion but i don't know too much about it so i wasn't sure to ask
29419:53 <amiti> right so the behavior change comes from the logic used to decide which local address to relay
29519:53 <Murch> robot-dreams: Wasn't it only for the self-advertisement after establishing the new connection?
29619:54 <robot-dreams> Murhc: Yes, what I'm saying is, after the PR, could the address we self-advertise could be different?
29719:54 <Murch> Yes, but only on a per-peer basis
29819:54 <robot-dreams> Murch* sorry
29919:54 <felixweis> amiti: hope to see you at one event in the not all to distant future
30019:55 <amiti> okay and to squeeze in the last couple questions, lets just thread this conversation
30119:55 <Murch> I'm not sure whether it could already be part of the VER handshake
30219:55 <amiti> 5. When you PushAddress, will this necessarily send an addr P2P message? (hint: we've already discussed this)
30319:55 <amiti> 6. When you relay an addr out to a peer, what does the receiving peer do with the message?
30419:55 <elle> amiti: 5) no. it might be replaced by another one later on if the vAddrToSend is too full. It will also not be added to vAddrToSend (and hence not sent) if m_addr_known filter has a matching address.
30519:56 <Murch> amiti: fanmail and stickers. Definitely to send fanmail and stickers.
30619:56 <amiti> elle: very nice!
30719:56 <amiti> murch: o.0 ?
30819:56 <Murch> err, it adds it to the list of peers it will advertise?
30919:57 <amiti> ahhahahahha oh I get the joke now
31019:57 <Murch> if one of the peer's peers asks for more peers
31119:57 <sipa> needs more interrobang
31219:58 <amiti> murch: yeah, adds to addrman as one thing
31319:58 <@jnewbery> elle: great answer! In reality, I think it's uncommon for vAddrToSend to fill up except when we process a GETADDR (which can only happen once for each connection)
31419:58 <amiti> but also, when a node receives an addr message, if there's < 10 of them & a couple other conditions are met, it will relay it out to 1-2 other peers
31519:58 <willcl_ark> Also, since #18991 the address would not propagate into our cached AddrMan for some time
31619:59 <elle> jnewbery: ok cool, thanks. yeah i see MAX_ADDR_TO_SEND=1000 which is pretty big!
31719:59 <amiti> willcl_ark: ya, so that impacts the GETADDR responses I believe
31820:00 <amiti> okay, final minute... any burning questions?
31920:00 <amiti> 🎉
32020:00 <@jnewbery> elle: right, and when we receive a gossipped address, we'll add to the vAddrToSend vectors for at most 2 peers.
32120:00 <ajonas> thanks amiti
32220:00 <amiti> and thats a wrap!
32320:00 <Murch> Thanks!
32420:00 <robot-dreams> thanks!
32520:00 <felixweis> thanks amiti!
32620:00 <emzy> thanks all!
32720:01 <stacie> thanks amiti!
32820:01 <spiral_> thank amiti
32920:01 <@jnewbery> great pun review club meeting. Thanks amiti!
33020:01 <willcl_ark> thanks amiti!
33120:01 <gloriazhao> thanks amiti!
33220:01 <ajonas> addriós amigos!
33320:01 <amiti> thanks all, that was awesome! great questions. I learned a lot & have more I want to dig into :)
33420:01 <amiti> #endmeeting