--- Day changed Wed Oct 07 2020
00:15 -!- PaulTroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews     
00:18 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews     
00:19 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
00:23 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]     
00:27 -!- PaulTroo_ [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit []     
01:27 -!- tralfaz [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
01:27 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]     
01:35 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
01:39 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]     
01:55 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 265 seconds]     
01:56 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds]     
02:09 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews     
02:31 -!- jonatack [~jon@213.152.162.94] has joined #bitcoin-core-pr-reviews     
02:42 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]     
02:45 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
03:03 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]     
03:06 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
03:09 -!- belcher_ is now known as belcher     
03:10 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection]     
03:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
03:10 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews     
03:11 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has joined #bitcoin-core-pr-reviews     
03:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
03:14 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection]     
03:20 -!- Alisa27Konopelsk [~Alisa27Ko@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:22 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews     
03:30 -!- Alisa27Konopelsk [~Alisa27Ko@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 265 seconds]     
03:36 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
03:37 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews     
04:19 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews     
04:19 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
04:19 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
04:29 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection]     
04:30 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has joined #bitcoin-core-pr-reviews     
04:30 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews     
04:40 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 240 seconds]     
04:44 -!- jonatack [~jon@213.152.162.94] has quit [Ping timeout: 246 seconds]     
04:58 -!- tryphe_ is now known as tryphe     
05:34 -!- icota[m]1 [icotamatri@gateway/shell/matrix.org/x-sxcivdfavteepvuu] has quit [Quit: killed]     
05:34 -!- sharknado9000[m] [sharknado9@gateway/shell/matrix.org/x-wcoqmaxqlrsnikxp] has quit [Quit: killed]     
05:40 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-zjoqpgpgseeabplt] has joined #bitcoin-core-pr-reviews     
05:55 -!- sharknado9000[m] [sharknado9@gateway/shell/matrix.org/x-qqahyttnvzclanjx] has joined #bitcoin-core-pr-reviews     
05:59 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews     
06:03 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews     
06:04 -!- Netsplit *.net <-> *.split quits: da39a3ee5e6b4b0d, tryphe, kallewoof, dergoegge
06:04 -!- tryphe_ is now known as tryphe     
06:04 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 260 seconds]     
06:09 -!- dergoegge [sid453889@gateway/web/irccloud.com/x-jzdktyxxskljzfdk] has joined #bitcoin-core-pr-reviews     
06:09 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has joined #bitcoin-core-pr-reviews     
06:33 -!- tralfaz is now known as davterra     
06:38 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
06:52 -!- worc3131 [~quassel@2a02:c7f:c026:9500:7d0b:65d0:38a4:4786] has quit [Quit: No Ping reply in 180 seconds.]     
06:53 -!- worc3131 [~quassel@2a02:c7f:c026:9500:a0d2:b9d1:42a4:69b4] has joined #bitcoin-core-pr-reviews     
07:04 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
07:14 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-zjoqpgpgseeabplt] has left #bitcoin-core-pr-reviews ["Kicked by @appservice-irc:matrix.org  : Idle for 30+ days"]     
08:12 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has joined #bitcoin-core-pr-reviews     
08:44 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews     
08:59 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
09:11 -!- premek [50fa1c6e@80.250.28.110] has joined #bitcoin-core-pr-reviews     
09:12 -!- premek [50fa1c6e@80.250.28.110] has quit [Remote host closed the connection]     
09:13 -!- spiral_ [~spiral@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
09:38 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
09:43 -!- elle [~ellemouto@155.93.252.70] has joined #bitcoin-core-pr-reviews     
09:47 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has joined #bitcoin-core-pr-reviews     
09:54 -!- lightlike [~lightlike@p200300c7ef134f0014170b67e50a7b8d.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
09:59 -!- norisg [~nobody123@dslb-094-216-002-184.094.216.pools.vodafone-ip.de] has quit [Remote host closed the connection]     
10:00 < amiti> #startmeeting
10:00 < spiral_> hello
10:00 < willcl_ark> hi     
10:00 < elle> hi!     
10:00 < pinheadmz> hi     
10:00 < emzy> hi     
10:00 < stacie> hi     
10:00 < amiti> hi everyone!
10:00 < felixweis> hi     
10:00 < nehan> hi     
10:00 < robot-dreams> hi     
10:00 < gloriazhao> hi!     
10:00 < lightlike> hi     
10:00 <@jnewbery> hi!     
10:00 < amiti> anyone here for the first time?
10:01 -!- dhruvm [~noreply@249.115.24.136.in-addr.arpa] has joined #bitcoin-core-pr-reviews     
10:01 < ajonas> hi     
10:01 < dhruvm> hi     
10:01 < Murch> Hai     
10:01 < amiti> welcome all :)
10:02 < sipa> hi     
10:02 < amiti> this week, we’ll be chatting about ✨ addr relay ✨
10:02 < pinheadmz> hooray! thats a great kind of relay!
10: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!
10:02 < sipa> about time that we *address* this issue
10:02 < amiti> 😂
10:02  * spiral_ ba dum tsh
10:02 < felixweis> announce all the peers!
10:03 < amiti> let's get started!
10:03 <@jnewbery> are you relay going to make that joke, sipa?
10:03 < amiti> who's had the chance to look at the PR? y/n
10:03 < Murch> y     
10:03 < robot-dreams> y     
10:03 < spiral_> y     
10:03 < felixweis> y     
10:03 < elle> y     
10:03 <@jnewbery> y     
10:03 < stacie> y     
10:03 < willcl_ark> y     
10:03 < emzy> y     
10:03 < nehan> n     
10:03 < lightlike> y     
10:03 < amiti> ( but to be clear, these puns are great. keep em coming )
10:04 < amiti> wow nice! lots of review
10:04 < Murch> peering over the verge :)
10:04 < amiti> ok, so lets start with the fundamentals- why do we advertise our own address?
10:04 < Murch> Cuz we want more friends :'(
10:05 < stacie> because outbound peers do not necessarily have your address, and like Murch said, you want more friends :)
10:05 < willcl_ark> We want to get new inbound connections and populate addrman
10:05 < dhruvm> So we can have incoming connections which can help us discover transactions and blocks faster
10:05 < emzy> So that others know us.
10:05 < spiral_> announce a concrete location to the network where we can be located
10:05 < gloriazhao> do we do it even if inbounds aren't enabled?
10:05 < amiti> yup! exactly. its to make sure other nodes know how to find us
10:05 < Murch> gloriazhao: Excellent question.
10:06 < gloriazhao> thank u very murch
10:06 < amiti> anybody know the answer to gloriazhao's question?
10:06 < Murch> No, but I'm curious as well ^^
10:06 < dhruvm> @gloriazhao: i know that addr gossip continues even in -connect mode without -listen
10:06 < pinheadmz> instinct is no
10:06 < robot-dreams> I think we don't if inbounds aren't enabled or if we're in IDB?
10:07 < dhruvm> but i do not know if we will advertise ourselves without -listen
10:07 < robot-dreams> (though I'm not sure if I'm interpreting the `fListen` condition correctly)
10:07 < Murch> dhruvm: But `-connect` only regulates outbound, right?
10:07 <@jnewbery> the gloval fListen is relevant here
10:07 <@jnewbery> *global
10:07 < jrawsthorne> hi     
10:07 < amiti> hi! welcome
10:08 < jrawsthorne> Thanks amiti
10:08 < willcl_ark> Looks like we don't,  if -listen is disabled?
10: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
10: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
10: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?
10:09 < sipa> lightlike: not if we connected out to them
10:09 < amiti> great question lightlike!
10:09 <@jnewbery> (fListen is checked for self-advertisement before and after this PR)
10: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)?
10:09 < dhruvm> lightlike: even if they know our address, nodes only share 23% of their addrman with their peers
10:09 < pinheadmz> robot-dreams its not in the version message
10:10 < pinheadmz> but we can send an ADDR message right after handshake
10:10 < sipa> jnewbery: you knew i had to make that joke if nobody else did
10:10 < felixweis> dhruvm: don't advertise all the peers!
10:10 < spiral_>  addr documentation: https://en.bitcoin.it/wiki/Protocol_documentation#addr
10:11 < amiti> ok, so to dig in- what address information is contained in the version message?
10: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
10:11 < pinheadmz> amiti robot-dreams my bad! there is an address in there https://en.bitcoin.it/wiki/Protocol_documentation#version
10:11 < dhruvm> @jnewbery: I see.
10:11 < sipa> jnewbery: the period gossip is only for new addresses; it's not from addrman at all
10:11 < sipa> afaik?
10:12 <@jnewbery> sipa: correct
10: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?
10:13 < pinheadmz> amiti there is a net_addr for both sender and receiver in version
10:13 < amiti> lets start with #2, because its essentially been answered. can someone summarize the difference between these two methods for sharing addresses?
10:13 <@jnewbery> sipa: oops, yes. What I said was confusing.
10:13 < amiti> pinheadmz: yup :)
10: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?
10: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.
10:13 < sipa>     CAddress addrMe = CAddress(CService(), nLocalNodeServices);
10:13 < sipa>     connman.PushMessage(&pnode, CNetMsgMaker(INIT_PROTO_VERSION).Make(NetMsgType::VERSION, PROTOCOL_VERSION, (uint64_t)nLocalNodeServices, nTime, addrYou, addrMe,
10:13 < Murch> Or is the joke that we could lie?
10:13 < sipa>             nonce, strSubVersion, nNodeStartingHeight, ::g_relay_txes && pnode.m_tx_relay != nullptr));
10:14 < sipa> ^ i believe the "our address" in the version message is a dummy these days
10:15 < felixweis> so during handshake we learn about our own IP
10: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"?
10:15 < willcl_ark> I also came across this issue during my research, which i thought was interesting: https://github.com/bitcoin/bitcoin/pull/5161
10: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?
10:16 < pinheadmz> lightlike could be wrong but i think thats kinda handled by the OS- like the handle for the tcp connection
10:16 < sipa> amiti: indeed
10:16 < pinheadmz> you might see localAddr in getpeerinfo
10:16 < sipa> amiti: let me find the change that did that, it's ancient
10: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
10:16 < amiti> sipa: oh wow, interesting.
10:17 < Murch> willcl_ark: looks very relevant.
10: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?
10: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 ?
10:17 < sipa> amiti: PR 8740
10:17 < willcl_ark> Murch: the older linked issue too (#3088) also had some additional context
10:17 -!- ares_ [~ares@gateway/tor-sasl/virtu] has quit [Remote host closed the connection]     
10:17 -!- ares_ [~ares@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews     
10:18 < robot-dreams> amiti: I'm looking at `AVG_ADDRESS_BROADCAST_INTERVAL`
10:18 < amiti> robot-dreams, sipa: thanks! looks like I'll have lots more to dig into after this session :)
10:19 < sipa> in any case, the "my address" function is fullfilled by just sending out addr messages for our own IP
10:19 < felixweis> external IP resolution services were the main way to get the IP to announce in the IRC channels?
10:19 < gloriazhao> I find it interesting that we don't respond to getaddrs from outbounds https://github.com/bitcoin/bitcoin/blob/283a73d7eaea2907a6f7f800f529a0d6db53d7a6/src/net_processing.cpp#L3549 (if i'm reading this correctly)
10:20 < willcl_ark> Seems like sometimes an outbound might have a better idea of our address than we do ourselves
10:20 < felixweis> willcl_ark: almost always at least for anything that uses NAT
10:20 < willcl_ark> no wait, inbounds ...
10:20  * spiral_ fantasizes about all these address-discovery challenges going away with onion addressing
10:20 -!- ares_ [~ares@gateway/tor-sasl/virtu] has quit [Remote host closed the connection]     
10:20 < willcl_ark> yeah
10: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
10:21 < amiti> so- how often do we advertise our address?
10:21 < emzy> willcl_ark: Also IPv6 fixes this :)
10: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.
10: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"?
10:21 < Murch> gloriazhao: To prevent outbound peers from eclipse attacking easily
10:21 < willcl_ark> emzy: hooray! Now if only my ISP would move forward with it...
10:22 < sipa>         // This asymmetric behavior for inbound and outbound connections was introduced
10:22 < sipa>         // to prevent a fingerprinting attack: an attacker can send specific fake addresses
10:22 < sipa>         // to users' AddrMan and later request them by sending getaddr messages.
10:22 < sipa>         // Making nodes which are behind NAT and can only make outgoing connections ignore
10:22 < sipa>         // the getaddr message mitigates the attack.
10:22 < ajonas> murch: yeah, I think that coinscope protection and what not
10:22 < gloriazhao> i think it's to protect the outbound actually, yes?
10:22 < gloriazhao> owait no, jk
10:22 -!- ares_ [~ares@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews     
10: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
10:23 < ajonas> if I recall correctly, exploiting the getaddr timestamps was used to infer network topology
10:24 < sipa> ajonas: indeed
10:24 < amiti> ajonas: yeah
10:24 < amiti> anyone? how often do we advertise our address?
10:24 < lightlike> amiti: on average we advertise once in 24 hours (AVG_LOCAL_ADDRESS_BROADCAST_INTERVAL)
10:24 < amiti> lightlike: thanks!
10: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
10:25 < Murch> s/connected/disconnected
10:25 < amiti> and also, its on a Poisson timer
10:25 < amiti> does this frequency make sense? why is it on a poisson timer?
10:25 < amiti> (two separate questions)
10:26 < sipa> it's also filtered by addr_known, so the exact timer probably doesn't matter much
10: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?
10:26 < felixweis> is auto dis/reconnect common for ISPs in the US/other countries too? new IP every 24 hours
10:26 < robot-dreams> sipa: Thanks! Now it makes sense what `addrMe` means in `ProcessMessage` when processing an incoming `version`.
10:26 < amiti> ares_ : good question!
10: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.
10: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
10:27 < Murch> lightlike: Thnaks, that makes sense
10:27 < willcl_ark> Perhaps we want the frequency to be _close_ to every 24h, but also to defeat any possible fingerprinting of exactly 24h?
10:27 < sipa> ares_: we don't use it to learn what our own IP(s) are in the first place
10:28 < sipa> i forgot, is the local relay timer per connection or not?
10:28 < ares_> sipa: oh, okay. then that's not a concern
10:28 < Murch> amiti: to prevent that announcements can be used to infer topology via timing?
10:28 < felixweis> willcl_ark: i think thats correct, makes it harder to guess when exactly we came online
10:28 < robot-dreams> ares_: Yeah, good point. Does the `IsPeerAddrLocalGood` check protect us against the "deliberately announces a wrong IP" attack?
10: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
10:29 <@jnewbery> sipa: local relay timer is per-peer
10: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
10: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
10:30 < gloriazhao> what can someone do with information about when we came online?
10:30 < amiti> as murch said, there might be the possibility of topology inference
10:30 < sipa> no, i think it may have just have been added as a "poisson all the things!" change
10:30 < amiti> but another element is trying to prevent any synchronized network events to make sure there aren't random bandwidth spikes
10:30 < sipa> i don't see the benefit in this case
10:30 < willcl_ark> "In bitcoin we like pseudo-randomness?"
10:30 < felixweis> poisson processes are cool tho...
10:30 < Murch> Sounds fishy anyway.
10:31 < gloriazhao> murch just won best pun of the day
10:31 < willcl_ark> Another way of looking at the question; "why not poisson things?" :)
10:31 < spiral_> gloriazhao I agree, seems like obfuscating our start time has a privacy benefit
10:31 < sipa> well it's actually an exponential distribution, not a poisson one ;)
10: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)
10: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.
10:31 < Murch> spiral_: but we seem to announce/advertise to each of our peers when coming online anyway
10: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"?
10:32 < willcl_ark> sipa: are you saying `PoissonNextSend(current_time, AVG_LOCAL_ADDRESS_BROADCAST_INTERVAL)` is lying to me?
10:32 < spiral_> Murch e.g. your point being it's not total obfuscation?
10:32 < amiti> robot-dreams: good question! seems like one for the floor rather than me specifically :)
10:32 < sipa> willcl_ark: it simulates a poisson process, by generating intervals that are exponentiall distribution :)
10:32 < willcl_ark> oh no; a fake poisson
10:32 < sipa> *exponentially *distributed
10:32 < felixweis> simulation theory confirmed
10: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.
10: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
10:33 < emzy> felixweis: :D
10:33 < spiral_> Murch I see your point now :]
10:33 < Murch> spiral_: So, I'm starting to see why sipa said that he isn't aware of a privacy benefit
10:33 < willcl_ark> sipa: phew
10: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)?
10: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?
10:34  * spiral_ just now got the "fishy" joke
10: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
10:34 < sipa> lightlike: i believe it may be pointless
10:35 < stacie> ah, got it
10:35 <@jnewbery> is it important that we send our own addr to addr_fetch peers?
10:35 < sipa> robot-dreams: that's my belief too
10:35 < willcl_ark> lightlike: looks like a good PR
10:36 < Murch> Breaking: Bitcoin Core to reduce advertising by 50%
10: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
10:36 < amiti> jnewbery: for those unfamiliar, can you share what an addr_fetch peer is?
10:36 < Murch> sipa: I see.
10:36 < amiti> or, can anybody else answer? :)
10: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
10:37 < amiti> sipa: agreed.
10:37 < spiral_> sipa would that be a performance-degrading facet of the code?
10:37 < sipa> spiral_: no, how?
10: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
10: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)
10:38 < sipa> amiti: indeed
10:38 < amiti> okay, 38 minutes in, time for question 3 😛
10:38 < amiti> why might we have multiple addresses for ourselves?
10:39 < amiti> where do they come from?
10:39 < Murch> jnewbery: Sounds very enabling to topology crawlers like bitnodes :p
10: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
10:39 < Murch> amiti: Because we might live in a weird internal network, where we think we have a different address than the global ip
10: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 ;)
10:40 < Murch> And some of our peers could be in the same sub network
10: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
10:40 < robot-dreams> Is there any IPv4 / IPv6 stuff thrown in there as well?
10:40 < Murch> Or, Onion, IPv4, IPv6?
10:40 < amiti> murch, felixweis: yup, those are def some use cases
10: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!
10:41 < Murch> We could even have more than one internet connection!
10:41 < jrawsthorne> Can we listen on multiple hosts/ports at the same time?
10:41 < sipa> jrawsthorne: sure
10:41 < felixweis> we can listen on v4 and v6 simulataneous
10:42 < sipa> you can specify -listen multiple times too, if you have multiple ipv4/ipv6 addresses you're reachable on
10:42 < felixweis> i believe by default we listen on all the interfaces
10:42 < sipa> right
10:42 < amiti> there's also the `-bind` command line arg where users can give addresses they want to listen to
10:42 < emzy> In IPv6 you could have more then one Internet connection at home and use both.
10:43 < emzy> Ok. Maybe nearly nobody uses this feature.
10:44 < amiti> hahahha, so there are lots of reasons we might have multiple local addresses!
10: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?
10:44 < emzy> Already outed myself as IPv6 fanboy.
10:44 < sipa> amiti: yeah, it probably means you're behind a local NAT?
10: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.
10:44 < willcl_ark> Your router could also forward multiple ports to your bitcoind machine
10:45 < sipa> emzy: aren't we all?
10:45 < sipa> Murch: no, it's not used for that (too easy to lie)
10:45 < emzy> sipa: I hope so. IPv4 is deprecated.
10:45 < Murch> sipa: It is used for our self-advertisement via that peer.
10:46 < Murch> to clarify "cuz we often don't know _how they see us_"
10:46 < sipa> Murch: yes, but we determine what our local addresses are through a different mechanism (-externalip, upnp, local interface if it's public, ...)
10: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?
10:46 < Murch> yeah, I was not clear
10:46 < sipa> Murch: then we use "how they see us" to score those list of addresses
10:47 < amiti> sipa: are you talking about the weighting logic of `mapLocalHost` and `nScore`?
10: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
10:47 < sipa> amiti: yes
10:47 < felixweis> whats the rationale for switching form * to &
10: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?
10: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?
10:48 -!- worc3131 [~quassel@2a02:c7f:c026:9500:a0d2:b9d1:42a4:69b4] has quit [Quit: No Ping reply in 180 seconds.]     
10:48 < sipa> jnewbery: correct
10:48 < sipa> amiti: it depends on how you define "majority of the time"... for home users, sure
10:48 < amiti> sipa, jnewbery: ooooo
10:48 < amiti> wow! this stuff is wild!
10: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
10:49 < amiti> sipa: ah, I see
10:50 < spiral_> +1     
10: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)
10:50 < amiti> oh snap, we only have 11 minutes left. umm maybe we should talk about the changes in this PR 😂
10:50 < sipa> amiti: actually, which PR is it?
10:50 < sipa> i don't think you mentioned that ;)
10:50 < amiti> can anyone overview what this PR is doing, and what are the behavioral changes
10:50 < felixweis> amiti: or if you come to chaos communication congress
10: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
10:50 < amiti> sipa: lolol 19843
10:50 < amiti> sipa: gotcha! thanks thats very helpful
10:51 < sipa> felixweis: is 37c3 happening?
10:51 < felixweis> every laptop/smarphone/raspiblitz gets a publicly routable address at europes biggest hacker conference
10:51 < amiti> felixweis: I have no idea what chaos communication congress is, but I like it. I'm definitely in.
10:51 < Murch> felixweis, jnewbery: Thanks, I was wondering as well.
10: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.
10:52 < felixweis> sipa: certainly not :(
10: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`.
10:52 < emzy> sipa: 37C3 will be online.
10:52 < amiti> robot-dreams: yeah! thats my understanding as well
10:52 < robot-dreams> However, my guess is this could only happen if we connect to an outbound peer who already knew about us?
10: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
10:53 < amiti> right so the behavior change comes from the logic used to decide which local address to relay
10:53 < Murch> robot-dreams: Wasn't it only for the self-advertisement after establishing the new connection?
10:54 < robot-dreams> Murhc: Yes, what I'm saying is, after the PR, could the address we self-advertise could be different?
10:54 < Murch> Yes, but only on a per-peer basis
10:54 < robot-dreams> Murch* sorry
10:54 < felixweis> amiti: hope to see you at one event in the not all to distant future
10:55 < amiti> okay and to squeeze in the last couple questions, lets just thread this conversation
10:55 < Murch> I'm not sure whether it could already be part of the VER handshake
10:55 < amiti> 5. When you PushAddress, will this necessarily send an addr P2P message? (hint: we've already discussed this)
10:55 < amiti> 6. When you relay an addr out to a peer, what does the receiving peer do with the message?
10: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.
10:56 < Murch> amiti: fanmail and stickers. Definitely to send fanmail and stickers.
10:56 < amiti> elle: very nice!
10:56 < amiti> murch: o.0 ?
10:56 < Murch> err, it adds it to the list of peers it will advertise?
10:57 < amiti> ahhahahahha oh I get the joke now
10:57 < Murch> if one of the peer's peers asks for more peers
10:57 < sipa> needs more interrobang
10:58 < amiti> murch: yeah, adds to addrman as one thing
10: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)
10:58 -!- philipds [c2d1bf22@194.209.191.34] has joined #bitcoin-core-pr-reviews     
10: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
10:58 < willcl_ark> Also, since #18991 the address would not propagate into our cached AddrMan for some time
10:58 -!- worc3131 [~quassel@2a02:c7f:c026:9500:a0d2:b9d1:42a4:69b4] has joined #bitcoin-core-pr-reviews     
10:59 < elle> jnewbery: ok cool, thanks. yeah i see MAX_ADDR_TO_SEND=1000 which is pretty big!
10:59 < amiti> willcl_ark: ya, so that impacts the GETADDR responses I believe
11:00 < amiti> okay, final minute... any burning questions?
11:00 < amiti> 🎉
11:00 <@jnewbery> elle: right, and when we receive a gossipped address, we'll add to the vAddrToSend vectors for at most 2 peers.
11:00 < ajonas> thanks amiti
11:00 < amiti> and thats a wrap!
11:00 < Murch> Thanks!
11:00 < robot-dreams> thanks!
11:00 < felixweis> thanks amiti!
11:00 < emzy> thanks all!
11:01 < stacie> thanks amiti!
11:01 < spiral_> thank amiti
11:01 <@jnewbery> great pun review club meeting. Thanks amiti!
11:01 < willcl_ark> thanks amiti!
11:01 < gloriazhao> thanks amiti!
11:01 < ajonas> addriós amigos!
11:01 < amiti> thanks all, that was awesome! great questions. I learned a lot & have more I want to dig into :)
11:01 < amiti> #endmeeting
11:01 < dhruvm> There's a ton I need to learn about tcp/ip and the networking stack. Does anyone have recommendations for structured learning?
11:01 < lightlike> thanks!
11:01 < dhruvm> thanks, amiti!
11:01 < elle> thanks amiti! that was awesome. learned soooo much!
11:01 < amiti> yay!
11:02 < spiral_> amiti def check out the CCC lectures, chaos computer congress is a cyberpunk treasure
11:02 < Murch> p2p is hard, I'll stick to easier stuff like coin selection :p
11:02 < spiral_> lol     
11:02 < amiti> spiral_: cool! thanks
11:02 < willcl_ark> dhruvm: I once bookmarked this page: http://beej.us/guide/bgnet/html/
11:02 < sipa> amiti: fwiw, chaos communication congress (often incorrectly abbreviated as CCC), is the largest security/hacker conference in europe, held annually dec 27-30
11:02 -!- philipds [c2d1bf22@194.209.191.34] has quit [Remote host closed the connection]     
11:03 < emzy> Info for the CCC this year: https://events.ccc.de/2020/09/04/rc3-remote-chaos-experience/#english
11:03 < dhruvm> willcl_ark: this it great. thanks.
11:03 < amiti> 👌 🙂
11:03 < willcl_ark> enjoy!
11:03 < spiral_> sipa are you saying the congress shouldn't be abbreviated as CCC as CCC stands for the club?
11:04 < sipa> spiral_: indeed
11:04 < spiral_> :P     
11:04 < Murch> CCC stands for Chaos Computer Club, Chaos Communiction Congress is 3C ;)
11:04 < sipa> Murch: C3
11:04 < felixweis> amiti: https://calendify.com/uploads/media/cache/event_1360x766/event/5e691e809eef00-55380068-9c708fb5153423cdf1f62477b78642e8.jpg
11:04 -!- elle [~ellemouto@155.93.252.70] has left #bitcoin-core-pr-reviews []     
11:04 < Murch> shame :~
11:05 < spiral_> I enjoy recognizing various bitcoiners' voices during Q&A at C3
11:05 < spiral_> bad opsec though, should have had a voice modulator :P
11:05 < sipa> one cool thing is the 'assemblies' which are table space that organizations can request to make their own stand/meeting space
11:05 < emzy> Awesome event. I'm so sad to see you this this year not in person.
11:05 < sipa> there has been a bitcoin assembly for years
11:05 < sipa> (organized by a dogecoiner)
11:06 < emzy> But I startet it ;)
11:06 < sipa> emzy: oh did you!
11:06 < felixweis> its the best assembly. but there also tons of other nerdy things to learn about with their own assemblies
11:06 < spiral_> I     
11:06 < spiral_> O     
11:06 < spiral_> I     
11:06 < spiral_> sorry an error
11:07 < emzy> sipa: yes. But the dogecoiner joind in the first year. Also felexwies was there.
11:07 < sipa> yes, that's where i met you two first i think
11:07 < felixweis> bitcoin sofa!
11:07 < sipa> felix may have been in hong kong
11:07 < emzy> without sofa ;)
11:07 < spiral_> for those based in the US, defcon seems the closest equivalent to C3 - but it's more philosophical and less stunt-hacking
11:08 < felixweis> sipa: aah. i kinda hoped you didn't remember
11:08 < sipa> felixweis: i remember macau
11:08 < sipa> spiral_: also, C3 is entirely volunteer-organized
11:08 < emzy> I think there will be a online assembly this year.
11:09 < felixweis> ok macau was fun. but we first met in HK at the reception party for scaling bitcoin
11:09 < sipa> felixweis: hmm, possible
11:09 < felixweis> that part i was hoping you'd forgotten about
11:09 < sipa> i may have
11:09 < felixweis> ok perfect
11:10 < Murch> talking about bad opsec: youtu.be/ELIeyjIg5V4
11:10 < Murch> talking about bad opsec: https://youtu.be/ELIeyjIg5V4
11:11  * sipa shares that URL
11:11 < spiral_> congrats on chaincode Murch, I'm going to attribute your PR-review attendance due to your new role hehe
11:12 -!- lightlike [~lightlike@p200300c7ef134f0014170b67e50a7b8d.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
11:12 < felixweis> congrats both, much and sipa. and chaincode :)
11:12 < Murch> spiral_: I've been meaning to for a long time, but often it was conflicting with other meetings or I just lost track of time. Now it's on my calendar, yeah :D
11:12 < emzy> I have the feeling I have to visit NYC some time in the future. Seems to be big into bitcoin people :)
11:13 < sipa> i'd avoid it for the time being
11:13 < spiral_> NYC...is....hmmm how to say
11:13 < Murch> lol, I can't watch it, I'm so nervous :p
11:13 -!- worc3131 [~quassel@2a02:c7f:c026:9500:a0d2:b9d1:42a4:69b4] has quit [Ping timeout: 240 seconds]     
11:13 < sipa> felixweis: thanks :)
11:14 < spiral_> ..not an emblem of freedom :P
11:14 < Murch> spiral_: It's an anarchistic city!
11:14 < spiral_> lol I don't know about that
11:14 < sipa> Murch: it's too german for me to understand much, but apart from that, you did fine
11:14 < Murch> (per POTUS's assessment, how could you doubt)
11:14 < emzy> I only drove by once. Saw the skyline. Thats it.
11:14 -!- worc3131 [~quassel@94.4.49.118] has joined #bitcoin-core-pr-reviews     
11:15 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews     
11:15 < Murch> emzy: Yeah, when the whole 'rona circus has died down a bit, we expect your visit in the office.
11:15 < spiral_> emzy it's definitely a city to know in the world and it's role/weight.  It's just a nightmare for anyone who's privacy focused or non authoritarian
11:16 < emzy> YAY!
11:16 < emzy> I'm German, so I used to it ;)
11:17 < emzy> I still hope Bitcoin 2021 will happen.
11:17 < spiral_> a Scaling?
11:18 < sipa> the bitcoin magazine thing?
11:18 < felixweis> me too hopes bitcoin $2021 is happening. buying the dip
11:19 < emzy> sipa: yes.
11:21 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 272 seconds]     
11:21 < spiral_> it's supposed to be held in Los Angeles, no?
11:22 < emzy> yes     
11:22 < Murch> Thanks for the congrats, spiral_ and felixweis.
11:23 < emzy> Congrats also from me Murch and sipa. IRC is more official than twitter ;)
11:23 < Murch> Well, we'll see whether people get their head straight about disease prevention until then, so that such events can happen again…
11:23 < Murch> haha, thanks
11:24 < Murch> but we are getting a bit off-topic here ^^
11:24 < emzy> I like all the online stuff. Saves my money :) But missing the RL part.
11:25 < emzy> Yes. OT
11:28 < spiral_> V#=71Bj†wh
11:28 < pinheadmz> spiral_ now you have to change all your passwords :-(
11:28 < pinheadmz> been there
11:28 < spiral_> pfff 58 bits of entropy -- too weak for a password
11:29 < spiral_> :P     
11:29 < spiral_> rookie numbers
11:30 < spiral_> let's just say it's some magic bytes to signify something
11:58 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]     
11:59 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]     
12:19 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
12:33 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
13:00 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]     
13:01 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
13:25 -!- jaybny [~jaybny@c-73-162-160-252.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
13:31 -!- pinheadm_ [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
13:31 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Read error: Connection reset by peer]     
13:32 -!- likewhoa [~likewhoa@li1078-231.members.linode.com] has quit [Ping timeout: 240 seconds]     
13:33 -!- likewhoa [~likewhoa@li1078-231.members.linode.com] has joined #bitcoin-core-pr-reviews     
13:35 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
13:44 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection]     
14:14 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
14:14 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
14:20 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews     
14:42 -!- worc3131 [~quassel@94.4.49.118] has quit [Ping timeout: 240 seconds]     
14:43 -!- worc3131 [~quassel@2a02:c7f:c026:9500:7d0b:65d0:38a4:4786] has joined #bitcoin-core-pr-reviews     
14:48 -!- spiral_ [~spiral@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: spiral_]     
15:04 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has quit [Quit: ZNC 1.8.1 - https://znc.in]     
15:04 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
15:06 -!- ariard [~ariard@167.99.46.220] has quit [Ping timeout: 240 seconds]     
15:07 -!- ariard [~ariard@167.99.46.220] has joined #bitcoin-core-pr-reviews     
15:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
15:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
15:14 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has quit [Quit: stacie]     
15:19 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews     
15:23 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 260 seconds]     
15:37 -!- jaybny [~jaybny@c-73-162-160-252.hsd1.ca.comcast.net] has quit [Quit: jaybny]     
16:07 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
16:13 -!- pinheadm_ [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadm_]     
16:15 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
16:23 -!- ares_ [~ares@gateway/tor-sasl/virtu] has quit [Ping timeout: 240 seconds]     
16:25 -!- ares_ [~ares@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews     
16:43 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]     
16:44 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
16:48 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Client Quit]     
16:50 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has joined #bitcoin-core-pr-reviews     
16:55 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
16:57 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Client Quit]     
17:02 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]     
17:02 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews     
17:06 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
17:14 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]     
17:29 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
17:48 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews     
18:04 -!- S3RK [~s3rk@47.246.66.115] has quit [Ping timeout: 260 seconds]     
18:05 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]     
18:17 -!- tralfaz [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
18:20 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 240 seconds]     
18:20 -!- tralfaz is now known as davterra     
18:21 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
18:25 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds]     
18:35 -!- dante [~dante@2001:41d0:8:4c56::1] has joined #bitcoin-core-pr-reviews     
18:37 -!- dante is now known as d4nte     
18:38 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Ping timeout: 265 seconds]     
18:40 -!- d4nte is now known as dante     
18:40 -!- dante is now known as d4nte     
18:43 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
18:45 -!- d4nte [~dante@2001:41d0:8:4c56::1] has quit [Quit: WeeChat 2.9]     
18:45 -!- dante [~dante@2001:41d0:8:4c56::1] has joined #bitcoin-core-pr-reviews     
18:47 -!- dante [~dante@2001:41d0:8:4c56::1] has quit [Client Quit]     
18:47 -!- d4nte [~dante@2001:41d0:8:4c56::1] has joined #bitcoin-core-pr-reviews     
19:05 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]     
19:06 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews     
19:47 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Read error: Connection reset by peer]     
19:49 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
20:12 -!- tralfaz [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
20:12 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Disconnected by services]     
20:13 -!- tralfaz is now known as davterra     
20:26 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]     
20:43 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
20:55 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
21:06 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews     
21:20 -!- rjected_ [~dan@pool-71-184-77-198.bstnma.fios.verizon.net] has quit [Ping timeout: 258 seconds]     
21:34 -!- da39a3ee5e6b4b0d [~textual@n11211935170.netvigator.com] has joined #bitcoin-core-pr-reviews     
21:43 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection]     
21:50 -!- S3RK [~s3rk@47.246.66.115] has joined #bitcoin-core-pr-reviews     
21:57 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
22:00 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
22:10 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
22:12 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]     
22:14 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 258 seconds]     
22:52 -!- S3RK [~s3rk@47.246.66.115] has quit [Remote host closed the connection]     
23:07 -!- tralfaz [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
23:09 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 240 seconds]     
23:35 -!- sharknado9000[m] [sharknado9@gateway/shell/matrix.org/x-qqahyttnvzclanjx] has quit [Quit: killed]     
23:41 -!- sharknado9000[m] [sharknado9@gateway/shell/matrix.org/x-llwrxglwyjvtzzrk] has joined #bitcoin-core-pr-reviews