--- Log opened Wed May 17 00:00:04 2023
00:20 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
00:24 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 250 seconds]
00:31 -!- __gotcha [~Thunderbi@94.105.119.42.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
00:49 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
00:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 264 seconds]
01:03 -!- ___nick___ [~quassel@host86-164-104-11.range86-164.btcentralplus.com] has joined #bitcoin-core-pr-reviews
01:21 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
01:26 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 265 seconds]
01:55 -!- b_101 [~robert@185.242.5.35] has quit [Ping timeout: 240 seconds]
01:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
01:57 -!- b_101 [~robert@185.242.5.35] has joined #bitcoin-core-pr-reviews
02:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 265 seconds]
02:02 -!- Cory [~Cory@068-187-125-109.res.spectrum.com] has quit [Ping timeout: 265 seconds]
02:03 -!- Cory [~Cory@068-187-125-109.res.spectrum.com] has joined #bitcoin-core-pr-reviews
02:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
02:33 -!- __gotcha [~Thunderbi@94.105.119.42.dyn.edpnet.net] has quit [Remote host closed the connection]
02:34 -!- __gotcha [~Thunderbi@94.105.119.42.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
02:36 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 248 seconds]
03:05 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
03:09 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 248 seconds]
03:18 -!- codexnakamoto [~codexnaka@dsl-197-245-186-36.voxdsl.co.za] has joined #bitcoin-core-pr-reviews
03:21 < codexnakamoto> heya
03:23 -!- codexnakamoto [~codexnaka@dsl-197-245-186-36.voxdsl.co.za] has quit [Client Quit]
03:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
03:40 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 264 seconds]
03:59 -!- test3 [~test@5.151.70.133] has joined #bitcoin-core-pr-reviews
04:00 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
04:05 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 265 seconds]
04:45 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
04:49 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
04:54 -!- test3 [~test@5.151.70.133] has quit [Quit: Connection closed]
04:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
05:16 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Remote host closed the connection]
05:16 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
05:58 -!- alex-wiederin [~xyz@146.70.179.101] has joined #bitcoin-core-pr-reviews
06:02 -!- alex-wiederin is now known as AlexWiederin
06:19 -!- AlexWiederin [~xyz@146.70.179.101] has quit [Ping timeout: 240 seconds]
07:29 -!- alex-wiederin [~xyz@146.70.179.101] has joined #bitcoin-core-pr-reviews
07:29 -!- alex-wiederin [~xyz@146.70.179.101] has quit [Client Quit]
09:11 -!- alex-wiederin [~xyz@146.70.179.101] has joined #bitcoin-core-pr-reviews
09:23 -!- alex-wiederin [~xyz@146.70.179.101] has quit [Ping timeout: 240 seconds]
09:30 -!- abubakarsadiq [~abubakars@197.210.76.51] has joined #bitcoin-core-pr-reviews
09:39 -!- alex-wiederin [~xyz@146.70.179.101] has joined #bitcoin-core-pr-reviews
09:40 -!- alex-wiederin is now known as alex_wiederin
09:58 -!- sebastianvanstaa [~sebastian@ip-095-223-106-175.um35.pools.vodafone-ip.de] has joined #bitcoin-core-pr-reviews
10:00 < stickies-v> #startmeeting
10:00 < LarryRuane> hi
10:00 < sebastianvanstaa> hi
10:00 < lightlike> hi
10:00 < alex_wiederin> hi
10:00 < pinheadmz> hi B-)
10:00 < abubakarsadiq> hello
10:00 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
10:00 < brunoerg> hi
10:01 < stickies-v> welcome everyone! Today we're looking at #27600, authored by pinheadmz, who I'm delighted is here as well! The notes and questions are available on https://bitcoincore.reviews/27600
10:01 < stickies-v> anyone joining us for the first time today? even if you're just lurking, feel free to say hi!
10:01 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has joined #bitcoin-core-pr-reviews
10:02 < LarryRuane> thanks for hosting again, @stickies-v!
10:02 -!- AbubakarIsmail[m [~abubakars@2001:470:69fc:105::3:5cb4] has joined #bitcoin-core-pr-reviews
10:03 < stickies-v> quietly hoping no one is getting sick of me 🤞 if so, next week we've got abubakarsadiq taking the mic, so hang in there!
10:03 < stickies-v> who got the chance to review the PR or read the notes? (y/n)
10:03 < sebastianvanstaa> y
10:03 < pinheadmz> y
10:03 < alex_wiederin> y
10:03 < lightlike> y
10:03 < abubakarsadiq> y 
10:03 < LarryRuane> y
10:04 < abubakarsadiq> read the notes 
10:04 < stickies-v> ohhhhh, such diligence this week, nice!
10:04 < stickies-v> for those of you who were able to review, would you give it a Concept ACK, Approach ACK, Tested ACK, or NACK? what was your review approach?
10:05 < LarryRuane> "such diligence" -- it helps that this PR isn't super difficult to understand!
10:05 -!- Chan [~Chan@dynamic-077-183-024-228.77.183.pool.telefonica.de] has joined #bitcoin-core-pr-reviews
10:05 < LarryRuane> I built the branch, ran the updated functional test, looked at the individual commits
10:06 < sebastianvanstaa> same here
10:06 < abubakarsadiq> concept Ack, was lost reading linked pr review club session and concept behind the pr. run the test, but did not review the code
10:06 < lightlike> Concept ACK, not completely sure about the approach yet (I just started reviewing 1 hour ago)
10:07 < LarryRuane> I find it easier to look at the diffs from within VScode (i.e. `code` on ubuntu), as opposed to GitHub, because then I can see more context, and search symbols and such
10:07 < alex_wiederin> Concept Ack. Read the code and tried to understand implications for SelectNodeToEvict() and EraseLastKElements()
10:08 < LarryRuane> concept ACK for me as well, but I'm not familiar with peer eviction, so I'd defer to people like @lightlike for this kind of PR
10:08 < stickies-v> LarryRuane: yeah, agreed. Also protects us from github potentially hiding nefarious changes on the webui, when wearing the tinfoil hat
10:08 < LarryRuane> oh that's interesting, hadn't thought of that!
10:09 < stickies-v> Let's start with building some more understanding/context. Why does this PR only apply to inbound peer requests?
10:09 < LarryRuane> (sorry for the sidetrack) one thing I don't like about using vscode is that when looking at a diff, it doesn't allow you to "tag" (jump to the definition of the symbol your cursor is on)
10:10 < LarryRuane> so i have to go to the non-diff file, find the right location, and tag from there... maybe someone has a better idea?
10:10 < sebastianvanstaa> stickies-v for outbound connections, the contacted node decides if it wants the connection?
10:10 < pinheadmz> LarryRuane i use sublime text with a plugin I forked for myself: https://github.com/CJTozer/SublimeDiffView/pull/73
10:10 < brunoerg> Concept ACK
10:10 < stickies-v> LarryRuane: yeah, that is by far my biggest annoyance in reviewing code on vscode. opening the file works, but in multi-commit PRs not ideal, have to actually check out the commit too
10:11 < LarryRuane> stickies-v: I think because it's changing the behavior of accepting an inbound connection, so our outbounds shouldn't be affected
10:11 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Ping timeout: 245 seconds]
10:11 < abubakarsadiq> outbound peers are protected from eviction
10:11 < LarryRuane> pinheadmz: thanks, i'll check that out!
10:12 < stickies-v> sebastianvanstaa: indeed, from the outbound node's perspective, we're the inbound, and we could get evicted
10:12 < lightlike> abubakarsadiq: outobund peers can be evicted too! but there is a completely seperate algorithm for this
10:12 < LarryRuane> abubakarsadiq: I was wondering about that ... there are times where we evict an outbound, aren't there? I'm not sure, but if it's not performing well?
10:12 < sebastianvanstaa> yes, when it behaves badly
10:13 < LarryRuane> lightlike: thanks (you beat me to it)
10:13 < sebastianvanstaa> there is a scoring system for that
10:14 < abubakarsadiq> thanks lightlike, LarryRuane. 
10:14 < LarryRuane> i know that during IBD, if there's a peer who's holding us up (we're like 1000 blocks ahead of that peer), then we can kick it (but I forget the details)
10:14 < lightlike> abubakarsadiq: outbound peers get evicted if the don't keep up with the best chain or we have too many of them, see ConsiderEviction() https://github.com/bitcoin/bitcoin/blob/594f05db19fa2eaf6705f13bb0e147bce6ac21e5/src/net_processing.cpp#LL4955C6-L4955C27
10:14 < stickies-v> outbound peers are irrelevant here because we choose our outbounds, whereas for inbounds we are connected to, so we don't really control who fills up our slots (although we do filter, but it's more of a passive thing). but in some cases (e.g. with whitebind), we want to make sure we keep some space for certain nodes
10:15 < stickies-v> lightlike: there are a lot of ways an outbound can get evicted right? quite a few protocol violations also lead to this, I think?
10:15 < pinheadmz> theres also this idea of "churn" -- like just the idea that we evict any current peer when an inbound request comes in si interesting
10:15 < pinheadmz> it prevents aggresive eclipse attacks
10:16 < abubakarsadiq> thanks lightlike
10:16 < LarryRuane> stickies-v: lightlike: isn't there some kind of "ban" score? so if a peer misbehaves a little bit, we decrement its score (from 100), and only if it reaches zero do we kick it?
10:16 < stickies-v> pinheadmz: oh yeah, great point! we don't blindly always want to evict a peer whenever a new node tries to connect to us, because that would make it easy for an attacker to fill up all our (inbound) slots
10:17 < pinheadmz> as also dont want our slots to be filled up with the same peers forever, so even if we are full we allow some churn
10:17 < pinheadmz> s/as/we
10:17 < lightlike> stickies-v: yes - same for inbound peers. But I think these kind of misbehavior-base disconnections/bans aren't usually called "eviction"
10:17 < sebastianvanstaa> LarryRuane yes, but the banscore increases with time, until threshold reached
10:18 < stickies-v> ohh, I see. eviction more relates to when the peer isn't really misbehaving, but we still want to kick them out anyway?
10:18 < LarryRuane> lightlike: ah interesting, so the term eviction sort of implies well-behaved peers?
10:18 < LarryRuane> sebastianvanstaa: oh I see, thanks, that makes sense
10:18 < lightlike> stickies-v: yes, at least that's how I use these terms usually.
10:19 < sebastianvanstaa> I don't think outbounds get evicted in any case unless misbehaving
10:19 < stickies-v> I'm going to post the next question already, but as always - we're async, so feel free to keep discussing the previous question!
10:19 < sebastianvanstaa> this is also to harden it against eclipse attack
10:19 < stickies-v> What is the impact of the `force` parameter of `SelectNodeToEvict()` on the return value?
10:19 < stickies-v> (link: https://github.com/bitcoin-core-review-club/bitcoin/blob/e71d495ffbda3bc072bbaecd7580809d5087f9e6/src/node/eviction.h#L42)
10:20 < lightlike> sebastianvanstaa: they do if we have too many outbound peers (because we sometimes create extra ones), see EvictExtraOutboundPeers in net_processing
10:20 < sebastianvanstaa> lightlike cool, will check that out
10:21 < alex_wiederin> stickies-v: 'force' ensures that at least one is selected for eviction. Previously it would not pick one if it had already excluded all peers to protect
10:21 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:21 < LarryRuane> stickies-v: if our eviction candidate list is empty (everyone on it has been protected), then we normally return `nullopt`, but if force is set, then we return the least-good protected peer
10:21 < pinheadmz> * which could still be null!
10:22 < pinheadmz> if for example all our inbounds are already whitelisted
10:22 < abubakarsadiq> +1 larryRuane
10:22 < alex_wiederin> pinheadmz: gotcha!
10:22 < LarryRuane> pinheadmz: oh interesting! hadn't noticed that! might be worth adding a comment there
10:22 -!- ___nick___ [~quassel@host86-164-104-11.range86-164.btcentralplus.com] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
10:22 < pinheadmz> eviction.cpp:195
10:22 < pinheadmz>     ProtectNoBanConnections(vEvictionCandidates);
10:22 < alex_wiederin> Yea, I think one of tests covers that case
10:22 < pinheadmz> this line does not return a "last out" for example
10:23 < pinheadmz> alex_wiederin yes the test tries to add additional whitebind inbounds that do NOT get accepted
10:23 -!- test23 [~test@146.70.179.101] has joined #bitcoin-core-pr-reviews
10:24 < LarryRuane> pinheadmz: excellent work on the tests, sometimes good tests are harder to write than the code!
10:24 < pinheadmz> thanks i like writing tests lol and yes it can take all day to figure out how to reproduce a bug, then the fix is simple
10:24 -!- ___nick___ [~quassel@host86-164-104-11.range86-164.btcentralplus.com] has joined #bitcoin-core-pr-reviews
10:25 < lightlike> another way to get into this situation is wehn running with  a much smaller value of -maxconnections than the default (<40 or so?)
10:25 -!- ___nick___ [~quassel@host86-164-104-11.range86-164.btcentralplus.com] has quit [Client Quit]
10:25 < LarryRuane> lightlike: good to know.. just curious, why would someone configure their node to run with a smaller maxconnections?
10:25 < pinheadmz> yeah and if you are expecting a lot of whitebind inbounds, you need to be conscious of that and set it higher
10:25 < stickies-v> pinheadmz: this makes me wonder what happens if we pass a vector containing only whitelisted candidates to `SelectNodeToEvict()`, I think that means we'll be returning a default-initialized `last_out.id`?
10:26 < lightlike> LarryRuane: for example to reduce traffic
10:26 < pinheadmz> LarryRuane just cpu/memory resources
10:26 < pinheadmz> stickies-v i *think* it should return nullopt
10:26 < LarryRuane> lightlike: oh right! like if you're on a limited bandwidth connection, hadn't thought of that, thanks
10:26 < pinheadmz> but i mighrve missed something
10:27 < stickies-v> pinheadmz: sorry, I mean when `force` is also set to `true`
10:27 < LarryRuane> pinheadmz: yes, also like you said, cpu / memory resources
10:27 -!- ___nick___ [~quassel@host86-164-104-11.range86-164.btcentralplus.com] has joined #bitcoin-core-pr-reviews
10:27 < abubakarsadiq> what if you have small maxconnection and still wants the whitelisted inbound to be your peer
10:28 < LarryRuane> abubakarsadiq: i'm guessing that's okay, as long as you have only ONE whitelisted inbound
10:28 < LarryRuane> (or, at least, a smaller number than maxconnections)
10:28 < stickies-v> abubakarsadiq: you just can't have more whitelisted inbound peers than the number specified in your maxconnections
10:29 < stickies-v> increasing maxconnections seems like the straightforward solution
10:29 < LarryRuane> basic question, is maxconnections applicable to inbound only?
10:29 < pinheadmz> its less than that too, as i learned writing this, because inbound slots = maxconnections - 10 outbound - 1 feeler
10:29 < stickies-v> LarryRuane: no, inbound is maxconnections minus outbound and feelers etc
10:29 < pinheadmz> see p2p_eviction.py:49
10:30 < stickies-v> oh beat me to it
10:30 < LarryRuane> stickies-v: pinheadmz: thanks
10:30 < stickies-v> In `SelectNodeToEvict()`, is the order in which we make the various `EraseLastKElements()` calls important? Why (not)?
10:30 < LarryRuane> (and 2 of the 10 are blocks-only, IIRC)
10:30 < lightlike> stickies-v: before or after this PR?
10:30 < LarryRuane> *10 outbound that is
10:31 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
10:31 < alex_wiederin> I believe order does make a difference. Before and after. No?
10:31 < stickies-v> lightlike: both, sorry should have added that to the question
10:32 < stickies-v> alex_wiederin: what is the impact of ordering them differently?
10:33 < alex_wiederin> I believe impact depends on the number of peers that are present
10:34 < stickies-v> I'm not sure I understand what you're saying, do you mean a different number of candidates will get protected?
10:34 < lightlike> seems that after this PR the order is more important because the force-evicted peer would be the one from the last EraseLastKElements call
10:35 < lightlike> before, I guess the order could have some small effects if some peers would be protected through multiple criteria, but I can't really see a systematic bias there.
10:35 < stickies-v> lightlike: that's my understanding as well. On master, I don't think the order has any impact. After this PR, it affects which `std::optional<NodeId>` is returned, where the implicit assumption is that the "least important" protection rule needs to get executed last
10:36 < pinheadmz> i definitely made that assumption!
10:36 < stickies-v> oh
10:37 < alex_wiederin> stickies-v: if say the number of current peers is 4 (which the first EraseCall covers) do the other EraseCalls take effect? Not sure I understand the EraseLast function - new to C++
10:37 < stickies-v> wow, sorry. brain fart. I was only considering the edge case where all candidates get evicted, in which case the order does not matter on `master` (but it still does on this PR)
10:39 < stickies-v> How is the function signature of `EraseLastKElements` changed in this PR? Why is this necessary? Do you see an alternative approach?
10:39 < stickies-v> (link: https://github.com/bitcoin-core-review-club/bitcoin/blob/e71d495ffbda3bc072bbaecd7580809d5087f9e6/src/node/eviction.cpp#L78-L80)
10:40 -!- test23 [~test@146.70.179.101] has quit [Quit: Connection closed]
10:40 < yashraj> still confused about the answer to the previous one...
10:40 < lightlike> I'm not sure that all the EraseLastKElements calls are ordered by importance. e.g. the "recently sent us novel blocks" seems more important/harder to game to me than having low minimum ping times.
10:41 < pinheadmz> i guess it might make sense to specifically pick one quality (instaed of all) and for exmple "force' will just evict the worst ping time peer 
10:42 < LarryRuane> the signature changed because of the need to return the best protected peer, which we figure out as a side-effect of erasing elements
10:44 < stickies-v> yashraj: with this PR, the order in which we execute the `EraseLastKElements` calls is important we keep overwriting `last_out` with the most recently erased candidate. does that make sense?
10:44 < LarryRuane> stickies-v: "Do you see an alternative approach?" yes, `last` could be passed to `EraseLastKElements()` as an in-out argument (and make that function return void again),
10:44 < lightlike> a very simple alternative approach would be to just pick a random peer before the first EraseLastKElements, and evict that one if at the end of the function there is no better peer left because every peer is protected.
10:44 < pinheadmz> lightlike wow a random peer? i thought our eviction choise was super-sensitive
10:44 < LarryRuane> and then the multiple instances of `if (last.has_value()) last_out = last.value();` would be eliminated
10:45 < pinheadmz> LarryRuane that is a good option, thanks. yeah i think i do not need to modify that function as much as i did
10:45 < pinheadmz> i actually did not know if I could "template" a return value and thats why I changed it so much
10:45 < stickies-v> pinheadmz: but this only applies in case of `force==true`, i.e. we trust the inbound peer, so I think we can be less careful about eviction here?
10:46 < yashraj> yes, thanks stickies-v:
10:46 < pinheadmz> bc i also saw the function was not used in any other context
10:46 < lightlike> pinheadmz: this would only apply when you have a whitelisted incoming peer connecting to you and all peers are protected. seems a like a very special-case scenario to me.
10:46 < pinheadmz> stickies-v thats a good point but id still have to defer to lightlike and the p2p gurus
10:47 < pinheadmz> right but even in that scenario random choice doesnt seem very bitcoin-core-y
10:47 < LarryRuane> i actually like that change to eliminate the templating... I think it's confusing when code is over-generalized... if it's only instantiated one way, then why not "hard code" that way?
10:47 < pinheadmz> oh ok
10:47 < stickies-v> LarryRuane: that's a good alternative! generally i'm not a huge fan of out-parameters but in this case it would quite significantly clean up the code
10:48 < pinheadmz> im sure the original author of "remove elements" designed the function to just remove elements in a generic way
10:48 < LarryRuane> but on the other hand (arguing against myself), those `if` statements make it very clear to the reader what's going on, without having to dig into the function being called
10:48 < stickies-v> I agree with LarryRuane about templating. Much easier to reason about what a function is doing when it's not templated, so I like to avoid it when possible
10:49 < pinheadmz> ah but is it an unecessary code change for this PR
10:49 < LarryRuane> pinheadmz: that's a good question, reviewers may say so ... it might help to make that change in a separate commit?
10:50 < stickies-v> I think another approach would be to have `EraseLastKElements` return all (instead of just the last) removed elements, which imo is a bit more intuitive/general, but perhaps not worth it. And this can also be coupled with LarryRuane's idea of using an out-parameter to simplify the current code
10:51 < stickies-v> we're nearing the end, so time for the last question for today
10:51 < lightlike> pinheadmz: why does ProtectEvictionCandidatesByRatio need to be changed? It protects only 50% at best as far as I understand, so it should leave an unprotected peer usually so last wouldn't be needed if we get that far? Or is this just for the edge case of having 1 peer left?
10:51 < stickies-v> Suppose we pass a vector of 40 eviction candidates to `SelectNodeToEvict()`. Before and after this PR, what's the theoretical maximum of Tor nodes that can be protected from eviction?
10:52 < pinheadmz> lightlike yeah really wanted to make sure i caught the absolute last protected peer after we seal off the outbound an no-ban peers
10:52 < pinheadmz> but mightve been overkill
10:53 < LarryRuane> stickies-v: does it change from 10 to 9?
10:54 < stickies-v> lightlike: I really like your suggestion to just select a random (non-whitelisted, inbound) peer, it seems sensible at first sight and would simplify this PR so much
10:55 < stickies-v> LarryRuane: I've found different numbers but I want to give a bit more time for people to share their numbers (if any)
10:55 < lightlike> stickies-v: I'll suggest it in the PR, would be good to have some input from other p2p contributors on that.
10:55 < pinheadmz> yeah and actually we can just select a random peer from whatevers left at any point in SelectNodeToEvict()
10:56 < pinheadmz> so like, protect outbound, noBan AND peers that sent us blocks, and then choose random
10:57 < pinheadmz> whitebind is also not entirely attack-proof for example i have a ful node with whitebind on a non-standard port that i use for my SPV wallet... but anyone could discover that port by sweeping
10:58 < pinheadmz> i dont know if we deal with that in any other way, i suppose bip324 maybe we can actually authenticate inboudns?
10:58 < stickies-v> pinheadmz: that almost sounds like an invite
10:58 < pinheadmz> go for it boss
10:59 < pinheadmz> but yeah with that in mind (that a whitebind inbound could still be an attacker) i wonder if random choice is still safe
11:00 -!- Chan [~Chan@dynamic-077-183-024-228.77.183.pool.telefonica.de] has quit [Quit: Connection closed]
11:00 < stickies-v> LarryRuane: I think both with and without this PR 34/40 Tor nodes would be the maximum number (assuming they're not NoBan and inbound, I underspecified the question a bit) of nodes that can be protected by `SelectNodeToEvict`
11:01 < LarryRuane> stickies-v: thanks, i'll have to study that more!
11:01 < stickies-v> feel free to ping me here later on if you disagree on the numbers, but since we're at time I'll be closing off the meeting now
11:01 < stickies-v> thanks everyone for participating, and pinheadmz for authoring the PR and joining us today!
11:02 < pinheadmz> thanks stickies-v !! and everyone for reviewing and thikning about this issue
11:02 < stickies-v> #endmeeting
11:02 < LarryRuane> stickies-v: thanks for hosting! This was very informative! Thanks to @pinheadmz for the PR and @lightlike for your expertise!
11:02 < lightlike> pinheadmz: when you have -noban permission on that address, anyone repeatedly connecting to it can exhaust all of your inbound slots and evict anybode else anyway, right? no matter if random or non-random
11:02 < alex_wiederin> thanks!
11:02 < pinheadmz> 🕺🕺🕺
11:02 < abubakarsadiq> thanks everyone, thanks stickies-v for hosting
11:02 < pinheadmz> lightlike good point
11:02 < lightlike> thanks stickies-v!
11:03 < yashraj> this seemed like a fantastic discussion (even though I did not understand much of it), thanks all
11:06 -!- alex_wiederin [~xyz@146.70.179.101] has quit [Quit: WeeChat 3.8]
11:07 < pinheadmz> yashraj anything you want to ask?
11:10 -!- alex-wiederin [~xyz@146.70.179.101] has joined #bitcoin-core-pr-reviews
11:10 < yashraj> thanks for offering pinheadmz:, I should do a proper go-over before I ask anything. Really appreciated how open-minded and candid you were throughout the convo!
11:10 < pinheadmz> this is the best channel on IRC ;-)
11:11 < stickies-v> now that's a tagline
11:11 < yashraj> add it
11:11 -!- alex-wiederin [~xyz@146.70.179.101] has quit [Client Quit]
11:12 -!- Amirreza [~Amirreza7@2.177.11.97] has joined #bitcoin-core-pr-reviews
11:20 -!- Guest15 [~Guest15@104.168.64.220] has joined #bitcoin-core-pr-reviews
11:25 -!- Guest15 [~Guest15@104.168.64.220] has quit [Quit: Client closed]
11:27 -!- abubakarsadiq [~abubakars@197.210.76.51] has quit [Ping timeout: 240 seconds]
11:29 -!- abubakarsadiq [~abubakars@105.112.125.243] has joined #bitcoin-core-pr-reviews
11:37 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has joined #bitcoin-core-pr-reviews
11:45 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has quit []
11:48 -!- b_101 [~robert@185.242.5.35] has quit [Ping timeout: 240 seconds]
11:49 -!- abubakarsadiq [~abubakars@105.112.125.243] has quit [Quit: Lost terminal]
11:53 -!- ___nick___ [~quassel@host86-164-104-11.range86-164.btcentralplus.com] has quit [Ping timeout: 240 seconds]
11:57 -!- sebastianvanstaa [~sebastian@ip-095-223-106-175.um35.pools.vodafone-ip.de] has quit [Quit: Connection closed]
11:59 -!- puchka [~puchka@185.203.122.230] has joined #bitcoin-core-pr-reviews
12:07 -!- pinheadmz[m] [~pinheadmz@2001:470:69fc:105::fe40] has joined #bitcoin-core-pr-reviews
12:08 < pinheadmz[m]> Ignore me just trying element / matrix
12:08 < pinheadmz> sweet
12:20 -!- alex-wiederin [~alex@146.70.179.101] has joined #bitcoin-core-pr-reviews
12:21 -!- alex-wiederin [~alex@146.70.179.101] has quit [Client Quit]
12:40 -!- Amirreza [~Amirreza7@2.177.11.97] has quit [Quit: Leaving]
12:47 -!- puchka [~puchka@185.203.122.230] has quit [Ping timeout: 240 seconds]
13:04 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
14:10 -!- __gotcha1 [~Thunderbi@94.105.119.42.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
14:10 -!- __gotcha [~Thunderbi@94.105.119.42.dyn.edpnet.net] has quit [Read error: Connection reset by peer]
14:10 -!- __gotcha1 is now known as __gotcha
14:30 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
14:32 -!- b_101 [~robert@185.242.5.35] has joined #bitcoin-core-pr-reviews
14:52 -!- b_101 [~robert@185.242.5.35] has quit [Ping timeout: 240 seconds]
17:10 -!- b_101 [~robert@189.236.24.221] has joined #bitcoin-core-pr-reviews
17:52 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
17:57 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
18:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 264 seconds]
18:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
18:42 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 264 seconds]
19:10 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has quit [Quit: grettke]
19:11 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
19:16 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
19:31 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has joined #bitcoin-core-pr-reviews
19:36 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has quit [Quit: grettke]
19:39 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
19:44 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 265 seconds]
19:50 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
19:55 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 264 seconds]
20:25 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
20:29 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 240 seconds]
20:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
20:34 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has joined #bitcoin-core-pr-reviews
20:35 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 240 seconds]
20:38 -!- grettke [~grettke@065-026-198-174.biz.spectrum.com] has quit [Ping timeout: 240 seconds]
20:52 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
20:57 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 240 seconds]
21:14 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
21:19 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 256 seconds]
21:37 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
21:42 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 264 seconds]
21:43 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
21:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 265 seconds]
21:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
21:53 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 264 seconds]
21:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
21:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 265 seconds]
22:11 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
22:15 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 246 seconds]
22:22 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
22:27 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 264 seconds]
22:38 -!- puchka [~puchka@185.203.122.231] has joined #bitcoin-core-pr-reviews
22:49 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has joined #bitcoin-core-pr-reviews
22:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:189e:23c6:5ab3:887] has quit [Ping timeout: 240 seconds]
23:06 -!- __gotcha [~Thunderbi@94.105.119.42.dyn.edpnet.net] has quit [Ping timeout: 256 seconds]
23:26 -!- __gotcha [~Thunderbi@94.105.119.42.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
23:26 -!- Guest41 [~Guest41@138.199.6.226] has joined #bitcoin-core-pr-reviews
23:27 -!- Guest41 [~Guest41@138.199.6.226] has quit [Client Quit]
23:30 -!- __gotcha [~Thunderbi@94.105.119.42.dyn.edpnet.net] has quit [Ping timeout: 256 seconds]
23:32 -!- elichai2 [sid212594@id-212594.hampstead.irccloud.com] has quit [Ping timeout: 250 seconds]
23:35 -!- elichai2 [sid212594@id-212594.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
23:39 -!- robot-dreams [sid463268@id-463268.uxbridge.irccloud.com] has quit [Ping timeout: 250 seconds]
23:40 -!- robot-dreams [sid463268@id-463268.uxbridge.irccloud.com] has joined #bitcoin-core-pr-reviews
23:41 -!- elichai2 [sid212594@id-212594.hampstead.irccloud.com] has quit [Ping timeout: 250 seconds]
23:42 -!- elichai2 [sid212594@id-212594.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
--- Log closed Thu May 18 00:00:05 2023