--- Day changed Wed Nov 11 2020
00:53 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-111.revip7.asianet.co.th] has joined #bitcoin-core-pr-reviews     
01:32 -!- reallll is now known as belcher     
01:53 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-111.revip7.asianet.co.th] has quit [Ping timeout: 265 seconds]     
02:08 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]     
02:08 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
02:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
02:11 -!- vasild_ is now known as vasild     
02:27 -!- glozow [uid453516@gateway/web/irccloud.com/x-gmntjjbvzgugnwfk] has joined #bitcoin-core-pr-reviews     
02:46 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]     
02:46 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
02:48 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-111.revip7.asianet.co.th] has joined #bitcoin-core-pr-reviews     
02:50 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]     
02:51 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
03:05 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-111.revip7.asianet.co.th] has quit [Ping timeout: 260 seconds]     
03:20 -!- Pete27Reichel [~Pete27Rei@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:25 -!- Pete27Reichel [~Pete27Rei@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 258 seconds]     
05:04 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-111.revip7.asianet.co.th] has joined #bitcoin-core-pr-reviews     
05:12 -!- glozow [uid453516@gateway/web/irccloud.com/x-gmntjjbvzgugnwfk] has quit [Quit: Connection closed for inactivity]     
05:25 -!- pinheadm_ [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadm_]     
05:25 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
05:31 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-111.revip7.asianet.co.th] has quit [Ping timeout: 272 seconds]     
06:33 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
06:44 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
07:38 -!- dappdever [~dappdever@pool-100-8-184-107.nwrknj.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
07:50 -!- crma [bedb3996@190.219.57.150] has joined #bitcoin-core-pr-reviews     
07:50 -!- crma [bedb3996@190.219.57.150] has quit [Remote host closed the connection]     
08:08 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
08:13 -!- crma [bedb3996@190.219.57.150] has joined #bitcoin-core-pr-reviews     
08:35 -!- glozow [uid453516@gateway/web/irccloud.com/x-egbyliprpembytlb] has joined #bitcoin-core-pr-reviews     
08:38 < jnewbery> hi folks. We'll get started in around 20 minutes
08:52 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has joined #bitcoin-core-pr-reviews     
08:52 -!- sergei-t [~sergei@94.103.211.82] has joined #bitcoin-core-pr-reviews     
08:55 -!- elle [~ellemouto@155.93.252.70] has joined #bitcoin-core-pr-reviews     
09:00 < jnewbery> #startmeeting
09:00 -!- andozw [49bd3c74@c-73-189-60-116.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
09:00 < amiti> hi     
09:00 < emzy> hi     
09:00 < jnewbery> what time is it?
09:00 < sergei-t> hi     
09:00 < willcl_ark> hi     
09:00 < elle> hi!     
09:00 < jnewbery> Review Club time!!!
09:00 < stacie> hi     
09:00 < andozw> hi     
09:00 < ariard> hello
09:00 < troygiorshev> hi     
09:00 < jnewbery> welcome all. Feel free to say hi to let everyone know you're here
09:00 -!- lightlike [~lightlike@p200300c7ef1378009905ff7ebf7d3d3e.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
09:00 < pinheadmz> hi     
09:01 < lightlike> hi     
09:01 < jnewbery> anyone here for the first time?
09:01 < nehan> hi     
09:01 < murch> hi     
09:01 < dappdever> hi     
09:01 < jnewbery> anyone here for the 83rd time?
09:02 < pinheadmz> hm maybe ?
09:02 < willcl_ark> alas, not quite
09:02 < pinheadmz> wait how many have there been?
09:02 < murch> jnewbery: Have there been that many?
09:02 < pinheadmz> is this an overflow attack?
09:02 < pinheadmz> whats the modulus
09:02 < jnewbery> 83 so far
09:02 < murch> wow, neat.
09:02 < jnewbery> ok, notes and questions are in the normal place: https://bitcoincore.reviews/19315
09:02 < pinheadmz> i bet only jnewbery can claim that record then
09:03 < jnewbery> pinheadmz: I've missed a couple
09:03 < emzy> I try to be here every time... :)
09:03 < jnewbery> There are changes to the C++ and Python code in that PR. We'll concentrate on the C++ changes in this meeting, but it's important to review the Python code too
09:04 < jnewbery> so if any of you love Python asyncio and networking code, that PR is your chance to shine
09:04 < jnewbery> who had time to review the C++ code this week? (y/n)
09:04 < sergei-t> y (resulting in a bunch of dumb questions!)
09:04 < emzy> n     
09:04 < willcl_ark> A light review; most time was spent trying to familiarise with the existing code in this area...
09:05 < nehan> y lightly
09:05 < jnewbery> sergei-t: there are no dumb questions in Review Club
09:05 < murch> n     
09:05 < amiti> the test framework additions are decently complex. I've tried to make the changes clear, but definitely welcome any feedback !
09:05 < troygiorshev> y light
09:05 < stacie> +1 for light review. Focused more on the concept of the PR as a whole
09:05 < jnewbery> ok, any initial thoughts on the PR? Concept ACKs/NACKs? Thoughts about the approach?
09:05 -!- rain [~rain@cpe-98-14-230-48.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews     
09:05 -!- rain is now known as feulf     
09:05 < lightlike> y (1 month ago though)
09:06 < dappdever> y     
09:06 < sergei-t> if we add new connection types to the tests, why not feeler connections and addr_fetch connections?
09:07 < willcl_ark> Increasing test coverage is good?
09:07 < glozow> hi, sorry i'm late, y
09:07 < jnewbery> sergei-t: great question. Anyone else have thoughts about that? Perhaps also explain what feeler and addr_fetch connections are?
09:07 < troygiorshev> huge concept ACK!  our test framework should try and match things as closely and completely as possible imo
09:07 < glozow> there's outbound-specific behavior we want to test, like banning
09:07 < stacie> Seems like a big win. Is there ever a reason to concept NACK increased test coverage?
09:07 < elle> cool pr! i was surprised that an rpc endpoint for adding specific connection types didnt already exist
09:08 < dappdever> jnewberry: does enabling these connections types open up a need for more functional tests to take advantage of this?
09:08 < amiti> sergei-t: good question, since outbound-full-relay & block-relay-only are the most common connections, I focused on those for this PR, but went a route that would allow for adding more connection types in the future
09:08 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
09:08 < jnewbery> dappdever: these connection types already existed, but we just had no way of testing them in our functional test framework
09:09 -!- feulf [~rain@cpe-98-14-230-48.nyc.res.rr.com] has quit [Remote host closed the connection]     
09:09 < ariard> sergei-t: intuitvely as those connections (feeler/addr_fetch) are short-lived we have less logic around them (e.g we don't have eviction for them)
09:09 < jnewbery> This question links in with the first questions from the review club notes: What are Bitcoin Core’s different connection types?
09:09 < dappdever> so perhaps a good follow-up activity would be authoring those functional tests?
09:09 -!- hmrawal [~hmrawal@2401:4900:2346:80a1:f1a3:fefd:98f8:cdd8] has joined #bitcoin-core-pr-reviews     
09:10 < lightlike> stacie: i think there is - sometimes one would need invasive changes to the main code for better testing - that could be a NACK..
09:10 -!- sergei-t [~sergei@94.103.211.82] has left #bitcoin-core-pr-reviews []     
09:10 < dappdever> inbound, outbound_full_relay, manual, feeler, block_relay, addr_fetch :)
09:10 < stacie> I have a q about the manual connection type. Are these connections restricted to being full relay or block relay only? I’m assuming they default to full relay but could they be block relay only?
09:10 -!- sergei-t [~sergei@94.103.211.82] has joined #bitcoin-core-pr-reviews     
09:10 < jnewbery> dappdever: yes. This PR includes basic tests for outbound full relay and outbound block relay only tests, but more testing of our p2p functionality would definitely be useful
09:10 -!- feulf [~rain@cpe-98-14-230-48.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews     
09:10 < stacie> lightlike - that's a good point!
09:10 < pinheadmz> jnewbery are anchor connections a thing yet? was that merged?
09:11 < willcl_ark> stacie: I think manual connections are only full_relay
09:11 < amiti> stacie: currently there are no manual block relay only connections, but I know this is something ariard is interested in :)
09:11 < ariard> pinheadmz: yeah it was merged but still appear as block-relay-only
09:11 < sergei-t> is it true that the only difference between full relay conns and manual conns is the reaction to their misbehavior?
09:11 < stacie> thanks for the clarification! willcl_ark & amiti
09:11 < jnewbery> pinheadmz: anchor connections are a thing, but that's not a distinct connection type. We save all our block-relay-only connections on shutdown
09:12 < ariard> amiti: because no addr-relay interferences :)
09:13 < jnewbery> stacie: test code needs to be maintained just the same as all other code, so I'd NACK it if it doesn't meet the quality bar or doesn't add enough value to justify the ongoing maintainance cost
09:14 < jnewbery> dappdever: yes, those are currently the six connection types. There's some very nice documentation for them here: https://github.com/bitcoin/bitcoin/blob/d9f5132736f34f31f6e7d009015f917c9dcfec00/src/net.h#L124
09:14 < stacie> jnewbery I hadn't thought of that, and it makes a lot of sense
09:15 < jnewbery> sergei-t: I think there are quite a few subtle behavior differences between manual connections and full relay connections, but I'd need to dig around in the code to find them
09:16 < jnewbery> but in their high-level behavior, they're the same: they both relay txs, blocks and addrs
09:16 < amiti> sergei-t: I don't think thats the only difference. for example, if you restart your node, you'll reconnect to your manually added peers. whereas you probably wont reconnect to the same full-relay outbound peers.
09:16 < jnewbery> Next question! In the test framework, what is the difference between connecting two bitcoind nodes and using a P2P connection?
09:16 < troygiorshev> sergei-t: how and when they are connectd is probably too important to ignore iirc
09:17 < sergei-t> amiti: this reconnection policy  resembles LN node behavior regarding nodes I share channels with :)
09:17 < pinheadmz> i think the add_p2p_connection method uses a pyhton "fake" node wheras connecting two bitcoind nodes.... is connecting two bitcoind nodes
09:17 < willcl_ark> Connecting two nodes directly connects them via their listening p2p ports whereas using P2P.py passes the connection through the P2PConnection class, which lets you instrument and act upon each message exchanged.
09:18 < sergei-t> jnewbery: I don't quite understand this question :( "using a P2P connection" is not connecting two nodes?
09:19 < sergei-t> I guess, the testing mechanics is just unclear to me: when we say "connect from testing framework to the node"... what does actually happen?
09:19 < jnewbery> sergei-t: P2PConnection is a Python class that we use in the test framework: https://github.com/bitcoin/bitcoin/blob/d9f5132736f34f31f6e7d009015f917c9dcfec00/test/functional/test_framework/p2p.py#L120
09:19 < glozow> pinheadmz add_p2p_connection is connecting a test framework object, not connecting bitcoind nodes
09:19 < glozow> test framework p2p object*
09:19 < ariard> sergei-t: I wouldn't confuse the p2p layer with LN link-layer (`channel_reestablish`)
09:19 < dappdever> Is there an example test for connecting two bitcoind nodes directly?  I understood the P2P connection code fairly well but was unsure what to compare it to
09:20 < lightlike> sergei-t: The old terminology (which was changed recently) was "connect to a (python) mininode" instead of "Using a p2p connection".
09:20 < sergei-t> jnewbery: that class is "A low-level connection object to a node's P2P interface" - which node?
09:20 < pinheadmz> glozow thats what i meant! a "fake" node yeah
09:20 < willcl_ark> it's more like a passthrough/man-in-the-middle as I see it
09:21 < hmrawal> can we use the RPC connection in a test framework ? or are there any other connection methods which can be used in a test framework ?
09:21 < jnewbery> dappdever: Look for any tests that call connect_nodes()
09:21 < sergei-t> OK, so the testing framework maintains a "fake" node that connects to the "real" node? and there are two ways of doing so - "directly" or via P2P?
09:21 < jnewbery> hmrawal: Yes, we can use the RPC interface in the tests
09:21 < glozow> omg i misunderstood this question. we're talking about connecting TestNodes vs connecting P2PConnections?
09:22 < jnewbery> sergei-t: I think you're getting your terminology mixed up. A test contains one or more bitcoind instances under test. We can interact with those instances from the test framework using the RPC interface or the P2P interface. We can also get the different bitcoind instances to connect to each other using p2p.
09:23 < willcl_ark> glozow: yeah in tests you can either directly connect them, or connect via P2P.py
09:23 < jnewbery> P2PConnection is a low-level class that the Python framework uses to connect to the bitcoind node (and after this PR is merged, it will be able to accept an outbound connection _from_ the bitcoind node)
09:24 < jnewbery> willcl_ark: what do you mean 'directly' connect to them?
09:24 < willcl_ark> jnewbery: well using their RPC to connect to each other
09:24 < troygiorshev> lightlike: thanks, mininode has been renamed to p2p, got it
09:24 < sergei-t> jnewbery: is it correct that the test framework spins up one or more "real" nodes that it tests and an additionally a "fake" node that can connect to "real" nodes?
09:25 < jnewbery> willcl_ark: RPC is a different interface. We're just talking about P2P connections here
09:25 < hmrawal> in the test framework, is the bitcoind instance treated as a node ?
09:26 < jnewbery> sergei-t: there's no "fake" node. The test framework can open P2P connections to the bitcoind instances. You could call the test framework a "fake" node if you wanted to, but I don't think it makes things any clearer (in fact, I think it's confusing terminology)
09:26 < jnewbery> hmrawal: the bitcoind instance is a node, yes
09:26 < troygiorshev> hmrawal: yep exactly.  Note that we can have multiple nodes (aka multiple bitcoind instances)
09:26 < willcl_ark> jnewbery: Ok I think i see now
09:27 < hmrawal> so n number of instances = n number of nodes right!
09:27 < glozow> https://www.irccloud.com/pastebin/s5jUB5Ac/
09:27 < sergei-t> jnewbery: fair enough! I just perceive anything that can connect to a node as a node itself, now I see this isn't always true
09:28 < amiti> for people interested in learning more: when you are writing a functional test, in `set_test_params` you have to set `self.num_nodes`. this creates `TestNode` objects that wrap a bitcoind instance (and does things like forward along RPC calls)
09:28 < amiti> if you have multiple test nodes initialized, they get connected to one another in `setup_nodes` in `test_framework.py`
09:29 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-pr-reviews     
09:29 -!- fodediop [~fodediop@41.214.81.127] has joined #bitcoin-core-pr-reviews     
09:29 < sergei-t> so in question 2 "connecting two bitcoind nodes" refers to calling connect_nodes()?
09:29 < glozow> if i might plug my test framework intro doc https://github.com/glozow/bitcoin-notes/blob/master/test_framework_intro.md
09:30 < glozow> sergei-t i believe so yes
09:30 < jnewbery> glozow: thank you. That's a great doc!
09:30 < sergei-t> glozow: great page, will read, thanks!
09:30 < troygiorshev> glozow: amazing!
09:30 < jnewbery> Next question. Why would it be useful to create outbound or block-relay-only connections in the test framework?
09:30 < willcl_ark> glozow: very nice!
09:31 < amiti> +1 awesome writeup glozow
09:31 < sergei-t> and the second option in question 2 is connecting the nodes... how if not wth connect_nodes()? sorry for jumping back to q2
09:31 -!- pedr0fr [5f5f0d25@a95-95-13-37.cpe.netcabo.pt] has joined #bitcoin-core-pr-reviews     
09:31 < lightlike> sergei-t: I think it is a matter of terminology. I still think of the P2PConnection instances as objects, mock/fake nodes that we control and use to send the real node whatever p2p messages we wish.
09:31 < dappdever> jnewberry: perhaps it is useful to test non-manual functionality, such as automatic disconnect or discouragement filter?
09:31 < elle> useful since there are a few places in the code where there is a switch on connection path. so we want to test these different code paths
09:32 < willcl_ark> jnewbery: presumably without being able to set up those types of nodes, then we can't test their codepaths
09:32 < elle> *connection type
09:32 < stacie> glozow that pastebin link you shared earlier is also really helpful!
09:32 < glozow> thank you everyone i feel very appreciated today ^_^
09:32 < troygiorshev> jnewbery: to test misbehaving outbound connections?
09:32 < jnewbery> yay. We appreciate you glozow!
09:34 < jnewbery> sergei: question 2 should say `P2PConnection`, not "P2P Connection". The difference is that the second option is creating a p2p connection using the python P2PConnection object, which as lightlike says, is a mock/fake to test the p2p interface
09:34 < glozow> +1 to troygiorshev, https://github.com/bitcoin/bitcoin/blob/d9f5132736f34f31f6e7d009015f917c9dcfec00/src/net_processing.cpp#L3779 limits us greatly in the testing department
09:35 < jnewbery> dappdever elle troygiorshev: exactly, so we can test the code paths where we treat outbound and block-relay-only connections differently from manual connections
09:35 < glozow> i tried to write a banning test once, and spent 2 days tracing why it didn't work - this is the line hahaha
09:35 < pinheadmz> elle +1 for example we "prefer" not to download blocks from inbound peers
09:36 < pinheadmz> and the version handshake is different of course
09:36 < pinheadmz> (just grepping net_processing for IsInboundConn)
09:36 < jnewbery> Q4. How does this PR enable creating outbound and block-relay-only connections in the test framework?
09:37 < pinheadmz> add_p2p_connection() creates  an inbound, and new method add_outbound_p2p_connection() ...
09:37 < willcl_ark> It adds `add_outbound_p2p_connection()` to test/functional/test_framework/test_node.py::TestNode which can be added in "outbound" or "blockrelay" mode
09:38 < jnewbery> Yes, and what changes in the C++ allow us to create those outbound connections?
09:39 < sergei-t> AddConnection() function added to CConnman ?
09:39 < stacie> The new addconnection RPC
09:39 < willcl_ark> I think thats CConnman::AddConnection
09:40 < jnewbery> that's right! There's a new RPC called addconnection, which calls through to a new CConnman method called AddConnection(). Good team effort :)
09:41 < jnewbery> The RPC method is hidden. Why do we make some RPC methods hidden, or “test only”?
09:42 < glozow> users would get confooz about addconnection
09:42 < pinheadmz> jnewbery to protect curious meddling users!
09:42 < sergei-t> because the behavior of these RPCs is not triggered by an RPC call in "real world"? I.e., full relay connections only appear to randomly chosen nodes, it the node is specified, it's a manual connection by definition
09:42 < emzy> They are not stable, can change in the future.
09:43 < troygiorshev> emzy: +1
09:43 < pinheadmz> although this RPC is also disabled on test and mainnet
09:43 < jnewbery> emzy: I think that's the most important reason. As soon as you make an interface public, then it becomes part of some user's workflow and you can never change it!
09:44 < jnewbery> pinheadmz: yes. Good observation.
09:44 < sergei-t> jnewbery: so in principle this RPC may become public if it's considered stable?
09:44 < hmrawal> I think it should
09:44 < glozow> i don't see why users should be able to use this
09:45 < dappdever> the connection type should be discerned from the messages exchanged, I think
09:45 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews     
09:45 < willcl_ark> Specifying a blocksonly peer could be useful, in some niche?
09:45 < sergei-t> it would be like manual connection but with behavior of full relay connection... _if_ we were to add it, would it make more sense to parameterize manual connection instead?
09:45 < jnewbery> sergei-t: it's possible, but I think a good general principle is that new features/interfaces should be as tightly restricted as possible to begin with. It's much easier to give users features than take them away.
09:46 < amiti> when implementing, I initially tried adding the functionality to the `addnode`RPC, but didn't like adding yet another definition to an already overloaded endpoint, so separated it out into a new RPC endpoint. then made it test only for mostly these reasons, like more flexibility & its easier to isolate test needs vs trying to encapsulate all possible uses on mainnet
09:46 < amiti> (addnode RPC adds manual connections)
09:46 < jnewbery> Normal users should never need this functionality though. I could only imagine it being useful for testing or niche use-cases
09:46 < pinheadmz> and we already have good rpc to create outbound conenction
09:47 < pinheadmz> if you want to accept a specific inbound you could use whitebind or somthing maybe
09:47 < jnewbery> peer selection in general is something that should be automated and hidden from the vast majority of users
09:47 < jnewbery> 6. For each different type of connection, what is the maximum number of connections that Bitcoin Core will have by default?
09:48 < hmrawal> MAX_OUTBOUND_FULL_RELAY_CONNECTIONS = 8
09:48 < ariard> jnewbery: disagree, manual peering can be really useful
09:48 < hmrawal> MAX_BLOCK_RELAY_ONLY_CONNECTIONS = 2
09:48 < hmrawal> MAX_FEELER_CONNECTIONS = 1
09:48 < hmrawal> MAX_ADDNODE_CONNECTIONS = 8
09:48 < emzy> 8 full peers, 2 blocks only, one deeler.
09:48 < stacie> https://github.com/bitcoin/bitcoin/blob/f51006b8184a56fe18a5e64f43846f38fb982993/src/net.h#L62
09:48 < sergei-t> inbound = 125 - (all of the above)?
09:48 < emzy> *feeler
09:48 -!- darius7 [516cb8be@cpc159747-finc22-2-0-cust189.4-2.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
09:49 < willcl_ark> INBOUND: 10, OUTBOUND_FULL_RELAY: 8, MANUAL: ?, FEELER: 1, BLOCK_RELAY: 2, ADDR_FETCH: 1 (at a time)
09:49 < hmrawal> willcl_ark: where did you find the inbound and addr_fetch connections ?
09:49 < stacie> I don't know if those constants are the correct answer (MAX_OUTBOUND_FULL_RELAY_CONNECTIONS, MAX_BLOCK_RELAY_ONLY_CONNECTIONS, etc.) but that link to net.h is where I found them
09:49 < sergei-t> willcl_ark: where's the max for addr_fetch connections defined?
09:49 < jnewbery> ariard: if the majority of users have to manually configure their peer connections, then I don't think the developers have done their job
09:50 < willcl_ark> hmrawal: sergei-t: I felt reading net.cpp that only one at a time was going to be allowed to happen?
09:51 < sergei-t> I just see constants explicitly defined in net.h for all except addr_fetch
09:51 < glozow> ariard manual peering is fine, but should be done using the interface for creating manual connections, which already exists
09:51 < ariard> jnewbery: well just opening few manual connections might protect you against potential peer selection vulns, or settup some multihoming
09:51 < hmrawal> even I read it in net.h but didn't get the inbound and addrfetch
09:51 < jnewbery> willcl_ark: if you allow inbound connections, then by default you'll allow up to 125 connections in total
09:51 -!- imprecise [~imprecise@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
09:51 < amiti> inbound is implicit, max connections is 125, so subtract the outbounds we have open
09:52 < ariard> glozow: but you can't open block-relay-only manual connections with current interface?
09:52 < hmrawal> jnewberry: exactly
09:52 < imprecise> Am I late or early?
09:52 < jnewbery> 8 of those will be for full outbound and 2 for block-relay outbound, so generally 115 would be left for inbound
09:52 < glozow> ariard why do you need manual block-relay-only?
09:52 < sergei-t> amiti: subtract the outbound including addr_fetch? (supposedly 1, but not defined in net.h)
09:52 < ariard> there is a difference between a default setting for a wide majority of users and fine-setting its peering according to your network deployment
09:52 < willcl_ark> jnewbery: ah whoops, I see that now...
09:52 < amiti> imprecise: we are 52 minutes into the session :)
09:53 < ariard> glozow: your current manuals are full-relay, thus I can guess their presence through tx/addr relay
09:53 < imprecise> ':0 amiti thanks
09:53 < amiti> addr_fetch connections are short-lived connections only (possibly) made on startup, I don't remember exactly how the counting works but for the majority of the time running a node, we won't have any open
09:53 < jnewbery> imprecise: your timeliness could use some work, but your nick suggests an admirable level of self-awareness
09:54 < jnewbery> ok, final question: What are CSemaphore and CSemaphoreGrant used for in CConnman?
09:54  * imprecise chef kiss to fabulous British humor
09:54 < jnewbery> :)     
09:55 < hmrawal> jnewbery: so I get the outbound but how's addr_fetch defined ?
09:55 < glozow> ariard maybe a txrelay param in `addnode`... manual conn should be manual
09:56 < willcl_ark> hmrawal: As I read it its implicit; you don't keep them open so there's not many (maybe only one at a time?)
09:56 -!- fodediop1 [~fodediop@41.214.83.237] has joined #bitcoin-core-pr-reviews     
09:57 < hmrawal> why is that not subtracted from max peers (125) ?
09:57 < jnewbery> willcl_ark: I believe that's right. ADDR_FETCH connections can only be opened from the ProcessAddrFetch() function
09:57 < jnewbery> hmrawal: they're very short-lived. You open a connection, send a getaddr message, wait for the response and close the connection
09:58 -!- fodediop [~fodediop@41.214.81.127] has quit [Read error: Connection reset by peer]     
09:58 < sergei-t> Semaphores are used to not exceed the max allowed number of connections (but I'm not exactly sure how they do it)... what does "grant" mean in this context?
09:58 < pinheadmz> jnewbery maybe i missed this but why do we need special connections just for addr fetch? do we not trust our exisintg peers? (something seomthing eclipse attack?)
09:59 < amiti> pinheadmz: its if you don't have any existing peers yet
09:59 < pinheadmz> amiti aha thank you - we have dns seeds for this as well though right?
09:59 < jnewbery> sergei-t: exactly. It's used to not exceed the maximum number of outbound connections. If you can't get a semaphore grant it means that all outbound connection slots are filled
10:00 < amiti> so, if you're starting up a node for the first time. you connect to the DNS seeds with addr fetch connections. they send you back addresses of nodes to populate your addrman, you close those connections and start opening connections to the general network
10:00 < ariard> glozow: yeah IMO it should be both block-relay and manual something not captured by our current connection type struct
10:00 < willcl_ark> amiti: do we ever "reload" on addresses after we've been running for a while?
10:00 < jnewbery> ding ding ding. That's time
10:00 < kanzure> timezones
10:00 < jnewbery> #endmeeting
10:00 < glozow> AW MAN
10:00 < sipa> hi!     
10:00 < kanzure> hi     
10:00 < amiti> there's also a fallback set of seeds incase there's a crazy infrastructure attack or you don't want to connect to DNS, but I believe these are the only two groups that we automatically connect to via addrfetch
10:00 < imprecise> hi     
10:00 < pedr0fr> I have a question. I want to try the ZMQ sequence notifier (merged on the 23rd of September - PR #19572).I am willing to wait for bitcoin core 0.21.0rc1, which, if I understand correctly, was planned for the 1st of November (https://github.com/bitcoin/bitcoin/issues/18947). When is 0.21.0rc1 expected to be released? Thank you.
10:01 < glozow> thank u jnewbery and amiti for the fabulous content
10:01 < troygiorshev> thanks jnewbery and amiti !
10:01 < dappdever> thank you!
10:01 < willcl_ark> yes thanks jnewbery!
10:01 < lightlike> thanks!
10:01 < elle> thanks guys! very informative session!
10:01 < emzy> Thank you!
10:01 < imprecise> *pound* start meeting for people who got mistaken on time zone issues
10:01 < amiti> willcl_ark: what do you mean reload?
10:01 < hmrawal> thank you guys
10:01 < sipa> pedr0fr: after 0.21 forks off, which is still waiting on a few issues
10:01 < fodediop1> thank you everybody
10:01 < sergei-t> thank you!
10:01 < amiti> thanks all for coming! thanks jnewbery for hosting :)
10:01 < jnewbery> thanks for coming everyone!
10:02 < imprecise> ty for hosting jnewbery and amiti, apologies for not making the meeting
10:02 < willcl_ark> amiti: well you say we only do it at fresh startup; what about a nodes that's starting up again after being offline for a while, or a node that's been running for some time without being turned off
10:02 < hmrawal> asking silly questions isn't against the rules right ? :-p
10:02 < stacie> Thanks jnewbery and amiti!
10:02 < glozow> you probably don't need that, because you can read from peers.dat
10:02 < pedr0fr> sipa: Thank you. I see that it is waiting for three issues.
10:02 -!- darius7 [516cb8be@cpc159747-finc22-2-0-cust189.4-2.cable.virginm.net] has quit [Remote host closed the connection]     
10:02 < dappdever> where is the code for handling misbehaving outbound connections?  it seems like that will be testable after this PR, correct?
10:03 < glozow> dappdever grep for Misbehaving()
10:03 < willcl_ark> glozow: sure, I'm just wondering if we ever make those connections if we have a "healthy" peers.dat
10:03 < glozow> in net_processing.cpp
10:03 < fodediop1> exit
10:03 < amiti> willcl_ark: if the node has been running for a while, you'd expect the addrman to be populated with addresses from normal address relay behaviors
10:03 < willcl_ark> ok     
10:04 < amiti> willcl_ark: I don't believe so. if you were to shut down the node, wipe your `peers.dat` and then restart, you might create addr fetch connections again
10:04 < sipa> addr_fetch was originally introduced for situations where we can't just resolve DNS as a means of getting IP addresses (specifically when only connecting through tor)
10:06 < sipa> so instead of asking a DNS seed, we *connect* to one (which means the exit node we're using will resolve for us, and open a connection to one of the resolved IPs); we still want a lot of IPs though, so we ask that node
10:07 < sipa> it's essentially adding a redirection step, to work around the fact that DNS seeds can't be queried directly through tor
10:07 -!- hmrawal [~hmrawal@2401:4900:2346:80a1:f1a3:fefd:98f8:cdd8] has left #bitcoin-core-pr-reviews ["Leaving"]     
10:09 -!- sergei-t [~sergei@94.103.211.82] has left #bitcoin-core-pr-reviews []     
10:09 -!- crma [bedb3996@190.219.57.150] has quit [Remote host closed the connection]     
10:11 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
10:12 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has quit [Quit: stacie]     
10:20 -!- fodediop1 [~fodediop@41.214.83.237] has quit [Ping timeout: 260 seconds]     
10:25 -!- fodediop1 [~fodediop@41.214.83.237] has joined #bitcoin-core-pr-reviews     
10:28 -!- anir [40bba0b7@64.187.160.183] has joined #bitcoin-core-pr-reviews     
10:31 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 240 seconds]     
10:31 -!- fodediop1 [~fodediop@41.214.83.237] has quit [Ping timeout: 272 seconds]     
10:33 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
10:36 -!- fodediop1 [~fodediop@41.214.83.237] has joined #bitcoin-core-pr-reviews     
10:41 -!- fodediop1 [~fodediop@41.214.83.237] has quit [Ping timeout: 258 seconds]     
10:43 -!- feulf [~rain@cpe-98-14-230-48.nyc.res.rr.com] has quit [Remote host closed the connection]     
10:43 -!- fodediop1 [~fodediop@41.214.83.237] has joined #bitcoin-core-pr-reviews     
10:44 -!- feulf [~rain@cpe-98-14-230-48.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews     
10:48 -!- feulf [~rain@cpe-98-14-230-48.nyc.res.rr.com] has quit [Ping timeout: 256 seconds]     
10:49 -!- elle [~ellemouto@155.93.252.70] has quit [Quit: leaving]     
10:49 -!- pedr0fr [5f5f0d25@a95-95-13-37.cpe.netcabo.pt] has quit [Remote host closed the connection]     
11:07 -!- jesseposner [~jesse@98.37.146.62] has quit [Ping timeout: 260 seconds]     
11:08 -!- feulf [~rain@cpe-98-14-230-48.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews     
11:20 -!- feulf [~rain@cpe-98-14-230-48.nyc.res.rr.com] has quit [Remote host closed the connection]     
11:21 -!- feulf [~rain@cpe-98-14-230-48.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews     
11:25 -!- feulf [~rain@cpe-98-14-230-48.nyc.res.rr.com] has quit [Ping timeout: 258 seconds]     
11:28 -!- feulf [~rain@cpe-98-14-230-48.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews     
11:32 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews     
11:40 -!- fodediop1 [~fodediop@41.214.83.237] has quit [Ping timeout: 265 seconds]     
11:48 -!- feulf [~rain@cpe-98-14-230-48.nyc.res.rr.com] has quit []     
11:56 -!- fodediop1 [~fodediop@41.214.83.237] has joined #bitcoin-core-pr-reviews     
12:01 -!- fodediop1 [~fodediop@41.214.83.237] has quit [Ping timeout: 260 seconds]     
12:14 -!- lightlike [~lightlike@p200300c7ef1378009905ff7ebf7d3d3e.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
12:17 -!- fodediop1 [~fodediop@41.214.83.237] has joined #bitcoin-core-pr-reviews     
12:21 -!- fodediop1 [~fodediop@41.214.83.237] has quit [Ping timeout: 260 seconds]     
12:22 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]     
12:24 -!- fodediop1 [~fodediop@41.214.83.237] has joined #bitcoin-core-pr-reviews     
12:42 -!- andozw [49bd3c74@c-73-189-60-116.hsd1.ca.comcast.net] has quit [Remote host closed the connection]     
13:05 -!- glozow [uid453516@gateway/web/irccloud.com/x-egbyliprpembytlb] has quit [Quit: Connection closed for inactivity]     
13:15 -!- imprecise [~imprecise@195.181.160.175.adsl.inet-telecom.org] has left #bitcoin-core-pr-reviews []     
13:37 -!- Netsplit *.net <-> *.split quits: thomasb06, dr_orlovsky, Landryl, tinova, justinmoon, willcl_ark, raj_
13:37 -!- Netsplit over, joins: dr_orlovsky, raj_, willcl_ark, justinmoon, Landryl, tinova, thomasb06
13:38 -!- jesseposner [~jesse@98.37.146.62] has joined #bitcoin-core-pr-reviews     
13:40 -!- Netsplit *.net <-> *.split quits: tryphe_, ariard, nothingmuch, Nebraskka, harrigan, Henry151
13:40 -!- Netsplit *.net <-> *.split quits: robert_spigler, avril
13:40 -!- Netsplit *.net <-> *.split quits: Zenton, wullon, jakesyl, belcher, tynes
13:41 -!- Netsplit over, joins: robert_spigler, avril
13:41 -!- Netsplit over, joins: belcher, jakesyl, wullon, Zenton, tynes
13:41 -!- avril [wha@unaffiliated/avril] has quit [Max SendQ exceeded]     
13:41 -!- |avril [wha@chick.sex0r.net] has joined #bitcoin-core-pr-reviews     
13:41 -!- Netsplit *.net <-> *.split quits: mattdrollette, S3RK, gwillen, darosior
13:41 -!- Netsplit over, joins: ariard, Nebraskka, harrigan, nothingmuch, Henry151, tryphe_
13:41 -!- Netsplit *.net <-> *.split quits: CubicEarth, rabidus, jesseposner, likewhoa, jeremyrubin
13:41 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Max SendQ exceeded]     
13:41 -!- Henry151 [~bishop@ns3007530.ip-151-80-44.eu] has quit [Max SendQ exceeded]     
13:42 -!- Netsplit over, joins: likewhoa, CubicEarth, jeremyrubin, rabidus, jesseposner
13:42 -!- Netsplit over, joins: S3RK, gwillen, darosior, mattdrollette
13:42 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews     
13:42 -!- Henry151 [~bishop@ns3007530.ip-151-80-44.eu] has joined #bitcoin-core-pr-reviews     
13:43 -!- Netsplit *.net <-> *.split quits: virtu, sdaftuar, vasild, ghost43, _andrewtoth_, sipa, jb55, kristapsk
13:43 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-nslspbgiedwhglhg] has quit [Ping timeout: 272 seconds]     
13:43 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-njtrdildhtememmh] has quit [Ping timeout: 260 seconds]     
13:44 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-lesqambwizyhgzeh] has quit [Ping timeout: 264 seconds]     
13:44 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-uxpvzzgmfufkdehc] has quit [Ping timeout: 244 seconds]     
13:45 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-vkxamqyuloefpaxf] has quit [Ping timeout: 264 seconds]     
13:45 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
13:45 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
13:45 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
13:45 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
13:45 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews     
13:45 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews     
13:45 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews     
13:45 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews     
13:45 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-vmynyavngcrbrncl] has joined #bitcoin-core-pr-reviews     
13:46 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-rzimnonivggyksik] has joined #bitcoin-core-pr-reviews     
13:46 -!- Netsplit *.net <-> *.split quits: darosior, michaelfolkson, MarcoFalke, fjahr, provoostenator, murch, jesseposner, harding, gleb2, tinova,  (+90 more, use /NETSPLIT to show all of them)
13:47 -!- Netsplit over, joins: elichai2, Henry151, phantomcircuit, dongcarl, kristapsk, ghost43, jb55, tryphe_, CubicEarth, likewhoa (+87 more)
13:48 -!- Netsplit *.net <-> *.split quits: PaulTroon, _0x0ff, provoostenator, digi_james, notmandatory, fjahr, d4nte, phantomcircuit
13:50 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]     
13:50 -!- Netsplit over, joins: jrawsthorne, TheRec, fodediop1
13:51 -!- phantomcircuit [~phantomci@2604:a880:1:20::f2:c001] has joined #bitcoin-core-pr-reviews     
13:51 -!- fjahr [sid374480@gateway/web/irccloud.com/x-idmozsqtyjsaymjn] has joined #bitcoin-core-pr-reviews     
13:51 -!- digi_james [sid281632@gateway/web/irccloud.com/x-jxyqlpnraydxvprs] has joined #bitcoin-core-pr-reviews     
13:51 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-pr-reviews     
13:51 -!- PaulTroon [rich@2600:3c00::f03c:92ff:fe8e:dce6] has joined #bitcoin-core-pr-reviews     
13:51 -!- _0x0ff [~potatoe@2001:bc8:47b0:123::1] has joined #bitcoin-core-pr-reviews     
13:51 -!- Netsplit over, joins: d4nte
13:51 -!- notmandatory [notmandato@2600:3c00::f03c:92ff:fe8e:dce6] has joined #bitcoin-core-pr-reviews     
13:51 -!- Netsplit *.net <-> *.split quits: jonatack, troygiorshev, Henry151
13:51 -!- Netsplit *.net <-> *.split quits: djinni`
13:53 -!- Netsplit over, joins: djinni`
13:53 -!- Netsplit over, joins: jonatack, Henry151, troygiorshev
13:53 -!- Netsplit *.net <-> *.split quits: amiti, Jackielove4u
13:53 -!- Netsplit over, joins: amiti, Jackielove4u
13:53 -!- Netsplit *.net <-> *.split quits: jnewbery, aj, pinheadmz, kcalvinalvin
13:54 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-ohjdexvtbvfupplm] has joined #bitcoin-core-pr-reviews     
13:54 -!- Netsplit *.net <-> *.split quits: wallet42__, corollari__, kallewoof, harding, ryanofsky, michaelfolkson, RubenSomsen, hebasto, takinbo
13:54 -!- Netsplit over, joins: pinheadmz, aj, kcalvinalvin, jnewbery
13:54 -!- Netsplit *.net <-> *.split quits: nehan, MarcoFalke, dongcarl, dappdever, MasterdonX, gleb2, shesek, tuxcanfly
13:54 -!- Netsplit over, joins: RubenSomsen, hebasto, takinbo, michaelfolkson, harding, kallewoof, wallet42__, corollari__, ryanofsky
13:55 -!- Netsplit over, joins: nehan, shesek, dongcarl, MarcoFalke, gleb2, MasterdonX, dappdever, tuxcanfly
13:55 -!- Netsplit *.net <-> *.split quits: anir
13:55 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Max SendQ exceeded]     
13:55 -!- Netsplit over, joins: anir
13:55 -!- dongcarl1 [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews     
13:56 -!- amiti [sid373138@gateway/web/irccloud.com/x-guuzadlisysaifyz] has quit [Ping timeout: 246 seconds]     
13:58 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-rzimnonivggyksik] has quit [Ping timeout: 244 seconds]     
14:01 -!- amiti [sid373138@gateway/web/irccloud.com/x-ivprtaazvjpsstjf] has joined #bitcoin-core-pr-reviews     
14:01 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-rbfbgiogvwgpuexh] has joined #bitcoin-core-pr-reviews     
14:04 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
14:06 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-iijmcrkchxvqkkyl] has joined #bitcoin-core-pr-reviews     
14:07 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection]     
14:08 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
14:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
14:12 -!- vasild_ is now known as vasild     
14:13 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-vkobkkcmxhikgfgy] has joined #bitcoin-core-pr-reviews     
14:13 -!- glozow [uid453516@gateway/web/irccloud.com/x-xodpewyyywlkchym] has joined #bitcoin-core-pr-reviews     
14:16 -!- |avril [wha@chick.sex0r.net] has quit [Quit: later skater]     
14:16 -!- avril [wha@chick.sex0r.net] has joined #bitcoin-core-pr-reviews     
14:16 -!- avril [wha@chick.sex0r.net] has quit [Changing host]     
14:16 -!- avril [wha@unaffiliated/avril] has joined #bitcoin-core-pr-reviews     
14:17 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]     
14:18 -!- fodediop1 [~fodediop@41.214.83.237] has quit [Ping timeout: 258 seconds]     
14:33 -!- fodediop1 [~fodediop@41.214.83.237] has joined #bitcoin-core-pr-reviews     
14:38 -!- fodediop1 [~fodediop@41.214.83.237] has quit [Ping timeout: 260 seconds]     
15:14 -!- fodediop1 [~fodediop@41.214.83.237] has joined #bitcoin-core-pr-reviews     
15:19 -!- fodediop1 [~fodediop@41.214.83.237] has quit [Ping timeout: 264 seconds]     
15:33 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews     
15:35 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]     
15:36 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews     
15:49 -!- anir [40bba0b7@64.187.160.183] has quit [Remote host closed the connection]     
16:01 -!- gleb2 [~gleb@178.150.137.228] has quit [Quit: Ping timeout (120 seconds)]     
16:02 -!- gleb [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews     
16:20 -!- seven__ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Read error: Connection reset by peer]     
17:00 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th] has joined #bitcoin-core-pr-reviews     
17:06 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th] has quit [Ping timeout: 264 seconds]     
17:10 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th] has joined #bitcoin-core-pr-reviews     
17:35 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th] has quit [Ping timeout: 260 seconds]     
17:46 -!- da39a3ee5e6b4b0d [~da39a3ee5@67.23.55.162] has joined #bitcoin-core-pr-reviews     
18:27 -!- da39a3ee5e6b4b0d [~da39a3ee5@67.23.55.162] has quit [Quit: Textual IRC Client: www.textualapp.com]     
18:37 -!- fodediop1 [~fodediop@41.214.83.237] has joined #bitcoin-core-pr-reviews     
18:37 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th] has joined #bitcoin-core-pr-reviews     
18:42 -!- fodediop1 [~fodediop@41.214.83.237] has quit [Ping timeout: 265 seconds]     
18:45 -!- glozow [uid453516@gateway/web/irccloud.com/x-xodpewyyywlkchym] has quit [Quit: Connection closed for inactivity]     
19:19 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-69-228.revip7.asianet.co.th] has quit [Ping timeout: 265 seconds]     
19:54 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
19:56 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]     
20:04 -!- 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:32 -!- musdom [~Thunderbi@2001:f40:904:56bb:b4f5:b962:dfdb:e3da] has joined #bitcoin-core-pr-reviews     
21:06 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews     
21:07 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 260 seconds]     
22:43 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews     
23:28 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews     
23:30 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]     
23:55 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews     
23:55 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 240 seconds]