--- Log opened Wed Nov 02 00:00:06 2022
00:31 -!- Talkless [~Talkless@m83-181-72-210.cust.tele2.lt] has joined #bitcoin-core-pr-reviews
00:36 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
00:39 -!- jonatack3 [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
00:48 -!- gleb0712 [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews
00:53 -!- calvinalvin [~kcalvinal@ec2-3-38-183-204.ap-northeast-2.compute.amazonaws.com] has joined #bitcoin-core-pr-reviews
00:54 -!- kcalvinalvin [~kcalvinal@ec2-3-38-183-204.ap-northeast-2.compute.amazonaws.com] has quit [Read error: Connection reset by peer]
01:09 -!- Talkless [~Talkless@m83-181-72-210.cust.tele2.lt] has quit [Quit: Konversation terminated!]
01:19 -!- noxim [~AdminUser@user/noxim] has quit [Ping timeout: 252 seconds]
01:19 -!- noxim [~AdminUser@43.224.169.86] has joined #bitcoin-core-pr-reviews
01:19 -!- noxim [~AdminUser@43.224.169.86] has quit [Changing host]
01:19 -!- noxim [~AdminUser@user/noxim] has joined #bitcoin-core-pr-reviews
01:37 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
02:31 -!- livestradamus [~quassel@user/livestradamus] has quit [Read error: Software caused connection abort]
02:35 -!- mimmy [~mimmy@2604:a880:cad:d0::3e:1001] has quit [Read error: Software caused connection abort]
02:36 -!- livestradamus [~quassel@user/livestradamus] has joined #bitcoin-core-pr-reviews
02:38 -!- mimmy [~mimmy@159.203.19.37] has joined #bitcoin-core-pr-reviews
02:57 -!- kcalvinalvin [~kcalvinal@ec2-3-38-183-204.ap-northeast-2.compute.amazonaws.com] has joined #bitcoin-core-pr-reviews
02:57 -!- calvinalvin [~kcalvinal@ec2-3-38-183-204.ap-northeast-2.compute.amazonaws.com] has quit [Ping timeout: 252 seconds]
03:05 -!- Netsplit *.net <-> *.split quits: kevkevin
03:07 -!- Netsplit *.net <-> *.split quits: andrewtoth, ghost43
04:08 -!- noxim [~AdminUser@user/noxim] has quit [Ping timeout: 255 seconds]
04:10 -!- shiza [~admin@ec2-52-208-131-13.eu-west-1.compute.amazonaws.com] has quit [Ping timeout: 246 seconds]
04:12 -!- shiza [~admin@ec2-52-208-131-13.eu-west-1.compute.amazonaws.com] has joined #bitcoin-core-pr-reviews
04:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:f813:db88:1420:c742] has joined #bitcoin-core-pr-reviews
04:17 -!- noxim [~AdminUser@43.224.169.86] has joined #bitcoin-core-pr-reviews
04:17 -!- noxim [~AdminUser@43.224.169.86] has quit [Changing host]
04:17 -!- noxim [~AdminUser@user/noxim] has joined #bitcoin-core-pr-reviews
04:38 -!- noxim [~AdminUser@user/noxim] has quit [Ping timeout: 248 seconds]
04:44 -!- noxim [~AdminUser@43.224.169.86] has joined #bitcoin-core-pr-reviews
04:44 -!- noxim [~AdminUser@43.224.169.86] has quit [Changing host]
04:44 -!- noxim [~AdminUser@user/noxim] has joined #bitcoin-core-pr-reviews
06:14 -!- dergoegge [sid453889@lymington.irccloud.com] has quit [Read error: Software caused connection abort]
06:15 -!- shiza [~admin@ec2-52-208-131-13.eu-west-1.compute.amazonaws.com] has quit [Ping timeout: 252 seconds]
06:16 -!- dergoegge [sid453889@id-453889.lymington.irccloud.com] has joined #bitcoin-core-pr-reviews
06:17 -!- shiza [~admin@ec2-52-208-131-13.eu-west-1.compute.amazonaws.com] has joined #bitcoin-core-pr-reviews
06:32 -!- ariard [~ariard@167.99.46.220] has quit [Read error: Software caused connection abort]
06:38 -!- ariard [~ariard@167.99.46.220] has joined #bitcoin-core-pr-reviews
06:45 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
06:46 -!- lowhope [~lowhope@2602:fffa:fff:108a:0:16:3e86:c70e] has joined #bitcoin-core-pr-reviews
06:53 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
07:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:f813:db88:1420:c742] has quit []
07:57 -!- amovfx [~amovfx@d75-156-179-9.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
08:03 -!- lightlike [sid521075@user/lightlike] has quit [Read error: Software caused connection abort]
08:03 -!- lightlike [sid521075@user/lightlike] has joined #bitcoin-core-pr-reviews
08:04 -!- amovfx [~amovfx@d75-156-179-9.abhsia.telus.net] has quit [Ping timeout: 255 seconds]
08:08 -!- noxim [~AdminUser@user/noxim] has quit [Ping timeout: 255 seconds]
08:26 -!- noxim [~AdminUser@43.224.169.86] has joined #bitcoin-core-pr-reviews
08:26 -!- noxim [~AdminUser@43.224.169.86] has quit [Changing host]
08:26 -!- noxim [~AdminUser@user/noxim] has joined #bitcoin-core-pr-reviews
08:56 -!- sprainhill [~sprainhil@071-088-045-129.res.spectrum.com] has joined #bitcoin-core-pr-reviews
08:58 -!- ariard [~ariard@167.99.46.220] has quit [Ping timeout: 252 seconds]
08:58 -!- ariard [~ariard@167.99.46.220] has joined #bitcoin-core-pr-reviews
09:11 -!- qubenix_ [~qubenix@66.172.11.228] has quit [Quit: quit]
09:12 -!- qubenix [~qubenix@user/qubenix] has joined #bitcoin-core-pr-reviews
09:13 -!- qubenix [~qubenix@user/qubenix] has quit [Client Quit]
09:13 -!- qubenix [~qubenix@user/qubenix] has joined #bitcoin-core-pr-reviews
09:17 -!- sprainhill [~sprainhil@071-088-045-129.res.spectrum.com] has quit [Ping timeout: 252 seconds]
09:25 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
09:34 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 272 seconds]
09:34 -!- sprainhill [~sprainhil@071-088-045-129.res.spectrum.com] has joined #bitcoin-core-pr-reviews
09:37 -!- koolazer [~koo@user/koolazer] has quit [Read error: Software caused connection abort]
09:42 -!- sprainhill [~sprainhil@071-088-045-129.res.spectrum.com] has quit [Ping timeout: 252 seconds]
09:43 -!- koolazer [~koo@user/koolazer] has joined #bitcoin-core-pr-reviews
09:45 -!- amovfx [~amovfx@node-1w7jr9yi65te5njjlzr3t5lya.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
09:47 -!- sprainhill [~sprainhil@071-088-045-129.res.spectrum.com] has joined #bitcoin-core-pr-reviews
09:49 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
09:50 -!- amovfx [~amovfx@node-1w7jr9yi65te5njjlzr3t5lya.ipv6.telus.net] has quit [Remote host closed the connection]
09:51 -!- amovfx [~amovfx@node-1w7jr9yi65te5njjlzr3t5lya.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
09:55 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:59 < amovfx> It's learning time!
09:59 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
10:00 -!- inauman [~inauman@ip70-176-106-211.ph.ph.cox.net] has joined #bitcoin-core-pr-reviews
10:00 -!- hernanmarino [~hernanmar@186.152.233.128] has joined #bitcoin-core-pr-reviews
10:00 < dergoegge> #startmeeting
10:00 -!- pablomartin [~pablomart@37.120.199.204] has joined #bitcoin-core-pr-reviews
10:00 < pablomartin> hello!
10:00 < hernanmarino> Hello 
10:00 < dergoegge> Hi everyone! Welcome to this week's PR review club!
10:00 < andrewtoth> hi
10:00 < stickies-v> Hi!
10:00 < dergoegge> Feel free to say hi to let people know you are here
10:01 < amovfx> hu
10:01 < amovfx> hi
10:01 < svav> Hi All
10:01 < dergoegge> This week we are looking at #26140 "Move CNodeState members guarded by g_msgproc_mutex to Peer", notes are in the usual place: https://bitcoincore.reviews/26140
10:01 < effexzi> Hi every1
10:01 < dergoegge> Anyone here for the first time? :)
10:01 -!- Lov3r_Of_Bitcoin [~Lov3r_Of_@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
10:02 < Lov3r_Of_Bitcoin> Hello
10:02 < sprainhill> dergoegge: I am!
10:02 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has joined #bitcoin-core-pr-reviews
10:02 < amovfx> welcome sprain
10:02 < dergoegge> sprainhill: Welcome!
10:02 < sprainhill> ty!
10:02 < svav> sprainhill where did you hear of the meeting please, and Hi!
10:03 < LarryRuane> hi
10:03 < sprainhill> Svav: I think Twitter originally
10:03 < schmidty_> hi
10:04 < dergoegge> Lets get started! Who had a chance to look at the notes for this week? (y/n)
10:04 < amovfx> y
10:04 < hernanmarino> y
10:04 < stickies-v> y, mostly code review though!
10:04 < pablomartin> y
10:04 < svav> y
10:04 < sprainhill> n
10:04 < LarryRuane> y (but wasn't able to figure out all the answers to the questions)
10:05 < Lov3r_Of_Bitcoin> y
10:05 < dergoegge> Lots of ys, cool! Have you also reviewed the PR? Concept ACK, approach ACK, tested ACK, or NACK?
10:06 < pablomartin> approach CK
10:06 < stickies-v> Approach ACK
10:06 < hernanmarino> approach ACK, I will test it after this meeting
10:07 < Lov3r_Of_Bitcoin> approach ACK
10:08 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
10:08 < dergoegge> Great! The first question is a bit of a background question: What is `cs_main` and what is it used for?
10:08 < pablomartin> cs_main syncs access (recursive mutex) to the chain state in an atomic way
10:08 < hernanmarino> "critical section" mutex  from the old main function  
10:09 < svav> cs_main is a recursive mutex which is used to ensure that validation is carried out in an atomic way. It guards access to validation specific variables (such as CChainState and CNode) or mempool variables (in net_processing). The lock of cs_main is in validation.cpp.
10:10 < glozow> hi
10:10 < svav> https://bitcoin.stackexchange.com/questions/106314/what-is-cs-main-why-is-it-called-cs-main
10:11 < dergoegge> pablomartin: yes but is the chainstate all that it guards?
10:11 < dergoegge> And can someone explain what the difference between a mutex and a recursive mutex is?
10:12 < pablomartin> nop, also de ones svav mentioned and on this pr
10:13 < LarryRuane> For any of you history fans ... I was thinking `cs_main` was the only mutex in the original code, but that's not true, there were several (but not many): https://github.com/JeremyRubin/satoshis-version/search?q=CCriticalSection
10:13 < amovfx> A recursive mutex can be locked many times
10:13 < stickies-v> A recursive mutex doesn't lock when locked multiple times in the same stack, I think?
10:13 < amovfx> and needs to be unlocked that many times
10:13 < dergoegge> svav: I don't think that CNode is guarded by cs_main (and it totally shouldn't be). That SO answer is over a year old, so it might be out of date. Although i also can't remember CNode being guarded by cs_main.
10:14 < amovfx> oh shit, maybe I got it backwards
10:14 < pablomartin> recursive mutex: could be locked multiple times by the same process/thread, without causing a deadlock.
10:14 < LarryRuane> if a thread acquires (locks) a mutex and then that same thread tries to lock it again, it will block... with a recursive mutex, the same thread can lock the mutex multiple times (simultaneously), and it's only unlocked on the last unlock 
10:15 < svav> dergoegge ok I just Googled it
10:15 < dergoegge> stickies-v, amovfx: yes a recursive mutex can be locked multiple times but only by the same thread. A regular mutex will create a deadlock when locked twice from the same thread.
10:15 < amovfx> imo, Larry +1, he said what I was trying to say
10:15 < andrewtoth> pablomartin: I think that's true for thread, but a process can have multiple threads
10:15 < LarryRuane> the recursive mutex has a lock "counter" ... only if it's zero, is the lock unlocked
10:15 < dergoegge> pablomartin, LarryRuane: exactly +1
10:16 < pablomartin> andrewtoth: I agree
10:16 < amovfx> ah I missed the detail of the same thread has to lock multiple times, I thought it can be locked multiple times from wherever, good to know
10:16 < LarryRuane> but I'm pretty sure that we're trying to eliminate recursive mutexes, but it is a slow process
10:16 < dergoegge> andrewtoth: yes that is right, only relevant for threads
10:16 < LarryRuane> amovfx: well, if it could be locked multiple times from wherever, then it wouldn't have any effect!
10:17 < andrewtoth> a shared mutex can be locked multiple times from wherever, and only locked exclusively by a unique lock taken on it
10:17 < yashraj> just found out what a mutex is, with a fun, relevant analogy too! https://stackoverflow.com/questions/34524/what-is-a-mutex
10:17 < dergoegge> LarryRuane: yea recursive mutexes generally lead to worse code, i think we have a couple of open PRs that try to remove some of them.
10:17 < amovfx> Larry: good point, ty
10:18 < amovfx> imo, I don't like them at all
10:18 < andrewtoth> there is an open issue tracking removal of recursive mutexes https://github.com/bitcoin/bitcoin/issues/19303
10:18 < stickies-v> dergoegge: the docs state that CNodeState's members are protected by cs_main, but I can't see that enforced in code anywhere. Do the docs mean that they _should_ only be accessed with a lock on cs_main?
10:18 < dergoegge> My prepared answer for this question: cs_main is our main validation mutex lock, used to guard any validation state from parallel access by different threads. It is also used to guard non-validation state which we should change (like this week's PR does)
10:19 < LarryRuane> my impression is that recursive mutexes, even though they seem useful. lead to lazy coding, and increase the possibility of synchronization bugs
10:19 < LarryRuane> dergoegge: very helpful, can you say a little on what validatation state means? what's an example of such state, and example of NOT such state?
10:19 < pablomartin> dergoegge: I agree, it's the main mutex lock
10:20 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:20 < dergoegge> stickies-v: yes thats what the docs mean, we could add annotations (i.e. GUARDED_BY(cs_main)) to get the compiler to check (i think i did that at some point privately just to check that cs_main is always held when they're accessed) 
10:20 < amovfx> is validation state, things like chaintip, mempool?
10:21 < LarryRuane> maybe i can answer partially myself... our list of peers is part of our current state, but it's not *validation* state ... so changing that list should probably not require `cs_main`
10:22 < dergoegge> LarryRuane: validation state as in chainstate manager, chainstate but also non-validation state like CNodeState::nUnconnectingHeaders (which is strictly per peer p2p state)
10:23 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
10:23 < LarryRuane> dergoegge: +1 thanks
10:23 < stickies-v> dergoegge: okay cool thanks, that's what I thought. The docs just make it sound like the locking is already taken care of, instead of highlighting that it absolutely needs to be done - which I think is a bit confusing 
10:23 < amovfx> ah, validation data can come in through peers, so we lock any state that is associated with those?
10:24 < dergoegge> amovfx: we use cs_main to keep the mempool in sync with the current chainstate iirc (e.g. utxo set) (eventually we could have an async mempool but thats a story for another time)
10:24 < amovfx> chainstate ==utxo state
10:24 < amovfx> ?
10:24 < dergoegge> OK we should move on: Which threads access state relevant for message processing (PeerManagerImpl, Peer, etc.)? (Hint: have a look at the developer notes for a list of all threads)
10:25 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
10:25 < amovfx> https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#threads
10:25 < LarryRuane> amovfx: yes, I thought that naming is confusing, but yet, my impression is that chainstate is another term for UTXO state (utxo set)
10:25 < andrewtoth> amovfx: blocks added and indexed as well
10:25 < amovfx> ty
10:25 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Client Quit]
10:25 < LarryRuane> dergoegge: These "net threads" https://github.com/bitcoin/bitcoin/blob/master/src/net.h#L1105
10:26 < pablomartin> all net threads?
10:26 < dergoegge> amovfx: the naming can be confusing, you can have a look at our "Chainstate" to see what that includes (which is what i meant)
10:26 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has quit []
10:26 < amovfx> ty
10:27 < amovfx> dergoegge: ThreadMessageHandler?
10:27 < LarryRuane> (those threads are owned by `CConnman` of which there is one instance)
10:27 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
10:28 < dergoegge> Ideally the answer includes a list of thread names and an explanation on how they access the net processing (message processing) state
10:28 < pablomartin> LarryRuane: I see
10:29 < dergoegge> amovfx: yes the msghand thread is one of them, how does it access net processing state? (what PeerManager functions does it call?)
10:30 < amovfx> .m_recently_announced_invs?
10:30 < LarryRuane> amovfx: I think what i said is inaccurate, read this comment above the `Chainstate` class definition https://github.com/bitcoin/bitcoin/blob/master/src/validation.h#L404
10:31 < amovfx> ty
10:31 < LarryRuane> one of the members of that class is `m_coins_views` which is the UTXO set, but it's only one part of that class
10:31 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
10:32 < dergoegge> amovfx: ThreadMessageHandler directly calls methods on the PeerManager (i.e. ProcessMessages, SendMessages) which do all the message handling
10:32 < amovfx> ty
10:32 < dergoegge> How about the scheduler thread, does that call into net processing?
10:34 < andrewtoth> does it for scheduling feeler connections?
10:35 < pablomartin> dergoegge: but it does asynchronous calls, no? not sure if it ended up callin the net processing...
10:35 < pablomartin> *calling
10:35 < dergoegge> andrewtoth: feeler connections are opened by the openconn thread (see ThreadOpenConnections in net.cpp)
10:35 < amovfx> I would be shocked if the scheduler thread makes calls into netprocessing
10:37 < dergoegge> PeerManager is registered as a CValidationInterface so it receives validation callbacks which are scheduled on the scheduler thread (e.g. BlockConnected, BlockDisconnected, NewPowValidBlock)
10:37 < amovfx> Looks like there CConnman calls the scheduler
10:38 < stickies-v> a bit to my surprise, the scheduler does not start new threads for the tasks it starts (https://github.com/bitcoin/bitcoin/blob/5274f324375fd31cf8507531fbc612765d03092f/src/scheduler.cpp#L62), but rather they are indeed executed from the scheduler thread
10:38 < LarryRuane> scheduler calls `CheckForStaleTipAndEvictPeers` and `ReattemptInitialBroadcast`
10:38 < LarryRuane> (which are part of PeerManager)
10:39 < dergoegge> LarryRuane: also correct!
10:42 < dergoegge> Oh i think my last message didn't make it through...
10:42 < dergoegge> Ok so we covered the msghand and scheduler threads. How about the openconn thread?
10:42 -!- amovfx [~amovfx@node-1w7jr9yi65te5njjlzr3t5lya.ipv6.telus.net] has quit [Remote host closed the connection]
10:42 -!- amovfx [~amovfx@node-1w7jr9yi65te5njjlzr3t5lya.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
10:44 < stickies-v> (note: the thread is called "opencon", if you're grepping)
10:47 < stickies-v> dergoegge: I can't see any instances where `CConnman::ThreadOpenConnections` calls into net_processing, so... I think the answer is no?
10:49 < dergoegge> ThreadOpenConnections calls OpenNetworkConnection which calls... IntializeNode on PeerManager!
10:49 < dergoegge> I added this question to make it obvious that some functions on PeerManager are called by multiple threads and any state accessed/mutated in them needs protection against parallel access. 
10:49 < dergoegge> Some state in net processing however is only ever accessed by the msghand thread and therefore doesn't need a mutex.
10:50 < LarryRuane> in case this is helpful, link to ThreadOpenConnections: https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1577
10:50 < dergoegge> Next question: What is the difference between CNodeState and Peer? How would you decide where to store new per-peer state? (Bonus points if you also mention CNode in your answer)
10:50 < stickies-v> oh. good point, I only checked the direct calls, not the entire stacks. that seems like a very difficult thing to verify if you're not reasonably familiar with all the functions called, or is there a trick?
10:51 < stickies-v> (difficult as in very time consuming to do it manually)
10:52 < LarryRuane> dergoegge: I think currently, some of CNodeState is not relevant to validation, and so better belongs in Peer.. Peer has non-validation stuff, CNodeState should have validation stuff -- did I get that right? :)
10:54 < LarryRuane> stickies-v: +1 .. I sometimes find it helpful to run the node in the debugger to see those kind of dynamics
10:54 < pablomartin> stickies-v: should be a map/ graph somewhere... not sure if I ever saw it... or dreamt it 
10:54 < dergoegge> stickies-v: yea you need to do some digging, i don't have a special trick for this (i think the call graphs in the doxygen docs are sometimes helpful: https://doxygen.bitcoincore.org/class_c_connman.html#a0b787caf95e52a346a2b31a580d60a62)
10:54 < pablomartin> dergoegge: yeah there
10:55 < LarryRuane> dergoegge: that's cool, I wonder how good the call graphing is when using interface classes, that would make it tricky
10:55 < dergoegge> LarryRuane: yes CNodeState is meant for validation specific per-peer state guarded by cs_main and Peer is meant for all other per-peer state (that is not guarded by cs_main)
10:55 < stickies-v> intuitively, I'd say CNode mostly deals with communication between nodes, CNodeState with validating what we get from a node, and Peer to deal with policy and checking if peers are behaving correctly. Is that a fair approximation?
10:56 < stickies-v> pablomartin dergoegge yeah but call graphs are function/class based, so you'd have to look at a lot of charts to figure out what calls into net_processing?
10:56 < dergoegge> stickies-v: yea that sounds about right. Do you mean mempool policy?
10:57 < stickies-v> cool. No I mean p2p policy, e.g. not exceeding the number of unconnected headers etc. I don't think this touches mempool policy at all, right?
10:57 < dergoegge> stickies-v: yea the doxygen graphs are not perfect but in case of the addcon thread it would help
10:58 < dergoegge> stickies-v: OK good! It has no mempool policy state (i hope)
10:58 < amovfx> Is node state only for the operators node?
10:58 < dergoegge> Lets skip Q. 5: Why does the PR rename nUnconnectingHeaders and MAX_UNCONNECTING_HEADERS?
10:59 < LarryRuane> amovfx: no it's for each of our peers
10:59 < LarryRuane> dergoegge: because Marco suggested it :) https://github.com/bitcoin/bitcoin/pull/26140#discussion_r1003303992
10:59 < amovfx> ty
10:59 < pablomartin> dergoegge: about... where to store new peer-peer state? CNode (defined in net.h, used by m_nodes(CConnman) and covered by m_nodes_mutex) is concerned with the connection state of the peer.
11:00 < LarryRuane> but seriously, is the rename because it's more accurate to include "msgs" in the name, since it's a count of headers *messages*? (i'm not sure)
11:00 < dergoegge> LarryRuane: yes but the renaming is useful because the variable tracks the number of "headers" messages that did not connect, not the number of headers that didn't connect
11:00 < dergoegge> LarryRuane: yes
11:00 < LarryRuane> dergoegge: +1 that's what i was thinking
11:00 < dergoegge> #endmeeting
11:00 < dergoegge> thank you all for coming!
11:00 < Lov3r_Of_Bitcoin> thanks everyone
11:00 < dergoegge> Q5 is left as an exercise for you all :D
11:01 < pablomartin> thanks dergoegge!
11:01 < hernanmarino> Thanks dergoegge
11:01 < LarryRuane> thanks @dergoegge that was super helpful! great job hosting!!
11:01 < amovfx> thanks everyone and dergeogge, I learned a lot
11:01 < andrewtoth> thanks dergeogge
11:01 < sprainhill> Thank you dergoegge
11:01 -!- inauman [~inauman@ip70-176-106-211.ph.ph.cox.net] has quit [Quit: Connection closed]
11:01 < stickies-v> Thank you very much for hosting this dergoegge ! Learned a lot from this PR.
11:01 -!- Lov3r_Of_Bitcoin [~Lov3r_Of_@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed]
11:02 < dergoegge> pablomartin: yea i would say CNode is for lower level networking state (connection management, sockets, etc.)
11:03 < dergoegge> pablomartin: that used to be different and there was a lot of refactoring to separate our networking stack! CNode used to have a lot of application layer (message processing) state (e.g. addr relay, tx relay, etc)
11:03 < pablomartin> cheers
11:09 -!- sprainhill [~sprainhil@071-088-045-129.res.spectrum.com] has quit [Quit: Connection closed]
11:11 -!- noxim [~AdminUser@user/noxim] has quit [Ping timeout: 248 seconds]
11:40 -!- pablomartin [~pablomart@37.120.199.204] has quit [Quit: Leaving]
11:41 -!- hernanmarino [~hernanmar@186.152.233.128] has quit [Quit: Leaving]
11:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c13e:1768:fb2d:3720] has joined #bitcoin-core-pr-reviews
11:58 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: Client closed]
12:04 -!- noxim [~AdminUser@43.224.169.86] has joined #bitcoin-core-pr-reviews
12:04 -!- noxim [~AdminUser@43.224.169.86] has quit [Changing host]
12:04 -!- noxim [~AdminUser@user/noxim] has joined #bitcoin-core-pr-reviews
12:09 -!- noxim [~AdminUser@user/noxim] has quit [Ping timeout: 255 seconds]
12:24 -!- Talkless [~Talkless@mail.dargis.net] has quit [Ping timeout: 252 seconds]
12:32 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
12:34 -!- amovfx [~amovfx@node-1w7jr9yi65te5njjlzr3t5lya.ipv6.telus.net] has quit [Remote host closed the connection]
12:36 -!- neo70 [~neo@45.4.192.254] has joined #bitcoin-core-pr-reviews
12:37 -!- neo70 [~neo@45.4.192.254] has quit [Client Quit]
12:44 -!- amovfx [~amovfx@node-1w7jr9yi65te5njjlzr3t5lya.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
12:46 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
12:46 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
12:58 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 250 seconds]
13:01 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
13:02 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
13:03 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
13:18 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
13:37 -!- amovfx [~amovfx@node-1w7jr9yi65te5njjlzr3t5lya.ipv6.telus.net] has quit []
14:04 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 248 seconds]
14:10 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Read error: Connection reset by peer]
14:11 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
14:29 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:33 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
15:39 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
15:39 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
16:00 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
16:01 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
16:07 -!- TheRec [~toto@user/therec] has quit [Read error: Connection reset by peer]
16:08 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews
16:08 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host]
16:08 -!- TheRec [~toto@user/therec] has joined #bitcoin-core-pr-reviews
16:20 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
16:26 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 272 seconds]
16:27 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
16:31 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Remote host closed the connection]
16:32 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
17:01 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Remote host closed the connection]
17:01 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
17:06 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Ping timeout: 255 seconds]
17:06 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
17:13 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Ping timeout: 246 seconds]
17:22 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
17:26 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Ping timeout: 255 seconds]
17:29 -!- noxim [~AdminUser@43.224.169.86] has joined #bitcoin-core-pr-reviews
17:29 -!- noxim [~AdminUser@43.224.169.86] has quit [Changing host]
17:29 -!- noxim [~AdminUser@user/noxim] has joined #bitcoin-core-pr-reviews
17:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c13e:1768:fb2d:3720] has quit []
17:39 -!- noxim [~AdminUser@user/noxim] has quit [Read error: Connection reset by peer]
17:40 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
17:41 -!- noxim [~AdminUser@43.224.169.86] has joined #bitcoin-core-pr-reviews
17:41 -!- noxim [~AdminUser@43.224.169.86] has quit [Changing host]
17:41 -!- noxim [~AdminUser@user/noxim] has joined #bitcoin-core-pr-reviews
17:57 -!- jb55 [~jb55@user/jb55] has quit [Ping timeout: 272 seconds]
18:00 -!- noxim_ [~AdminUser@43.224.169.86] has joined #bitcoin-core-pr-reviews
18:00 -!- noxim [~AdminUser@user/noxim] has quit [Ping timeout: 252 seconds]
18:01 -!- instagibbs [~instagibb@pool-100-15-129-252.washdc.fios.verizon.net] has quit [Ping timeout: 268 seconds]
18:02 -!- instagibbs [~instagibb@pool-100-15-129-252.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
18:04 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Remote host closed the connection]
18:04 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
18:14 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Remote host closed the connection]
18:15 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has quit [Read error: Software caused connection abort]
18:15 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
18:18 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews
18:20 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Ping timeout: 276 seconds]
18:49 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
18:53 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Ping timeout: 255 seconds]
18:55 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has quit [Remote host closed the connection]
18:56 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
19:12 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
19:16 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Ping timeout: 246 seconds]
19:20 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
19:20 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
19:26 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has quit [Remote host closed the connection]
19:27 -!- __gotcha [~Thunderbi@94.105.119.88.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
19:30 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
19:35 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Ping timeout: 276 seconds]
20:14 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
20:22 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has quit [Ping timeout: 252 seconds]
20:22 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews
20:26 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
20:31 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
20:35 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Ping timeout: 255 seconds]
20:58 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
21:03 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Ping timeout: 246 seconds]
21:04 -!- aureleoules [~aureleoul@82-64-162-213.subs.proxad.net] has quit [Ping timeout: 250 seconds]
21:17 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
21:23 -!- aureleoules [~aureleoul@82-64-162-213.subs.proxad.net] has joined #bitcoin-core-pr-reviews
21:28 -!- noxim_ [~AdminUser@43.224.169.86] has quit [Ping timeout: 246 seconds]
21:29 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Ping timeout: 276 seconds]
21:33 -!- noxim [~AdminUser@182.253.75.246] has joined #bitcoin-core-pr-reviews
21:33 -!- noxim [~AdminUser@182.253.75.246] has quit [Changing host]
21:33 -!- noxim [~AdminUser@user/noxim] has joined #bitcoin-core-pr-reviews
21:59 -!- noxim [~AdminUser@user/noxim] has quit [Ping timeout: 255 seconds]
22:05 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
22:09 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Ping timeout: 255 seconds]
22:20 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
22:25 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has quit [Ping timeout: 252 seconds]
22:26 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews
22:33 -!- noxim [~AdminUser@43.224.169.86] has joined #bitcoin-core-pr-reviews
22:33 -!- noxim [~AdminUser@43.224.169.86] has quit [Changing host]
22:33 -!- noxim [~AdminUser@user/noxim] has joined #bitcoin-core-pr-reviews
22:57 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
23:28 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has quit [Ping timeout: 246 seconds]
23:57 -!- amovfx [~amovfx@node-1w7jr9yi65te5kzp0irbyyo9u.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Nov 03 00:00:06 2022