--- Day changed Wed Jul 01 2020 00:30 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 246 seconds] 00:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 01:49 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 01:57 -!- jungly [~jungly@host-80-117-253-7.retail.telecomitalia.it] has joined #bitcoin-core-pr-reviews 02:06 -!- slivera [~slivera@103.231.88.30] has joined #bitcoin-core-pr-reviews 02:14 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 02:26 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 02:32 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 02:35 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 02:35 -!- vasild_ is now known as vasild 03:05 -!- Abel38Mayer [~Abel38May@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:09 -!- Abel38Mayer [~Abel38May@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds] 03:39 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 246 seconds] 03:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 03:52 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 03:55 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 258 seconds] 03:59 -!- reallll is now known as belcher 04:35 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 04:49 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 04:52 -!- Landryl [~Landryl@ns528256.ip-192-99-10.net] has quit [Quit: Ping timeout (120 seconds)] 04:53 -!- Landryl [~Landryl@ns528256.ip-192-99-10.net] has joined #bitcoin-core-pr-reviews 04:55 -!- MasterdonX [~masterdon@94.126.172.60] has joined #bitcoin-core-pr-reviews 04:58 -!- masterdonx2 [~masterdon@94.126.172.60] has quit [Quit: ZNC 1.7.5 - https://znc.in] 05:01 -!- Landryl [~Landryl@ns528256.ip-192-99-10.net] has quit [Quit: Ping timeout (120 seconds)] 06:16 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 06:22 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in] 06:22 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 07:24 -!- emzy [~quassel@unaffiliated/emzy] has quit [Ping timeout: 272 seconds] 07:25 -!- emzy [~quassel@raspberry.emzy.de] has joined #bitcoin-core-pr-reviews 07:37 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 07:38 -!- tarboss [~tarboss@p54a030ce.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 07:39 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 08:05 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 246 seconds] 08:07 -!- emzy [~quassel@raspberry.emzy.de] has quit [Changing host] 08:07 -!- emzy [~quassel@unaffiliated/emzy] has joined #bitcoin-core-pr-reviews 08:11 -!- jonatack [~jon@184.75.221.3] has joined #bitcoin-core-pr-reviews 08:34 -!- slivera [~slivera@103.231.88.30] has quit [Remote host closed the connection] 08:54 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 08:56 < pinheadmz> autogen / configure / make -- when you pull a PR branch to build locally do you always have to do all 3? 08:56 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 240 seconds] 08:57 < pinheadmz> I had a missing symbol error just now but i wasn't sure how much i need to re-do when I switch branches 08:57 -!- Davterra [~tralfaz@104.200.129.62] has quit [Remote host closed the connection] 08:59 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 09:00 < jonatack> pinheadmz: you can often get away with just make if no need to change your configuration, compiler, or build type (fuzzing) 09:01 < jonatack> but if any issue don't hesitate to start with a clean slate with make clean or make distclean and the rest 09:01 < jonatack> don't hesitate to refer to https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests ... i keep it updated 09:02 < pinheadmz> this is great thanks 09:02 < jonatack> ta! goodnight. will see if anyone is around in exactly 11 hours for the second session 09:08 < jonatack> (correction, in 12 hours :) 09:15 -!- jonatack [~jon@184.75.221.3] has quit [Ping timeout: 240 seconds] 09:18 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 09:24 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 09:26 -!- Davterra [~tralfaz@104.200.129.62] has joined #bitcoin-core-pr-reviews 09:36 -!- jungly [~jungly@host-80-117-253-7.retail.telecomitalia.it] has quit [Remote host closed the connection] 09:36 -!- lightlike [~lightlike@p200300c7ef180e008912867bc47f2576.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 09:36 -!- jungly [~jungly@host-80-117-253-7.pool80117.interbusiness.it] has joined #bitcoin-core-pr-reviews 09:36 -!- jungly [~jungly@host-80-117-253-7.pool80117.interbusiness.it] has quit [Remote host closed the connection] 09:37 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 246 seconds] 09:39 -!- figs [592e3e25@89.46.62.37] has joined #bitcoin-core-pr-reviews 09:47 -!- gleb1010 [c113e45e@193.19.228.94] has joined #bitcoin-core-pr-reviews 09:47 < gleb1010> My IRC setting is broken so I'm using some random online service today, hope to not get disconnected during the meeting I'm driving :) 09:48 -!- troygiorshev [~troygiors@72.136.120.222] has joined #bitcoin-core-pr-reviews 09:52 < emzy> Driving and texting is not good. Even if it is IRC. 09:53 < gleb1010> :-) 09:54 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews 09:55 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews 10:00 < jnewbery> #startmeeting 10:00 < jnewbery> hi 10:00 < emzy> hi 10:00 < gleb1010> hi 10:00 < troygiorshev> hi 10:00 < willcl_ark> hi 10:00 < pinheadmz> hi 10:00 < figs> hi 10:00 < amiti> hi 10:00 < jnewbery> Hi folks! Today we're going to be looking at a part of the p2p network that we haven't looked at before: address discovery and gossip. 10:01 < jnewbery> Or in other words: how a node learns about potential new peers to connect to. 10:01 < michaelfolkson> hi 10:01 < lightlike> hi 10:01 < jnewbery> Notes and questions in the normal place: https://bitcoincore.reviews/18991.html 10:01 < jnewbery> We're lucky to have the PR author hosting today. So without any more delay, I'll hand over to gleb1010. 10:01 < sipa> hi 10:01 < gleb1010> Hi again all! Hope we have a productive hour 10:01 < gleb1010> I saw some useful review comments from participants, but let’s check with everyone. 10:01 < gleb1010> Have you reviewed the PR? Y/n 10:01 < willcl_ark> y 10:01 < pinheadmz> y 10:01 < troygiorshev> y 10:01 < amiti> y 10:01 < lightlike> y 10:01 < jnewbery> y 10:02 < emzy> y/n 10:02 -!- primal [~primal@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 10:02 < gleb1010> That's impressive :) 10:02 < gleb1010> You are feel free to ask any questions at any time, but let’s start with the notes we posted on the website. 10:02 < gleb1010> Let's first discuss this 10:02 < gleb1010> What is the importance of ADDR relay and specifically the GETADDR/ADDR protocol? 10:03 < pinheadmz> gleb1010 its for network nodes to discover new peers 10:03 < emzy> Asking a peer for more other peers. 10:03 < andrewtoth> hi 10:03 < gleb1010> Right, so since Bitcoin operates over a peer-to-peer network, it's essential for everyone to know somebody else from the network 10:03 < pinheadmz> there are also DNS seeds, and I think a hard-coded list of peers (?) for bootstrapping 10:04 < nehan_> hi 10:04 < gleb1010> pinheadmz: right, there are several ways to learn about other nodes in the network 10:04 < emzy> even a DNS seed uses ADDR to find nodes. 10:05 < pinheadmz> emzy true but to get a list of those peers from the seeder its actually DNS protocol 10:05 < willcl_ark> hmmmm, just thinking out loud - does this PR affect DNS nodes' responses at all? (I've not looked at the dnsseeder code) 10:05 < gleb1010> DNS internals always felt a bit obfuscated to me, so if you're somewhat confused, you're not alone :) 10:06 < gleb1010> Nope, I don't think they affect those responses, but maybe sipa can confirm? 10:06 < michaelfolkson> How were those hard-coded peers chosen? Are they regularly checked for uptime etc? 10:06 < willcl_ark> seems like https://github.com/sipa/bitcoin-seeder doesn't query Core, so I guess not! 10:06 < gleb1010> Pieter runs one out of 6 DNS seeds we have, so that the very new nodes know how to learn about each other 10:06 < gleb1010> michaelfolkson: I believe Wladimir maintains the list. 10:06 < sipa> do does emzy 10:07 < gleb1010> Well, hard-coded peers are updated within regular release process. 10:07 < emzy> willcl_ark: it connects direcly via p2p to a node to ask. No local bitcoind is running. 10:07 < sipa> michaelfolkson: see https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md 10:07 < gleb1010> So I think if you look hard enough you can find a PR with that list 10:07 < willcl_ark> emzy: thanks, 10:07 < gleb1010> Okay this one is really interesting. 10:07 < gleb1010> Which properties of ADDR relay are important? 10:08 < gleb1010> We know that blocks should be relayed faster, we know that transactions should be more or less unlinkable to IP 10:08 < michaelfolkson> sipa: Thanks 10:08 < willcl_ark> Ideally, you want to get a diverse list of peers 10:08 < pinheadmz> and you want peers with good uptime or at least "seen" recently 10:08 < jnewbery> emzy: DNS seeds actually use DNS 10:08 < gleb1010> Right, one way to look at it is to consider an individual node's AddrMan, not cross-network relay. 10:09 < jnewbery> here: https://github.com/bitcoin/bitcoin/blob/ffa70801dab7fa85c24fd5d19ca998e0910238d5/src/net.cpp#L1681-L1682 10:09 < gleb1010> Every node wants to have a good up-to-date list of nodes in their AddrMan. 10:09 < jnewbery> if DNS fails, we connect using P2P and send a GETADDR (here: https://github.com/bitcoin/bitcoin/blob/ffa70801dab7fa85c24fd5d19ca998e0910238d5/src/net.cpp#L1691-L1694) 10:10 < emzy> jnewbery: it answers via DSN but it has to crawl the nodes via p2p 10:10 < gleb1010> This is where we ideally should talk about unsolicited self-announcements which propagate ADDRs across the network, but let's leave that for homework 10:10 < gleb1010> Let's see what's this parallel discussion is about :) 10:10 < lightlike> so this change might influence DNS seed indirectly. If the DNS seeder regularly scrapes to get new addresses (and deliver them via DNS) and it gets cached responses in the future, it might introduce some kind of inertia to changes in the network. 10:10 < emzy> s/DSN/DNS/ 10:11 < gleb1010> emzy is curious how DNS servers actually learn about the nodes they gonna feed to nodes querying them 10:11 < gleb1010> or maybe not curious but he makes a statement :) 10:11 < sipa> emzy runs a DNS seed 10:11 < willcl_ark> lightlike: but the cached responses will be different from each node 10:11 < jnewbery> emzy: I'm not sure what you mean by crawl the nodes, but it gets its list of potential peers by DNS 10:12 < lightlike> willcl_ark: true, so probably not noticeably 10:12 < sipa> jnewbery: the DNS seeder itself, not the client 10:12 < sipa> jnewbery: it has to get the list of good IP addresses it serves from somewhere 10:12 < gleb1010> This is true. If everything is cached, the records everywhere become a bit older (within 1 day) 10:12 < sipa> to do so, it crawls the network using the P2P protocol 10:12 < pinheadmz> anyone can do a quick experiement to query the DNS seed nodes: `dig seed.bitcoin.sipa.be` 10:12 < pinheadmz> returns a list of A records 10:13 < sipa> you can get IPv6 ones using dig -t AAAA seed.bitcoin.sipa.be 10:13 < troygiorshev> pinheadmz: thx 10:13 < emzy> tnx sipa, that was my point. 10:13 < gleb1010> Okay, so we can talk about the impact a bit more now 10:13 < willcl_ark> so I think this doesn't affect the DNS seeds 10:13 < gleb1010> How we should look at the threat of everyone gets a bit older AddrMan records? 10:14 < gleb1010> Like, let's say a node gets 1000 records, but 500 of them were updated since the last cache 10:14 < michaelfolkson> That is a threat? Or just an inefficiency? 10:14 < troygiorshev> will this make it more difficult for a new node to get a diverse set of peers? 10:14 < willcl_ark> less than 24h should not be too much of a problem (unless node churn is very bad) 10:14 < gleb1010> Right, so I remember a research paper from Till Neudecker showing that churn in our network is really low 10:15 < jnewbery> ah, I understand. Thanks 10:15 < emzy> gleb1010: It will take longer for new nodes to be discoverd by others. 10:15 < jnewbery> yes. I thought emzy was talking about 'DNS seed connections' rather than 'DNS seeders'. All clear now! 10:15 < lightlike> troygiorshev: it will probably introduce a delay until you get new inbound peers. 10:15 < sipa> fwiw, my dns seeder software will generally visit every node it knows about in the network every few hours 10:15 < willcl_ark> https://dsn.tm.kit.edu/bitcoin/ these guys measure (some) churn 10:15 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 260 seconds] 10:15 < sipa> so this will impact it, but not much i think, given the low churn 10:15 < gleb1010> That's a great link above, it has so many things, save and take a look later :) 10:16 < gleb1010> sipa: So the point is, some of the records might have an older timestamps, but they will probably be still alive? 10:16 < gleb1010> And they won't be garbage in our AddrMan 10:17 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews 10:17 < gleb1010> Okay, let's move forward. 10:17 < pinheadmz> gleb1010 are the timestamps in addrman updated with every message from the peer? or just once on connection? 10:18 < gleb1010> pinheadmz: it's a bit complicated there, afaik it's different for inbound/outbounds 10:18 < gleb1010> For one of them it's every message, for another it's when they connect. We also update based on unsolicited ADDRs... 10:19 < gleb1010> But yeah, the expectations of these timestamps are a bit vague right now, probably that's an area of future improvements. 10:19 < emzy> If an attacker has like 1000 ipv4 addresses this PR would not mitigate the attack? 10:20 < gleb1010> There is no *the attack* :P 10:20 < amiti> pinheadmz: I found the coinscope paper interesting bc it used the timestamps to figure out network topology (link: https://www.cs.umd.edu/projects/coinscope/coinscope.pdf) 10:20 < gleb1010> Yeah coinscope is great! 10:20 < troygiorshev> pinheadmz: fwiw if you feel like looking into the history, it was apparently changed in version 0.10.1 10:20 < gleb1010> Let's get to attacks. 10:20 < willcl_ark> What I am interested to know is, how does the previous (current) ADDR response give away your connected vs disconnected peers? Unless disclosing is a security risk OFC 10:20 < amiti> idk how much the code has changed since then, but gave me an idea of the complexity 10:20 < gleb1010> In the PR, I was a bit vague about the attacks, because it's always a bit sensitive. 10:21 < emzy> gleb1010: or privacy leak 10:21 < willcl_ark> Also an acceptable answer :) 10:21 < gleb1010> But the coinscope paper is one example of exploiting it to infer direct links between nodes. 10:21 < gleb1010> Another leak is to map Tor identity to ipv4 identity of the same node. If we scrape everything and compare all timestamps, it's very easy to tell it's the same entity. 10:21 < pinheadmz> we've talked about eclipse attacks in review club before as well - it could be used by an atacker to check on their success maybe 10:22 < gleb1010> Anybody got some time to think of any other vectors? 10:22 < michaelfolkson> You mentioned linking Tor and IP addresses 10:22 < amiti> I was wondering how a spy could go from knowing addrman to figuring out the network topology, the coinscope paper uses the timestamps. is that the main way or are there others? 10:22 < gleb1010> pinheadmz: right, it's great to remember that most of researchers seem to feel that topology should be private/obscured for security reasons :) 10:22 < michaelfolkson> And then there's linking Bitcoin nodes to Lightning nodes ;) 10:23 < gleb1010> amiti: Great question! Timestamps is what I was always thinking too. 10:23 < willcl_ark> So from that paper it seems "recent and unique" timestamps (might) give it away 10:23 < gleb1010> willcl_ark can you elaborate? 10:23 < sipa> i would expect there are ways to introduce randomly generated IPs in the network, broadcast them on certain incoming connections, and then observing which other peers know about them 10:24 < willcl_ark> I'm not sure, but perhaps if we hear of a peer from another peer, we have the same timestamp, but if we connect ourselves, we get a unique timestamp 10:24 < willcl_ark> so if you see the same timestamp from a few peers we can't tell, but you give me a unique and recent timestamp, we can infer you are connected directly to them 10:24 < troygiorshev> sipa: ah like putting rubber ducks in a river and seeing where they end up 10:24 < gleb1010> My first idea was to just track the "self-announcements" 10:25 < gleb1010> Nodes sometimes announce themselves to their direct peers 10:25 < sipa> michaelfolkson: lightning node have an explicit public identity, so i'm not sure what there is to link 10:25 < gleb1010> And those timestamps will be very distinct 10:25 < gleb1010> sipa: link lightning node to a bitcoin ip or onion leads to issues, see our time-dilation attacks paper :) 10:25 < michaelfolkson> But you don't always know the Bitcoin full node that the Lightning node is using 10:26 < sipa> ok 10:26 < gleb1010> Alright, there are couple ideas to exploit this above 10:26 -!- Netsplit *.net <-> *.split quits: wallet42, jnewbery, gleb, MasterdonX, mol, rjected, primal 10:26 < gleb1010> Perhaps someone comes up with something even cooler than we can think of 10:26 < gleb1010> And maybe not much fixed by caching :) 10:26 < pinheadmz> gleb1010 this cache applies to all your peers? 10:26 < pinheadmz> so within 24 hours, every node that GETADDR from the same network get the same response? 10:26 < sipa> oh no, a netsplit 10:27 < pinheadmz> otherwise you could sybil a node and just get all the addrs anyway 10:27 < gleb1010> pinheadmz: yes, same cache per the network of request originator 10:27 < willcl_ark> i think the cache would be different for each peer, like the mempool 10:27 < gleb1010> Except white-listed requestor 10:27 < gleb1010> sipa: huh? 10:27 < sipa> gleb1010: on IRC, now, in this channel 10:28 < sipa> we lost jnewbery and others 10:28 < gleb1010> ah i see :) 10:28 < gleb1010> this happens from time to time 10:28 < gleb1010> My handbook doesn't have instructions for this... 10:28 < michaelfolkson> A network partition 10:28 < sipa> haha 10:28 < gleb1010> I think that subnet is in good hands of jnewbery 10:28 < willcl_ark> hard forked them off 10:28 < gleb1010> okay so the discussion above was 10:29 < gleb1010> I suggest using a separate cache for different network origin, and someone above pointed out why it is useful 10:29 -!- Netsplit over, joins: gleb, jnewbery, MasterdonX, mol, wallet42, rjected, primal 10:29 < gleb1010> Welcome back! 10:29 < gleb1010> Alright, let's try to merge back to the notes 10:30 -!- jnewbery_ [4a48f1f1@cpe-74-72-241-241.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews 10:30 < michaelfolkson> In the time you were away we eclipsed all your peers 10:30 < gleb1010> We sort of discussed the severity of the attacks 10:30 < gleb1010> Leaking the topology can eclipsing a node easier, also spying easier 10:30 < gleb1010> Also stealing funds from Lightning... many things 10:30 < gleb1010> Anything else? 10:31 < michaelfolkson> Privacy attacks 10:31 < willcl_ark> elcipse of lightning light clients (e.g. Neutrino) seems like a particularly severe one 10:31 < gleb1010> Well, part of the issue is that Neutrino's p2p stack is poor, so I'm not sure it's a good motivation for a Bitcoin Core change haha 10:31 < willcl_ark> but i guess it all comes back to the same base-layer eclipse 10:31 < willcl_ark> sure! 10:32 < gleb1010> Anyone looking for some little work should consider helping to mature Neutrino implementation 10:32 < gleb1010> With the experience we're getting while working on this stuff :P 10:33 < gleb1010> Yeah, so basically eclipse attacks are the worst probably (and netsplits, which is sort of an eclipse too but large scale)... 10:33 < gleb1010> You can do what you want with your victim, so we don't want that. 10:33 < gleb1010> Bringing us to the question... does this PR really help? 10:33 < pinheadmz> i guess if you got enough addrs from enough nodes you could uncover who the critical nodes are 10:33 < gleb1010> (to hide local and global topologies) 10:33 < pinheadmz> like, nodes with the most connections, potential attack points 10:34 < gleb1010> pinheadmz: Right, it would be easier to split the net if one kills the bridges, but hopefully our graph is random enough so that's not very helpful :) 10:34 < amiti> does netsplit = network partition? 10:34 < primal> not sure if it came across but I had the following comment during the netsplit 10:34 < primal> is the PR not shifting the attack strategy to gain topology information from an attacker being rate limited to the attacker spinning up a botnet? 10:34 < primal> I haven't worked through how peering dynamics and rate limiting ADDR will evolve, but ^^ is a gut-reaction check 10:34 < gleb1010> amiti: yeah 10:34 < willcl_ark> it appears that it might slow down the attack to the extent that peers get new connections etc. so that wouldn't be so effective 10:34 < nehan_> gleb1010: it slows the attacker down 10:34 < gleb1010> Right. This PR just makes an attacker spend way more time on learning what they want to learn. 10:34 < willcl_ark> at pretty minimal cost to "freshness" of ADDR responses 10:35 < troygiorshev> I'm worried that it simply delays learning the topology, but i'm not sure 10:35 < gleb1010> I never bothered to measure the exact attack delay we may introduce 10:35 < lightlike> primal: you can connect with as many bots that you want, all will get the same cached response for a while. 10:35 < gleb1010> Because I have other ideas on the way to improve the privacy :) 10:35 < gleb1010> Let's think of how we can improve this stuff even further? 10:35 < pinheadmz> is there a drawback where a new node with maxinbound 1000 wont actually get any new inbounds for up to 24 hours? 10:36 < primal> lightlike ahh ok so the cache reduces the set of info that we allow to leak out of our node 10:36 < gleb1010> Anything crazy creative works, let's discuss ideas 10:36 < michaelfolkson> Sometimes delays are all you can do troygiorshev. Make it unviable to do unless extremely targeted victim 10:36 < gleb1010> primal! Right. And also the indicators=timestamps are a little "outdated" 10:36 < willcl_ark> primal: I guess it's like "leak rate" 10:36 < gleb1010> pinheadmz: not sure I follow. 10:36 < primal> "topology disclosure rate" or something of the sort 10:36 < gleb1010> What this has to do with inbound limit? 10:37 < jnewbery> pinheadmz: it'll reduce how quickly other nodes learn about your address in the first 24 hours, but won't eliminate it entirely 10:37 < emzy> gleb1010: what about randomness in the last seen time? 10:37 < pinheadmz> jnewbery right, just a delay. and for inbounds its like "eh, your loss" 10:37 < jnewbery> because each node's cache is updated at a different time 10:37 < willcl_ark> pinheadmz: you should get 1000 different cached responses from all of those peers, so you should be fine 10:37 < primal> emzy: you don't want randomness, you want to chop the information at a certain bit 10:37 < gleb1010> emzy: this is interesting! 10:37 < jnewbery> also, be aware that there is another method of address gossipping, which is that each node will announce its own address to its peers every ~24 hours, and those peers will gossip that on to some of their peers. That method is unaffected by this PR. 10:37 < nehan_> the thing i'm trying to understand are the implications of serving stale timestamps. the timestamp logic is weird (as described in the coinscope paper, which might be out of date) 10:37 < thomasb06> is there a reverse mechanism in case of misusage: certain nodes able to overcome the privacy for example? 10:37 < gleb1010> wow this moves fast! 10:37 < emzy> primal: also vaid 10:37 < pinheadmz> willcl_ark i referring more to my own IP getting out to the network, if i have a lot of open slots to offer 10:37 < jnewbery> that there is another method of address gossipping, which is that each node will announce its own address to its peers every ~24 hours, and those peers will gossip that on to some of their peers. That method is unaffected by this PR. 10:38 < jnewbery> (https://github.com/bitcoin/bitcoin/blob/ffa70801dab7fa85c24fd5d19ca998e0910238d5/src/net_processing.cpp#L3896-L3899) 10:38 < jnewbery> (or more accurately: for each peer, once every 24 hours, we reannounce our address to that peer) 10:38 < gleb1010> jnewbery: I believe it's a bit less often than that, because there's a bloom filter in that announcement, but I have to double-check... 10:38 -!- gleb1010 [c113e45e@193.19.228.94] has quit [Remote host closed the connection] 10:38 < willcl_ark> oh no! we lost him 10:38 * sipa spawns a new gleb1010 10:39 < willcl_ark> :) 10:39 -!- tarboss [~tarboss@p54a030ce.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 10:39 -!- gleb10101 [c113e45e@193.19.228.94] has joined #bitcoin-core-pr-reviews 10:39 < pinheadmz> gleb1011 enters :-) 10:39 < michaelfolkson> I do wonder how easy/difficult it is to knock a node off the Bitcoin network 10:39 < gleb10101> Now I got forked, sorry. 10:39 < michaelfolkson> Because that's what eclipse attacks rely on right? 10:39 < gleb10101> michaelfolkson: good question! There are many ways to knock a node 10:39 < emzy> is there a problem for nodes that change evey 24h there ip address to be discoverd? Beause this is often the case by DSL/dial in connections. 10:40 < gleb10101> michaelfolkson: hopefully all those many ways are hard/expensive enough :) 10:40 < pinheadmz> jnewbery dont wanna veer too far off topic, but doesnt a node learn its own IP address from other peers? 10:40 < gleb10101> emzy: I actually didn't think about them. What would be the issue? They get less connections inbound? 10:40 -!- LarryRuane [62f5cc94@c-98-245-204-148.hsd1.co.comcast.net] has joined #bitcoin-core-pr-reviews 10:41 < jnewbery> pinheadmz: yes, I believe that's a part of it, although it's not something I've looked at too closely 10:41 < pinheadmz> emzy this is whayt i was getting to. but actually most home-run nodes probably arent accepting inbounds anyway (firewall, etc) 10:41 < emzy> gleb10101: exactly. They will be second class nodes. 10:41 < primal> pinheadmz I don't understand the significance of a node learning it's own ip add from other peers. what am I missing? 10:41 < amiti> pinheadmz, jnewbery: oh I've totally seen code in connection logic that says "if its yourself, disconnect" 😛 10:42 < pinheadmz> primal bitcoind used to actually make a request to whats-my-ip.com or something 10:42 < gleb10101> emzy: fair enough, maybe you should think about that more and then come to the PR with the conclusions 10:42 < pinheadmz> i guess its hard for a process on your laptop to know what its internet IP truly is 10:42 < jnewbery> amiti: that's something slightly different, and is detected by including a random nonce in the VERSION message 10:42 < emzy> pinheadmz: I think this is the case. 10:42 < gleb10101> emzy: wondering if that's the scenario we're targeting 10:42 < gleb10101> Alright, I asked about the alternative solutions, I was about to share one :) 10:42 < emzy> gleb10101: good question. 10:42 < gleb10101> Just to throw this another idea, we don't have to discuss it. 10:43 < gleb10101> I wanna implement self-announcement on feeler connection with some probability. 10:43 < amiti> jnewbery: oh, interesting. ok thanks 10:43 < primal> pinheadmz are you saying that bc a node can learn its ip addr from peers that removes the need to communicate with other services? 10:43 < gleb10101> We do connect to some node in the network every 2 minutes just to see if they're alive, might as well ask them to relay our addr. This would obfuscate it even further 10:43 < pinheadmz> primal right or more sepciifcally centralized services that arent even bitcoin related...ill try to find the PR its an old one 10:43 < gleb10101> Maybe someone gets any ideas like this for future PR :) 10:44 < sipa> bitcoin core used to query some "find my ip" website in a long-gone past 10:44 < jnewbery> gleb10101: what do you mean by 'obfuscate' in this context? 10:44 < willcl_ark> sipa: sounds like a privacy nightmare :P 10:44 < gleb10101> jnewbery: Coinsope and my own idea initially was to 1. scrape AddrMan often 2. infer inbounds by new records/special timestamps 10:44 < sipa> willcl_ark: yes indeed 10:45 < pinheadmz> sipa right, and then that website turned into a real estate site or something, was bascially getting ddosed by bitcoin network :-P 10:45 < gleb10101> jnewbery: so now these new records/special timestamps will be not only at victim's direct peers and their peers, but also at random feelers 10:45 < gleb10101> Yeah, this is an interesting story how we moved from that website... 10:45 < willcl_ark> could nodes use a random offset for the timestamp when serving (or storing) ADDR 10:46 < willcl_ark> then _nobody_ would ever have the same 10:46 < gleb10101> willcl_ark: this is what greg maxwell told me we already do when I discovered this issue a year ago haha 10:46 < gleb10101> But then I don't think we do randomize them 10:46 < gleb10101> So that was some phantom feature 10:46 < willcl_ark> :) But we should! 10:47 < gleb10101> So the idea is to randomize a timestamp on every ADDR sending 10:47 < gleb10101> This will help with some issues... 10:47 < pinheadmz> https://github.com/bitcoin/bitcoin/pull/3088 dont use 3rd party IP services 10:47 < gleb10101> willcl_ark tracking occurence of new records in AddrMan still would be possible 10:47 < emzy> the randomness may be the less invasive for the P2P network. 10:48 < amiti> fundamental question: what is the intended purpose of the ADDR timestamps? I saw logic that used this info to not relay old addrs. is that the main reason? 10:48 < gleb10101> amiti: yeah I believe so. 10:48 < primal> pinheadmz 845c86d128fb97d55d125e63653def38729bd2ed 10:49 < willcl_ark> gleb10101: hmmmm, interesting 10:49 < gleb10101> I believe every time we get an ADDR, we would deprioritize it if it's 1 week old 10:49 < primal> ah yeah you linked it 10:49 < gleb10101> Okay, we have 10 minutes left 10:49 < gleb10101> I was about to ask about side-effects, but we actually discussed them :) 10:49 < gleb10101> But someone can highlight a side-effect of their concern again 10:50 < gleb10101> Or just ask any other question? 10:50 < willcl_ark> I was wondering about setting ADDR as a default for whitebind 10:50 < jnewbery> There was a suggestion in https://github.com/bitcoin/bitcoin/pull/16442 to dynamically change the local service bits depending on whether the compact block filter index was built. It was argued that because it would only ever go from false to true, that would be ok. 10:50 < pinheadmz> is there any way an ADDR message cahced response could be used to identify a node? if you get the same response from nodes running on two IPs for example? 10:50 < willcl_ark> it doesn't really make much difference as you specify in config, but... 10:50 < nehan_> I asked earlier about the implications of serving stale timestamps but that might have gotten lost in the fork and/or I didn't see the answer 10:51 < jnewbery> I think if nodes start randomizing timestamps that's no longer true. You could get an old address record with a newer timestamp than the (actually) newer address record 10:51 < gleb10101> nehan_: We don't want to spend days digging into outdated nodes and finding a live one... 10:51 < nehan_> or think that nodes are stale that aren't actually stale 10:51 < gleb10101> And we don't want to spend bandwidth relaying old non-live nodes 10:52 < michaelfolkson> I was listening to ariard on TFTC and he was saying it needs a similar level of resource to secure P2P for Neutrino or Lightning as it does secure P2P on Core. Had never thought of it like that before 10:52 < nehan_> with this change, where a node might have served a fresh timestamp it would now serve one that was 27 hours old 10:52 < gleb10101> pinheadmz: yeah, but I don't know how to address this issue :) 10:52 < michaelfolkson> I just assumed Core would take the brunt of addressing a lot of the P2P attacks on Neutrino/Lightning indirectly 10:52 < gleb10101> nehan_: true, but in the beginning of the meeting we sort of considered that 1-day old is probably fine. 10:53 < gleb10101> We should be talking about at least several-days lag for it to be bad. Although it's a bit arbitrary and depends on many things. It's more of an intuition 10:54 < nehan_> gleb10101: doesn't that sort of imply we don't need to update timestamps frequently? 10:54 < sipa> jnewbery: i feel that with feelers this is less of an issue, as they will always overwrite the flags data with the actual flags 10:55 < sipa> (i need to check if feelers actually override flags) 10:55 < amiti> re timestamps and addr relay: I still don't understand how its _really_ helping. as a recipient you are able to assign likelihood-of-node-being-live if the sender is being honest in the reported timestamps. if thats the case, why not just have honest nodes proactively only send addrs of recently-tested-conns? 10:55 < gleb10101> nehan_: define frequently :) Records should be at most couple days old. We currently don't need better freshness. 10:55 < gleb10101> We don't know how to distinguish 3 days old from 1 day old. The code doesn't. 10:56 < willcl_ark> presumeably you could just also make the timstamp up, if you were so inclined 10:56 < gleb10101> I mean, we can distinguish, but we don't do anything with it, sorry. 10:57 < gleb10101> amiti: Right, maliciously updating timestamps attack is one of my todos :) 10:57 < gleb10101> That's also why any fine-grained optimization of being alive is dangerous. 10:57 < gleb10101> It's free to bump for an attacker to bump their timestamp 10:58 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 10:58 < pinheadmz> is there any banscore type thing if a node sends us 1000 ADDRS and none of them work ?! 10:58 < gleb10101> Meaning we don't want to rely on timestamps too much... 10:58 < amiti> gleb: huh? like explore the feasibility of attack? 10:58 < jnewbery> sipa: I think we do. We call SetServices() when we receive the version, and then disconnect 10:58 < sipa> pinheadmz: we won't know they don't work until days, maybe weeks later 10:58 < gleb10101> pinheadmz: nope. I mean, we don;t want checking 1000 nodes at once :) 10:58 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 10:59 < gleb10101> amiti: we're out of time it seems, hit me up later :) 10:59 < pinheadmz> sipa gleb10101 right, and no real pain y trying to connect to bad nodes 10:59 < pinheadmz> well great work on this gleb10101 very simple to understand and makes a lot of sense 10:59 < troygiorshev> yeah thanks gleb10101! 11:00 < gleb10101> Thank you! For those haven't look at the code it's actually few lines so please review :P 11:00 < willcl_ark> thanks gleb10101 11:00 < emzy> thanks gleb10101! 11:00 < andrewtoth> thanks gleb10101! 11:00 < lightlike> thanks! 11:00 < jnewbery> pinheadmz: and that's a more general problem. How do we 'punish' a node for giving us bad data? Looking at orphan processing and mapBlockSource is left as an exercise for the reader :) 11:01 < gleb10101> #endmeeting 11:01 < primal> thanks gleb10101 11:01 < jnewbery> thanks for being patient with the network issues everyone! If anyone has a full log of the meeting, can you message me so I can put it on the website? I dropped for 10 minutes in the middle 11:01 < gleb10101> I was also disconnected and get it lost, please someone help john :) 11:01 < thomasb06> thanks gleb10101 11:01 < willcl_ark> I think I have a full log 11:02 < michaelfolkson> I do too. Just copy and paste jnewbery? 11:02 < primal> I think I was on the side of the netsplit jnewbery was on 11:02 < nehan_> thanks 11:02 < jnewbery> willcl_ark: can you email them to me? 11:02 < willcl_ark> sure 11:02 < sipa> http://bitcoin.sipa.be/log.txt 11:03 -!- gleb10101 [c113e45e@193.19.228.94] has quit [Remote host closed the connection] 11:03 < willcl_ark> ^ even better! 11:03 < jnewbery> thanks sipa! 11:03 < emzy> was funny that we had the topic of bitcoin network splits and then an IRC network split. 11:03 < sipa> indeed 11:03 -!- figs [592e3e25@89.46.62.37] has left #bitcoin-core-pr-reviews [] 11:03 < sipa> fate, it seems, is not without a sense of irony 11:03 < michaelfolkson> Quick question for you sipa as you are here. Do you want someone to sort out https on your Miniscript site? 11:04 < emzy> some networks are more fragile. 11:04 < michaelfolkson> Let's Encrypt etc 11:04 -!- lightlike [~lightlike@p200300c7ef180e008912867bc47f2576.dip0.t-ipconnect.de] has quit [Quit: Leaving] 11:04 < sipa> michaelfolkson: i used let's encrypt on my site a few years ago, but then forgot about it 11:05 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 11:05 < michaelfolkson> At least for the Miniscript site it is probably worth it http://bitcoin.sipa.be/miniscript/ 11:05 < sipa> it's definitely worth it for the whole site, but i'm lazy :) 11:05 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 11:06 < michaelfolkson> Haha with the different stuff you are involved in I'm not buying that 11:08 -!- LarryRuane [62f5cc94@c-98-245-204-148.hsd1.co.comcast.net] has quit [Remote host closed the connection] 11:09 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Client Quit] 11:09 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 11:12 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Client Quit] 11:13 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 11:14 * primal wonder's if the javascript code that runs on my computer when visiting sipa http://bitcoin.sipa.be/miniscript/ has been MITM 11:14 < primal> :P 11:16 -!- jnewbery_ [4a48f1f1@cpe-74-72-241-241.nyc.res.rr.com] has quit [Remote host closed the connection] 11:27 -!- troygiorshev [~troygiors@72.136.120.222] has quit [Read error: Connection reset by peer] 11:37 -!- primal [~primal@195.181.160.175.adsl.inet-telecom.org] has left #bitcoin-core-pr-reviews [] 11:47 -!- Till49 [59f7ff11@i59F7FF11.versanet.de] has joined #bitcoin-core-pr-reviews 11:47 -!- jungly [~jungly@host-80-117-253-7.pool80117.interbusiness.it] has joined #bitcoin-core-pr-reviews 11:49 -!- Till49 [59f7ff11@i59F7FF11.versanet.de] has quit [Remote host closed the connection] 11:50 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews 11:52 -!- csknk [~csknk@unaffiliated/csknk] has quit [Client Quit] 11:58 -!- fodediop [~fodediop@41.214.92.142] has joined #bitcoin-core-pr-reviews 12:02 -!- fodediop [~fodediop@41.214.92.142] has quit [Client Quit] 12:02 -!- fodediop [~fodediop@41.214.92.142] has joined #bitcoin-core-pr-reviews 12:03 < jnewbery> Meeting log is up: https://bitcoincore.reviews/18991.html 12:04 -!- fodediop [~fodediop@41.214.92.142] has quit [Client Quit] 12:09 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:38 -!- tim [~real_or_r@173.249.7.254] has joined #bitcoin-core-pr-reviews 12:38 -!- tim is now known as Guest92810 12:45 -!- Netsplit *.net <-> *.split quits: real_or_random 13:45 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 13:46 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds] 13:58 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Remote host closed the connection] 13:59 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 13:59 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 13:59 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 14:33 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection] 14:35 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 14:59 -!- slivera [~slivera@103.231.88.30] has joined #bitcoin-core-pr-reviews 15:07 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 15:43 -!- nehan_ is now known as nehan 16:21 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 244 seconds] 16:36 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 17:24 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 18:10 -!- seven_ [~seven@2a00:ee2:410c:1300:219a:6549:f535:56b1] has quit [Ping timeout: 260 seconds] 18:53 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 19:27 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Quit: Leaving] 20:04 < jonatack> If anyone is around, we'll get started in just under an hour. 20:12 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 20:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 20:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 21:00 < jonatack> #startmeeting 21:00 < jonatack> hi 21:01 * jonatack things seem quiet 21:01 < sipa> vaguely here 21:02 < brikk> hi 21:02 < jonatack> hi! 21:03 < jonatack> So I spent some time going through the meeting log and the PR. 21:03 < jonatack> brikk: did you get a chance to review the PR? 21:04 < brikk> jonatack: unfortunately not, I was not aware of this meeting only saw activity now at a convenient time right at the start of my day :) 21:04 < jonatack> that's all good 21:04 < jonatack> this is about https://bitcoincore.reviews/18991 21:05 < jonatack> "Cache responses to GETADDR to prevent topology leaks (p2p)" 21:05 < brikk> thanks, I'm looking at it now 21:05 < jonatack> to make the ADDR/GETADDR address gossip protocol more private for the node providing addresses 21:06 < jonatack> ADDR relay and specifically the GETADDR/ADDR protocol exist for peer discovery in bitcoin's p2p network. 21:07 < jonatack> in addition to two other ways: DNS seeders which crawl the network using the p2p protocol, and hardcoded fixed seeds 21:08 < jonatack> for instance, one can run dig seed.bitcoin.sipa.be (or dig -t AAAA seed.bitcoin.sipa.be for IPv6) on the command line to see a list of A/AAAA records that seeders might provide 21:09 < jonatack> Essentially, the goal of this PR is to slow attackers down, to make them spend more time to learn local or global peer topology. 21:11 < jonatack> ADDR relay has various properties of importance. This PR seems to shift the priority among them a bit in the hope of a better tradeoff. 21:11 < jonatack> What are these properties? 21:11 < jonatack> - Privacy: hiding local and global topology, difficulty of identifying peers, or of linking transactions to IP addresses 21:11 < jonatack> - Peer diversity 21:12 < jonatack> - Decentralisation: Trust reduction with respect to the DNS seeds and the fixed seeds 21:12 < jonatack> - Speed of relay 21:12 < jonatack> - Freshness: peers having an up to date list of peers 21:13 < jonatack> - Quality: peers who are well-behaved, seen recently, with good uptime 21:14 < brikk> What does peer diversity mean? 21:14 < jonatack> For example, a tradeoff this PR would seem to be proposing is less freshness (if that is the best word; it may not be) in favor of privacy 21:14 < jonatack> or less diversity as well, possibly 21:15 < brikk> Speed of relay seems to be a tradeoff as well, right? 21:16 < jonatack> i'm not sure 21:16 < jonatack> how do you see it? 21:17 < brikk> just by looking at the comments in the review 21:17 < brikk> there's a lot of comments though and I am yet to make it til the end, so perhaps my perception will change :) 21:19 < jonatack> diversity: good question. for example, by ASN, which was a motivation for the -asmap p2p addition in the latest release of bitcoin core. 21:21 < jonatack> https://bitcoincore.reviews/16702 covered asmap and contains good resources on the various attacks: erebus, eclipse, bgp hijacking 21:22 < jonatack> sipa: do you think today's PR could adversely affect discovery of newly online peers, or ones who change IP address frequently? 21:23 < jonatack> ISTM if everything is cached, the records everywhere become a bit older (by 1 day) 21:23 < sipa> i'd need to think more about that 21:23 < brikk> right, sounds like the things amiti uttarwar was talking about in the reckless vr meetup 21:23 < jonatack> and new node discovery might be slower... but i would need to look at it more. 21:26 < brikk> jonatack: when you say new node discovery, does that mean that I bring a new node to the discovery and it would mean issues for me, or that someone else brings a new node online and the rest of the network has trouble discovering it? 21:27 < jonatack> Both? This is an aspect I'm not sure on. 21:27 < brikk> ok 21:30 < jonatack> The hard thing with p2p changes like this, to my mind, is how to simulate the effects before actually deploying on the network. 21:31 < luke-jr> it's in Knots 0.20.0 fwiw 21:31 < brikk> I agree 21:31 < luke-jr> not quite the same thing, but it's _part_ of the network that might be observable 21:32 < jonatack> luke-jr: nice. released june 14? any stats on number of nodes running that version? 21:32 < luke-jr> [04:23:42] ISTM if everything is cached, the records everywhere become a bit older (by 1 day) <-- isn't it 1 day *per hop*? 21:33 < luke-jr> jonatack: the release was June 16th, but based on June 14th PRs 21:33 < sipa> luke-jr: there are two mechanisms though; getaddr->addr, and normal addr gossipping 21:33 < luke-jr> I'm seeing only 24 nodes upgraded so far 21:33 < sipa> i don't think the second is affected by this PR but i haven't reviewed in detail 21:33 < luke-jr> sipa: ah 21:34 < sipa> and for the getaddr->addr mechanism there isn't really any concept of hops 21:34 < luke-jr> do we currently *use* getaddr as a client then? 21:35 < sipa> luke-jr: yes, under certain conditions, in response to version 21:35 < sipa> so at most once per connection 21:35 < sipa> (we also only respond once per connection iirc) 21:36 < luke-jr> looks like normally once at connection 21:36 < luke-jr> due to pfrom.nVersion >= CADDR_TIME_VERSION 21:36 < luke-jr> outbound connection* 21:37 < jonatack> CADDR always puts a smile on my face 21:38 < luke-jr> ? 21:38 < jonatack> seeing lisp in the codebase :) 21:38 < sipa> ))))))))))) 21:42 * luke-jr watches a tumbleweed roll by 21:42 < jonatack> luke-jr: "like normally once at connection" you're referring to ProcessMessage or RelayAddress? 21:42 < luke-jr> just glancing at the conditions around connman->PushMessage(&pfrom, CNetMsgMaker(nSendVersion).Make(NetMsgType::GETADDR)); 21:43 < jonatack> ah VERSION 21:43 < luke-jr> it seemed like it happens fairly normal circumstances 21:46 < jonatack> luke-jr: do you see any adverse effects from this PR? 21:46 < luke-jr> so far no 21:48 < jonatack> how did you decide to add it to knots? 21:48 < luke-jr> less than 50% of the network is running 0.19.x+, so it's not the end of the world if we discover something post-release either 21:48 < luke-jr> jonatack: Knots merge policy is very relaxed - if it won't clearly disrupt anything, it usually goes in 21:49 * jonatack looks at https://dsn.tm.kit.edu/bitcoin to see 21:49 < jonatack> luke-jr: ok 21:50 < jonatack> https://dsn.tm.kit.edu/bitcoin/#useragents 21:50 < jonatack> luke-jr: you have your own proprietary stats iirc? 21:51 < luke-jr> yes http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html 21:51 < jonatack> thakns 21:52 < luke-jr> I suppose http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html?onlylistening=1 shows 55% running recent versions 21:53 < brikk> I'm trying to wrap my head around the peer diversity: can I think of this as three nodes: nodes with an ipv4/ipv6 address that never change, nodes behind tor, nodes whose address change every 24 hours 21:53 < luke-jr> I guess a lot of 0.16.x nodes are firewalled or something 21:53 < jonatack> seems quite different from the dsn one in germany which appears to show more 0.19.x nodes 21:53 < luke-jr> jonatack: I include non-listening by default 21:53 < jonatack> got it 21:55 < jonatack> listening nodes seem to update more to the recent versions, which makes sense as they are presumably more sophisticated users 21:57 < jonatack> brikk: diversity by AS number, by IP, by geography 21:58 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 21:58 < jonatack> brikk: by uptime, recently seen 21:58 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 21:59 < jonatack> brikk: minimum ping time (i'm thinking about the criteria used in bitcoin core for potentially evicting peers) 22:00 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving] 22:01 < jonatack> brikk: recently sent us transactions or blocks 22:01 < jonatack> see CConnman::AttemptToEvictConnection in net.cpp 22:01 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 22:02 < brikk> jonatack: thanks! 22:03 < jonatack> brikk: we recently did a review club on that: https://bitcoincore.reviews/16756 22:03 < jonatack> #endmeeting 22:03 < jonatack> that's time! thanks brikk sipa luke-jr 22:05 < brikk> jonatack: thanks for hosting! I like this time slot better, although looking at the number of participants perhaps not so much? 22:05 < sipa> maybe it takes some time before people know it exists 22:06 < sipa> though i suspect it'll inevitably be less popular than the other slot 22:06 < jonatack> yes, my guess is it might be network/social effect, too... might just take time 22:07 < jonatack> kallewoof hosted a review club at this time slot a few months back which was well-attended 22:09 < jonatack> this one https://bitcoincore.reviews/17824#meeting-log--asia-time-zone 22:09 < jonatack> and even more, this one: https://bitcoincore.reviews/17824#meeting-log--asia-time-zone 22:10 < jonatack> sec 22:11 < jonatack> *this one* https://bitcoincore.reviews/16981#meeting-log--asia-time-zone 22:12 < luke-jr> kallewoof is in Japan, maybe he spread word in person 22:18 < jonatack> yes, there were the australians (aj, meshcollider, fanquake) and also murch 22:20 -!- RaviPatel [6ad59df4@106.213.157.244] has joined #bitcoin-core-pr-reviews 22:25 < meshcollider> An email chain was started for it last time 22:25 < meshcollider> That's how I found out about it 22:26 < jonatack> ah! -- good idea 22:28 * jonatack realises may have unwittingly described a new zealander as an australian 22:30 < sipa> you may have started world war 3 22:34 < brikk> it's 2020 all over again 22:35 -!- RaviPatel [6ad59df4@106.213.157.244] has quit [Remote host closed the connection] 22:35 < luke-jr> NZ is part of Australia after all 22:35 * luke-jr hides 22:48 < jonatack> Meeting log is up: https://bitcoincore.reviews/18991#meeting-log--asia-time-zone 22:59 < meshcollider> 5:30 PM you may have started world war 3 22:59 < meshcollider> Yep, just gotta wait for the border to open and we'll be off 23:00 < meshcollider> It's okay, some people don't even know NZ exists :) 23:00 < luke-jr> lol 23:06 < sipa> https://reddit.com/r/MapsWithoutNZ 23:15 < jonatack> meshcollider: sounds like an advantage. good opsec 23:34 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 23:47 < meshcollider> True. Anyway I'll join next week if you're running it again, sorry I missed it today 23:50 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews