--- Day changed Wed Jun 03 2020 02:35 -!- slivera [~slivera@103.231.88.28] has quit [Remote host closed the connection] 02:57 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 03:03 -!- Griffin73Lueilwi [~Griffin73@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:04 -!- adiabat [~adiabat@63.209.32.102] has quit [Ping timeout: 246 seconds] 03:08 -!- Griffin73Lueilwi [~Griffin73@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 260 seconds] 03:43 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Read error: Connection reset by peer] 03:43 -!- TheRec_ [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 03:43 -!- TheRec_ [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 03:43 -!- TheRec_ [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 03:48 -!- TheRec_ [~toto@drupal.org/user/146860/view] has quit [Ping timeout: 256 seconds] 04:23 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 04:59 -!- adiabat [~adiabat@63.209.32.102] has joined #bitcoin-core-pr-reviews 05:05 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Quit: Leaving] 05:52 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [] 05:52 -!- slivera [~slivera@103.231.88.10] has joined #bitcoin-core-pr-reviews 06:19 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 06:19 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 06:19 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 06:24 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Read error: Connection reset by peer] 06:24 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 06:24 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 06:24 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 06:28 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 06:29 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Remote host closed the connection] 07:12 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-isbkklkucdakpzvk] has quit [Quit: Connection closed for inactivity] 07:15 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in] 07:15 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 07:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 07:24 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 07:25 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-kwpbiqhkwszaggdi] has joined #bitcoin-core-pr-reviews 07:26 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer] 07:26 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 07:27 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 07:28 < fanquake> If anyone is bored pre-meeting, I'm looking for some review in 19088 and 18434. Will be around to answer any Qs etc for the next hour or so. 07:41 -!- KateMolly [b9ec2a4d@185.236.42.77] has joined #bitcoin-core-pr-reviews 07:42 -!- KateMolly [b9ec2a4d@185.236.42.77] has left #bitcoin-core-pr-reviews [] 08:19 -!- dr-orlovsky [~Dr_Orlovs@31.14.40.19] has quit [Remote host closed the connection] 08:20 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [] 08:20 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 08:20 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 08:20 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 08:25 -!- dr-orlovsky [~Dr_Orlovs@31.14.40.19] has joined #bitcoin-core-pr-reviews 08:30 -!- dr-orlovsky [~Dr_Orlovs@31.14.40.19] has quit [Ping timeout: 260 seconds] 08:32 -!- dr-orlovsky [~Dr_Orlovs@31.14.40.19] has joined #bitcoin-core-pr-reviews 09:02 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 09:07 -!- lightlike [~lightlike@p200300c7ef22dd0098f3a6326d8a5c7e.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 09:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 09:26 -!- riyasingh [~riyasingh@103.67.17.91] has joined #bitcoin-core-pr-reviews 09:32 -!- thomasb06 [~user@natedu100-11.unice.fr] has joined #bitcoin-core-pr-reviews 09:35 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 09:38 < michaelfolkson> Sorry I missed you fanquake. Did you want conceptual review, code review, running of tests or all of the above? 09:40 -!- riyasingh [~riyasingh@103.67.17.91] has quit [Remote host closed the connection] 09:43 -!- riyasingh [~riyasingh@103.67.17.91] has joined #bitcoin-core-pr-reviews 09:47 -!- ecurrencyholder [68ac287f@cpe-104-172-40-127.socal.res.rr.com] has joined #bitcoin-core-pr-reviews 09:48 < jnewbery> meeting starts in just over 10 minutes. Make sure you have your tea/coffee/(beer if you're pinheadmz) ready! 09:48 < pinheadmz> haha not today too much work ;-) 09:54 -!- decipher [~decipher@178.162.222.42.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 09:57 -!- tarboss [~tarboss@p54a037dd.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 09:58 < raj_149> pinheadmz: here i thought i am the only one who sits with a beer. :D The timiezone fits perfectly. Nice knowing theres solidarity. :) 10:00 < jnewbery> #startmeeting 10:00 < troygiorshev> hi 10:00 < lightlike> hi 10:00 < amiti> hi 10:00 < emzy> hi 10:00 < raj_149> hi 10:00 < michaelfolkson> hi 10:00 < jnewbery> Hi folks! Welcome to review club. Today, lightlike is going to be hosting the meeting on his PR #16756: Connection eviction logic tests. 10:00 < nehan> hi 10:01 < jnewbery> Notes and questions in the normal place: https://bitcoincore.reviews/16756.html 10:01 < jnewbery> Before we start though, I want to draw everyone's attention to the code of conduct that we added to the website last week: https://bitcoincore.reviews/code-of-conduct. Please read it! 10:01 < jnewbery> We want to make sure that PR Review Club is a safe, respectful, and productive environment for everyone. The Code of Conduct documents the behaviour we expect to ensure that's the case. 10:01 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 10:01 -!- gdejz [9d2f29b8@157.47.41.184] has joined #bitcoin-core-pr-reviews 10:01 < jnewbery> I don't think there's anything controversial in there. If you have any questions/concerns/comments, feel free to message me. 10:01 < pinheadmz> +1 for code of conduct 10:01 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 10:02 < decipher> hi 10:02 < jnewbery> With that, I'll hand over to lightlike. 10:03 < lightlike> Ok, so today will be on my PR on testing the eviction/protection logic for inbound peers. 10:03 < lightlike> I think that also the eviction algorithm in itself is quite interesting in itself. 10:03 < andrewtoth> hi 10:03 < lightlike> But let's start with the usual question - Who had a chance to review the PR? (y/n) 10:03 < raj_149> y 10:04 < troygiorshev> n 10:04 < nehan> n 10:04 -!- aco [1806aa07@c-24-6-170-7.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 10:04 < andrewtoth> y 10:04 < jnewbery> y 10:04 < gdejz> N 10:04 < amiti> mostly y 10:04 < emzy> n 10:05 -!- aco [1806aa07@c-24-6-170-7.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 10:05 < lightlike> Great - and there have been many helpful review comments so far. 10:05 < lightlike> So, moving to the first question: 10:05 < lightlike> Why is there an eviction mechanism for inbound peers, instead of simply not accepting new connections when full? 10:06 < michaelfolkson> To help bootstrap new nodes? 10:06 -!- aco [1806aa07@c-24-6-170-7.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 10:06 < raj_149> We might get better new peers than existing one? Having static peers might open risk of attacks? 10:06 < andrewtoth> To prevent an attacker from filling up all inbound slots 10:07 < decipher> preventing peering monopolization, potentially from an adversary 10:07 < troygiorshev> We ensure we're not stuck with a small (potentially malivious) subset of the network? 10:07 < amiti> it seems like we try to evict from the netgroup with the max number of connections of unprotected peers, so maybe as a method of ensuring peers across multiple netgroups? 10:08 < raj_149> quick question: what exactly is a netgroup? 10:08 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 10:08 < lightlike> I think all of these are valid reasons. 10:09 -!- gdejz [9d2f29b8@157.47.41.184] has quit [Remote host closed the connection] 10:09 < lightlike> but probably, preventing an attacker to fill the inbound slots was the main reason why eviction was introduced?! 10:10 < sipa> just in general: to try to improve the quality of inbound connections (a combination of peers that relay blocks quickly, don't misbehave, and come from a variety of networks across the world) 10:10 < sipa> when we're at our inbound connection limit, we have a choice 10:11 < sipa> or rather: we need to make a choice, and not evicting means making the implicit "first connection is best" assumption 10:11 < decipher> "prioritize peer desirability" 10:12 < michaelfolkson> raj_149: I had to look it up. Connections with certain characteristics form one netgroup https://github.com/bitcoin/bitcoin/blob/657b82cef0e8e8695fc189d013a4353bdbebb041/src/net.cpp#L895 10:12 < jnewbery> raj_149: traditionally, a netgroup was a /16 subnet. From 0.20, it can optionally be based on ASNs. See https://github.com/bitcoin/bitcoin/issues/16599 for more details 10:13 < sipa> raj_149: it's a fairly arbitrary grouping of IP addresses we make; for IPv4 it's /16 subnets, though since 0.20 it's possible to use asmap 10:13 < lightlike> ok, next question 10:13 < lightlike> Why are some peers protected from eviction? 10:13 < sipa> raj_149: the idea is that it's harder for an attacker to control many networks rather than many IP addresses in one network 10:14 < raj_149> thanks, makes sense. Will look up on it more. 10:14 < andrewtoth> The same way an attacker can fill up all inbound slots, an attacker could evict all other connections by continually connecting to a node 10:14 -!- aco [1806aa07@c-24-6-170-7.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 10:15 < jonatack> raj_149: see https://bitcoincore.reviews/16702 10:15 < michaelfolkson> And if they have proved themselves useful by providing blocks or responding to ping quickly you don't want to ditch them 10:15 < amiti> +1 andrewtoth. protecting peers from eviction based on different desired attributes increases the cost of attack to fill up all the slots. 10:16 < michaelfolkson> So you kind of want to get best of both worlds or a happy medium. Go too far in either direction and you don't get benefits of both extremes 10:16 < gzhao408> this might be a big claim, but I actually think any eviction policy that doesn't protect certain characteristics (i.e. ones that are hard to fake like minping and longest connection time) would almost guarantee that an attacker could fill up your slots 10:17 -!- ygfryh [9d2f29b8@157.47.41.184] has joined #bitcoin-core-pr-reviews 10:17 < ecurrencyholder> It's preferable to keep a connection that has proven to be reputable. By evicting it, you are opening yourself up to potentially connect to a malicious one. 10:17 -!- ygfryh [9d2f29b8@157.47.41.184] has quit [Remote host closed the connection] 10:18 -!- hdefh [9d2f29b8@157.47.41.184] has joined #bitcoin-core-pr-reviews 10:18 < lightlike> yes, i think it's a balance. we don't want to have our peers too static, but we also need to protect against attackers actively eviction other peers. 10:19 < decipher> having defined peering preferences gives an attacker the success criteria they need to meet to perform an attack -- regardless of what criteria are chosen. Our objective should be - choose the criteria which suite are desires best but also make it as costly as possible for an attacker 10:19 -!- riyasingh [~riyasingh@103.67.17.91] has quit [Remote host closed the connection] 10:19 -!- slivera [~slivera@103.231.88.10] has quit [Remote host closed the connection] 10:19 < decipher> suit our* 10:19 < nehan> decipher: +1 10:19 -!- riyasingh [~riyasingh@103.67.17.91] has joined #bitcoin-core-pr-reviews 10:19 < gzhao408> costly, and also that they're doing useful work anyway? 10:20 < gzhao408> (for some of the characteristics) 10:20 < nehan> gzhao408: i don't think usefulness is helpful. an attacker who is useful up to eclipsing you has still eclipsed you. 10:21 < jnewbery> I think amiti and decipher's point about having different criteria is very important. We obviously want to receive blocks quickly so a naive approach would be to just protect the peers that send us blocks. If we did that would it be easier or harder for an attacker to eclipse you? 10:21 -!- aco [1806aa07@c-24-6-170-7.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 10:21 < raj_149> jnewbery: seems easier, if that was the only criteria? 10:22 < decipher> easier or harder relative to which initial case 10:22 < sipa> the network serves a variety of purposes; for blocks it's partition resistance and fast relay; for transactions it's original privacy; for addresses there are eclipse attack concerns, ... 10:22 < sipa> so that means we need to select peers that are good across multiple different dimensions 10:22 < sipa> *origin privacy 10:22 -!- platesondeck [965000000@2405:8100:8000:5ca1::18:230c] has joined #bitcoin-core-pr-reviews 10:22 < gzhao408> nehan good point haha 10:23 < lightlike> next q: Can you summarize the algorithm by which the candidate for eviction is determined in AttemptToEvictConnection? 10:23 < jnewbery> decipher: compared to not just protecting block-serving peers. I think the answer is easier because a determined adversary can be a better block-serving peer than an average peer. 10:23 < michaelfolkson> nehan: They can. But you would still want to value node who has proved useful over a node who has not. 10:23 -!- platesondeck [965000000@2405:8100:8000:5ca1::18:230c] has quit [Remote host closed the connection] 10:24 < nehan> michaelfolkson: I think the issue is that if you measure nodes by how "good" they are and it's something an attacker can optimize, they can become better than average nodes and take up all the good nodes slots. I think :) 10:24 < michaelfolkson> nehan: Yeah good point 10:24 < sipa> nehan: there is a risk for a repution attack" 10:25 < raj_149> It seems focusing on any sinle character will by definition open up gamability. the only way is to have as many character as possible as criteria? 10:25 < nehan> sipa: i don't know what that means 10:25 < raj_149> *single 10:25 < sipa> nehan: an attacker can act "good" before trying to perform an attack 10:25 < nehan> sipa: yes 10:25 < sipa> which is inherently a problem without persistent identities 10:26 < sipa> on the other hand, some things can't be faked: a peer with a low ping time is close to you - it doesn't mean they're not an attacker of course 10:26 < nehan> sipa: yep or some other hard to fake mechanism + honesty assumptions 10:26 < gzhao408> lightlike: make a list of eviction candidates, sort them by characteristics and remove the top ones of each category, whittling the list down based on peers that you definitely want to protect. if you still have candidates left over, make an eviction decision? 10:26 -!- r251d [~r251d@162-196-59-192.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-core-pr-reviews 10:26 < sipa> or a peer who gives you a good block helped you and the network, regardless of their future actions 10:28 < amiti> lightlike: start by selecting eviction candidates that are inbound peers that are not on the NO BAN list or already marked for disconnect. remove the top candidates from each of the desirable categories (netgroup, ping time, recently sent txns, recently sent blocks, and the longest connected). If there are any candidates left over, choose from the netgroup with the most connections 10:28 < raj_149> is it implicite that there will always be a candidate for eviction (assuming peercount limit reached)? or it might be the case that none of them gets evicted and new connection is rejected? 10:28 < sipa> raj_149: the new connection may be the one that is evicted 10:28 < sipa> (i think, i haven't checked this code recently) 10:28 < nehan> so the idea is to optimize for metrics that are "proof of good and hard to fake behavior". like low ping times, bw usage for relaying blocks, etc. others? sort of like proof of work, ha 10:29 -!- platesondeck [965000000@2405:8100:8000:5ca1::5b7:d35a] has joined #bitcoin-core-pr-reviews 10:30 < nehan> random probably wrong thought: maybe more expensive the behavior is, the more it should be weighted 10:30 < lightlike> gzhao, amiti: right! we also preferably evict peers that are undesirable (HasAllDesirableServiceFlags) 10:31 < decipher> should we discuss the protected_peers weightings? 10:31 < gzhao408> I think it's important that it's not just favoring some but /protecting/ them - that's why we remove them from the list so even if a node is both a long-lasting connection and has short ping times we consider the same number regardless of overlap. and to nehan's point, the more expensive behavior comes at the end 10:32 < nehan> gzhao408: yeah i think i spoke too soon before, you are right that useful work is helpful especially if costly 10:32 -!- hdefh [9d2f29b8@157.47.41.184] has quit [Remote host closed the connection] 10:32 < lightlike> raj_149: I'm not sure how we would not find a candidate - if we have maxconnections large enough that that there are more than the fixed 20 peers (4 block +4 tx + 4netgroup +8 ping). 10:33 < raj_149> IMO weighting might be problematic as an attacker then gets higher probabailty to get into protected sets by playing good just before the attack? 10:33 < troygiorshev> i'm not sure i follow precisely what the attack is, can anyone give a quick summary? 10:33 < raj_149> lightlike: i was also thinking the same. Seems like it will always find a peer to evict. 10:33 < sipa> i think it's important that this is not just a score that maps all criteria onto a single value 10:34 -!- platesondeck [965000000@2405:8100:8000:5ca1::5b7:d35a] has quit [Remote host closed the connection] 10:34 < sipa> you want to keep the best peers according to many different criteria, so that an attacker has to beat your other peers in all those criteria 10:34 < michaelfolkson> These eviction policies in the test are a simplified version of the eviction policies in the actual codebase right? 10:34 < decipher> should have phrased it as protected_peers allocation not creating a score 10:35 < raj_149> michaelfolkson: only the netgrouping part. rest of the criteria are being tested as it seems. 10:37 < lightlike> ok, moving on to the test: Why does the test choose maxconnections=32? 10:38 < gzhao408> I don’t think maxinbound can be specified, rather it’s implied from maxconnections, maxoutbound, and maxfeeler.Basic math: Maxconnections = maxoutboundfullrelay + maxoutboundblocksonly + maxfeelers + maxinboundWe wanted 21 inbound so 8 + 2 + 1 + 21 = 32 10:38 < raj_149> so that it gives us total 20 peers to be protected, adding the 21st peer will trigger eviction of one? 10:39 < lightlike> raj_149: I think 21 are connected, so adding the 22nd will evict (because 20 are protected, and one is not protected) 10:39 < andrewtoth> it is calculated to give us exactly one more peer than protected, so we can see it get evicted 10:39 < raj_149> lightlike: ah right.. 10:40 < lightlike> gzhao408: right. that's why maxconnections needed to be raised by two when the PR introducing two more outbound connections (blocks-only) was merged 10:41 < lightlike> next q: What are the challenges in testing the eviction logic? Can you think of ways to extend the coverage of the functional test? 10:41 < raj_149> lightlike: its hard to simulate real world networking situations in regtest. 10:43 < michaelfolkson> I still haven't wrapped my head exactly what the test is doing at a high level. Maybe I am just slow :) 10:43 < troygiorshev> in particular, we can't test the netgroup behaviour 10:44 < michaelfolkson> Is it testing a Core node by spinning up a bunch of regtest nodes that connect to that Core node? Or a separate regtest network and testing how that independent network works? 10:44 < andrewtoth> There's no clear interface for the eviction logic, so the test has to build an extensive workaround simulated network 10:44 < raj_149> michaelfolkson: its making some peers satisfy the above criterias so to add them in protected group, then checking eviction is happening only from the non protected group, and protected peers are kept intact as intended. 10:45 < troygiorshev> andrewtoth: for a functional test this is maybe an advantage? 10:45 < jnewbery> michaelfolkson: it's a single node being tested, and a bunch of connections to it from the python test framework 10:45 < andrewtoth> troygiorshev an advantage in what way? 10:45 < michaelfolkson> Cool 10:45 < troygiorshev> michaelfolkson: the former 10:46 < raj_149> quickquestion: whats the diff between p2pdatastore and p2pinterface? 10:47 < amiti> lightlike: did you consider testing the `m_prefer_evict` preferred-for-eviction logic? I haven't looked too closely at feasibility yet 10:47 < lightlike> I originally had another commit with a unit test (testing the sorting in more detail), but that was controversial because in order to make the methods from Boost accessible, quite some code needed to be moved from net.cpp to net.h 10:47 < troygiorshev> andrewtoth: a functional test should try and simulate the real world as closely as possible. forcing us to actually spin up multiple nodes and connect them could help us realize if we've made an incorrect assupmtion somewhere along the line 10:47 < andrewtoth> i see 10:48 < andrewtoth> but even this test is fairly contrived, having only 32 connections. real world nodes will usually use the default 125 10:49 < raj_149> troygiorshev: but wont doing that in regtest will always be insufficient than real world? 10:49 < michaelfolkson> What are you concerned about going from 32 to 125 andrewtoth? DoS? 10:50 < lightlike> amiti: I think this should be possible. One problem is that due to the already mentioned impossibility to mock netgroup, there is some randomness involved (the first step kicks out 4 "random" peers which makes writing the tests harder) 10:50 < sipa> lightlike: with asmap you can mock netgroups 10:50 < andrewtoth> on one hand, it does simulate a lot of different things which would test for incorrect assumptions. on the other, it should be testing exactly the behaviour we want and not more. 10:51 < lightlike> sipa: oh, that is cool, I'll have a look at that! 10:51 < sipa> lightlike: ah, but all connections will still come from localhost, so probably not 10:51 < andrewtoth> michaelfolkson nothing particularly but to simulate real world we should use defaults. Could be some incorrect assumptions about how eviction works that we are not considering with default peers 10:52 < lightlike> last question: What do you think of the algorithm for eviction/protection? Do you have ideas for improvement? 10:52 < troygiorshev> andrewtoth: good point. I think, if you have multiple peers left over after protecting the 20, the logic to choose which one to evict is very simple, so there isn't much benefit to testing that it picks the right one? 10:52 < troygiorshev> now that I type that out I'm not sure that I agree with it ... 10:53 < jnewbery> it'd be great if we could somehow mock remote IP ranges in the test framework. There are quite a few differences between how we treat local peers and remote peers 10:53 < raj_149> jnewbery: mind pointing to few such diffs? 10:55 < MarcoFalke> raj_149: Pretty much anything that deals with addresses (addrman, ...) 10:55 < gzhao408> lightlike I wondered for a while why minping (best ping time ever) is used instead of pingtime (most recent ping time), but for the purposes of protection it seems like mingping would be much harder for an attacker to manipulate and thus...safer? 10:55 < jnewbery> raj_149: I'm not sure if it's that interesting to get into low-level details here. Search for IsLocal() and see where it's used 10:56 < emzy> lightlike: I think for ipv4 you can use as source every host in 127.0.0.0/8. 10:57 < michaelfolkson> Would testing remote peers be in the remit of maintainers/long term contributors with resources set up? Like industrial testing? 10:57 < emzy> Should be all localhost. 10:57 < sipa> gzhao408: ping times vary due to network conditions, node overloading, ...; but an attacker still can't fake minping (if minping is N ms, then you know the node is at most N*150 km away) 10:58 < lightlike> emzy: Probably those would all map to the same netgroup though? 10:59 < emzy> lightlike: no default netgroups is /16 so you could use 127.3.0.1 127.4.0.1 .... 10:59 < amiti> lightlike: hmmm, maybe a test could setup 5 nodes as preferred for eviction, and ensure that one of them is the one evicted? 😂 10:59 < amiti> not great, the netgroup definitely makes it tricky 10:59 < raj_149> sipa: woh, cool formula. 10:59 < MarcoFalke> michaelfolkson: I think having the tests call out to remote peers by default could be problematic, though if it is opt-in and can't be achieved in another way, why not 11:00 < jnewbery> ok, I've got to run to my next call. Thanks for hosting lightlike! 11:00 < jnewbery> Don't forget that tomorrow is the last of our BIP 157 specials, and probably the most interesting from a protocol-design perspective. Notes are here: https://bitcoincore.reviews/19070.html 11:00 < lightlike> ok, thanks all! 11:00 < jnewbery> And next week we'll get into some nice crypto implementation. Fabian will host a meeting on sipa's Python implementation of MuHash. Notes and questions will be up soon. 11:00 < gzhao408> sipa: ah, that makes sense that it can serve as a measurement of physical distance. so this would fall under "hard for attacker to fake" category more than "favorable behavior" category? I was confused because I thought we used it because we cared about how fast our peers were responding 11:00 < nehan> thanks lightlike! 11:00 < raj_149> thanks lightlike for hosting. has been a great one. 11:01 < troygiorshev> thanks lightlike! 11:01 -!- riyasingh [~riyasingh@103.67.17.91] has quit [Remote host closed the connection] 11:01 < gzhao408> thanks lightlike! 11:01 -!- r251d [~r251d@162-196-59-192.lightspeed.irvnca.sbcglobal.net] has quit [Quit: r251d] 11:01 -!- tarboss [~tarboss@p54a037dd.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 11:01 < emzy> tnx everyone! 11:01 < michaelfolkson> Nice hosting lightlike 11:01 < amiti> thanks lightlike! great test addition :) 11:01 * decipher sets up quantum tunneling peer to h4x minping 11:02 < MarcoFalke> jup, thx for hosting lightlike. Good to see more test prs here :) 11:02 < decipher> thanks lightlike 11:02 < sipa> thanks lightlike! 11:04 -!- thomasb06 [~user@natedu100-11.unice.fr] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 11:04 < andrewtoth> thanks lightlike! 11:10 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 11:12 -!- aco [1806aa07@c-24-6-170-7.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 11:27 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 11:27 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 11:27 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 11:32 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 11:37 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 11:37 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 11:37 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 11:40 -!- decipher [~decipher@178.162.222.42.adsl.inet-telecom.org] has left #bitcoin-core-pr-reviews [] 11:42 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 11:43 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 11:43 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 11:43 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 11:47 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 11:48 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 11:48 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 11:48 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 11:53 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 11:58 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 11:58 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 11:58 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 12:03 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 12:04 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 12:04 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 12:04 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 12:08 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 12:09 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 12:09 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 12:09 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 12:13 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 12:17 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 12:17 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 12:17 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 12:22 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 12:27 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 12:27 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 12:27 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 12:32 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 12:35 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 12:35 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 12:35 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 12:39 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 12:40 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 12:40 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 12:40 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 12:45 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 12:50 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 13:14 < jnewbery> log from today's meeting is posted: ttps://bitcoincore.reviews/16756.html#meeting-log 14:00 -!- seven_ [~seven@2a00:ee2:410c:1300:f9c5:ca52:c31b:5e7f] has quit [Read error: Connection reset by peer] 14:01 -!- seven_ [~seven@2a00:ee2:410c:1300:dccd:f4f1:8695:eaae] has joined #bitcoin-core-pr-reviews 14:20 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 256 seconds] 14:32 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Quit: Leaving] 14:53 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 14:53 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 14:58 -!- ecurrencyholder [68ac287f@cpe-104-172-40-127.socal.res.rr.com] has quit [Remote host closed the connection] 15:16 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 15:17 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 15:18 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 15:20 -!- lightlike [~lightlike@p200300c7ef22dd0098f3a6326d8a5c7e.dip0.t-ipconnect.de] has quit [Quit: Leaving] 15:21 -!- MM77788811 is now known as MM777888999 15:22 -!- MM777888999 [~MM7778881@92.38.148.45] has left #bitcoin-core-pr-reviews [] 15:23 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 15:25 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 15:26 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 15:28 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 15:28 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 15:46 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 15:47 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 15:49 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 15:50 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 15:55 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 15:56 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 15:57 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 15:57 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 15:58 < fanquake> michaelfolkson: yea just looking for review 16:00 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:01 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 16:02 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:02 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 16:10 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:11 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 16:12 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:12 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 16:13 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:14 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 16:18 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:18 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 16:19 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:20 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 16:20 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 16:20 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 16:26 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:26 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 16:27 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:28 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 16:29 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:29 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 16:32 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:33 -!- MM77788811 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 16:36 -!- MM77788811 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:36 -!- MM777888999 [~MM7778881@92.38.148.45] has joined #bitcoin-core-pr-reviews 16:37 -!- MM777888999 [~MM7778881@92.38.148.45] has quit [Remote host closed the connection] 16:37 -!- MM77788811 [~MM7778881@209.122.245.10] has joined #bitcoin-core-pr-reviews 16:42 -!- slivera [~slivera@103.231.88.28] has joined #bitcoin-core-pr-reviews 17:01 -!- MM77788811 [~MM7778881@209.122.245.10] has quit [Remote host closed the connection] 17:13 -!- MM77788811 [~MM7778881@209.122.245.10] has joined #bitcoin-core-pr-reviews 17:18 -!- MM77788811 [~MM7778881@209.122.245.10] has quit [Client Quit] 18:01 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 18:01 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 18:06 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 18:44 < instagibbs> oh no wonder I was getting bombarded with notifications on this PR :) 20:07 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 20:08 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 20:21 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 20:45 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 265 seconds] 21:24 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 21:25 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 21:59 -!- MM77788811 [~MM7778881@23.227.134.242] has joined #bitcoin-core-pr-reviews 22:00 -!- MM77788811 [~MM7778881@23.227.134.242] has left #bitcoin-core-pr-reviews [] 22:29 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in] 22:30 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 23:35 -!- seven_ [~seven@2a00:ee2:410c:1300:dccd:f4f1:8695:eaae] has quit [Ping timeout: 260 seconds]