--- Day changed Wed Feb 03 2021
01:56 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 258 seconds]     
02:30 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 268 seconds]     
02:31 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
02:53 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection]     
03:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
03:20 -!- Eulalia33Luettge [~Eulalia33@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:20 < jnewbery> michaelfolkson: that PR has unresolved review comments from October 2020. I don't think it's ready for review right now.
03:21 < jnewbery> it's also failing CI
03:22 < michaelfolkson> jnewbery: Fair enough. Will you be making progress on it in next few days luke-jr or should we aim for another week?
03:25 -!- Eulalia33Luettge [~Eulalia33@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds]     
03:51 -!- jadi [~jadi@213.207.193.58] has joined #bitcoin-core-pr-reviews     
03:53 -!- jadi_ [~jadi@213.207.193.58] has quit [Ping timeout: 265 seconds]     
04:10 -!- belcher_ is now known as belcher     
04:51 -!- jadijadi [~jadi@213.207.193.58] has joined #bitcoin-core-pr-reviews     
04:53 -!- jadi [~jadi@213.207.193.58] has quit [Ping timeout: 272 seconds]     
05:25 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
05:25 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
05:38 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
05:38 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
05:40 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
05:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
06:13 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
06:13 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
06:14 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]     
06:14 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has joined #bitcoin-core-pr-reviews     
06:18 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
06:20 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has left #bitcoin-core-pr-reviews ["Leaving"]     
06:22 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has joined #bitcoin-core-pr-reviews     
06:23 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has quit [Client Quit]     
06:26 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has joined #bitcoin-core-pr-reviews     
06:26 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has quit [Client Quit]     
07:06 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]     
07:39 -!- jadijadi [~jadi@213.207.193.58] has quit []     
08:00 -!- jay74 [70c492d2@112.196.146.210] has joined #bitcoin-core-pr-reviews     
08:02 -!- jay74 [70c492d2@112.196.146.210] has quit [Client Quit]     
08:06 -!- jadi [~jadi@213.207.193.58] has joined #bitcoin-core-pr-reviews     
08:13 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews     
08:29 -!- prayank [~andr0irc@2402:8100:206c:22b2:dd42:3f8f:ab4e:e59d] has joined #bitcoin-core-pr-reviews     
08:31 -!- lightlike [~lightlike@p200300c7ef11d00045c791784d59404a.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews     
08:37 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews     
08:50 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has joined #bitcoin-core-pr-reviews     
08:53 -!- troygiorshev [~troygiors@172-97-171-42.cpe.distributel.net] has joined #bitcoin-core-pr-reviews     
08:56 < jnewbery> hi folks. Get your engines started. PR Review Club begins in 4 minutes 🚀
08:56 < sunon> Wooo 🚀
08:58 -!- maqusat [522fec0b@cpc73666-dals20-2-0-cust10.20-2.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
08:58 -!- AnthonyRonning [ae2ddd4c@174-045-221-076.res.spectrum.com] has joined #bitcoin-core-pr-reviews     
08:59 -!- murtyjones [60ef6e85@pool-96-239-110-133.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
09:00 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
09:00 < jnewbery> #startmeeting
09:00 < jnewbery> Howdy! Welcome to PR Review Club!
09:00 < shafiunmiraz0> hi     
09:00 < jnewbery> Feel free to say hi to let everyone know you're here.
09:00 < murtyjones> hiya
09:00 < norisgOG> Hi     
09:00 < schmidty> hi     
09:00 < willcl_ark> hi     
09:00 < troygiorshev> hi!     
09:00 < sishir> hi     
09:00 < dhruvm> hi     
09:00 < AnthonyRonning> hi     
09:00 < sunon> hi!     
09:01 < lightlike> hi     
09:01 < jnewbery> Anyone here for the first time?
09:01 < shafiunmiraz0> i am first time
09:01 < glozow> howdy!
09:01 < michaelfolkson> hi     
09:01 < willcl_ark> welcome shafiunmiraz0 :)
09:01 < shafiunmiraz0> thank you so much
09:01 < AnthonyRonning> shafiunmiraz0: welcome!
09:02 < jnewbery> welcome shafiunmiraz0!
09:02 < maqusat> hi, it's my first time too
09:02 < jnewbery> Before we begin, a few reminders:
09:02 < prayank> hi     
09:02 < jnewbery> welcome maqusat!
09:02 < jnewbery> All questions are welcome. We're all here to learn.
09:02 < dhruvm> welcome maqusat!
09:02 < jnewbery> No need to ask if a question is on-topic. Just ask! (I'll let you know if we've wondered too far off-topic)
09:02 < nehan> hi     
09:02 < jnewbery> And finally, I'm always looking for hosts for future review club meetings. Please let me know after the meeting if you'd like to host. I can help you prepare notes and questions.
09:02 < felixweis> hi     
09:02 < jnewbery> ok, onto the meeting! Notes and questions are in the usual place: https://bitcoincore.reviews/20721
09:03 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews     
09:03 < jnewbery> who had a chance to review the PR this week? (y/n)
09:03 < glozow> y     
09:03 < murtyjones> y     
09:03 < svav> y     
09:03 -!- AnthonyRonning76 [6b4dc57a@mobile-107-77-197-122.mobile.att.net] has joined #bitcoin-core-pr-reviews     
09:03 -!- AnthonyRonning76 [6b4dc57a@mobile-107-77-197-122.mobile.att.net] has quit [Client Quit]     
09:03 < troygiorshev> n     
09:03 < nehan> n     
09:03 < willcl_ark> n     
09:03 < sunon> n     
09:03 < sishir> n     
09:03 < dhruvm> y     
09:03 < norisgOG> n     
09:03 < felixweis> y     
09:03 -!- effexzi [uid474242@gateway/web/irccloud.com/x-dqlofxxxgkznmkxl] has joined #bitcoin-core-pr-reviews     
09:03 < emzy> hi     
09:03 < emzy> n     
09:03 < amiti> hi     
09:03 < maqusat> y     
09:03 < effexzi> Hey     
09:03 -!- AnthonyRonning90 [6b4dc57a@mobile-107-77-197-122.mobile.att.net] has joined #bitcoin-core-pr-reviews     
09:04 < shafiunmiraz0> n     
09:04 < jnewbery> good stuff. For those of you who didn't have time this week, hopefully you'll be able to follow along the notes & questions at least.
09:04 < AnthonyRonning90> y     
09:04 < jnewbery> And I'd recommend going back and looking at the PR after. It'll really help cement your learning
09:04 < jnewbery> ok, any initial thoughts about the PR? What's it trying to do? Concept ACK/NACK?
09:04 -!- n3wB3333 [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
09:05 < schmidty> ACK for separations of concern
09:05 < willcl_ark> at a high level, definitely in favour of furthering modularisation
09:05 < svav> ACK for the principle
09:05 < murtyjones> makes sense to me and the stack analogy was helpful. although the fact that ping data is used in net and net processing both took me a little bit to reason about
09:05 < AnthonyRonning90> ACK, not immediately intuitive that ping should be in net processing but after seeing what additional stuff it did, it made sense.
09:06 < maqusat> Concept ACK
09:06 < troygiorshev> Concept ACK, and looking closer as to why ping should be in net_processing
09:06 < dhruvm> The PR is trying to further separate connection and application layer logic. Bitcoin Core uses ping/pong p2p messages to maintain data about connection health. p2p logic belongs in the application layer, so this PR moves the associated variables and logic there.
09:06 < michaelfolkson> Yeah Concept ACK. I'm always interested in what makes it into net, net processing, validation etc because it makes sense logically or because it is convenient from codebase perspective
09:06 -!- AnthonyRonning [ae2ddd4c@174-045-221-076.res.spectrum.com] has quit [Ping timeout: 240 seconds]     
09:07 < jnewbery> great! It sounds like you've all got the high-level concept. I agree that it's a bit strange to think about whether ping belongs in net or net processing. We'll dive into the details in a bit.
09:07 < b10c> hi     
09:07 < jnewbery> onto the technical questions:
09:07 < jnewbery> 1. What’s the difference between system time and mockable time? When is it appropriate to use one or the other?
09:07 < murtyjones> System time takes the actual time from the machine, whereas mockable time can be set manually. The latter is useful in a context where you want to change the time for testing purposes.
09:07 < AnthonyRonning90> System time is the real time, mockable time is a fake time used for tests.
09:08 < dhruvm> System time asks the OS for the time. Mockable time uses a mock time value if available, if not, uses system time. Mockable time can make tests more deterministic. However, mockable time does not tick forward so if the functionality being tested needs that, we have to `setmocktime` repeatedly.
09:08 -!- fodediop [~fode@41.83.7.234] has joined #bitcoin-core-pr-reviews     
09:08 < jnewbery> murtyjones AnthonyRonning90 dhruvm: yes, very good
09:08 < glozow> mockable time isn't just used for tests, it's just a time that can be manipulated in tests
09:08 < fodediop> hi     
09:09 < michaelfolkson> Where else is mockable time used glozow other than tests?
09:09 < dhruvm> glozow: what are the use cases other than tests?
09:09 < schmidty> glozow: where else is an example of its non test use?
09:09 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Remote host closed the connection]     
09:09 < michaelfolkson> Ha     
09:09 < michaelfolkson> Educate us glozow :)
09:09 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
09:10 < jnewbery> glozow: I think that mocktime can only be set for regtest
09:10 < pinheadmz> glozow isnt rpc setmocktime not even available outside of regtest?
09:11 < jnewbery> setmocktime can only be called for regtest: https://github.com/bitcoin/bitcoin/blob/ea96e17e1f2c2b0a949366260906ef02e560a425/src/rpc/misc.cpp#L377-L379 . There's also a -mocktime command line arg. I'm not sure whether that can be used outside regtest mode
09:11 < glozow> I was thinking mockable versus non-mockable 🤔 like, for nodes running in non-regtest-mode, the pingtimes are still measured in mock-able time but they're not fake?
09:11 < sishir> Does tx download use case fall under tests as well? https://github.com/bitcoin/bitcoin/pull/16197
09:11 < glozow> like can-be-mocked-but-isn't-right-now
09:12 < jnewbery> glozow: ah ok. Yes - we use 'mockable time' for ping timeouts, but mockable time can only be mocked for regtest
09:12 < jnewbery> ok, so what timers should use mocktime and what timers shouldn't?
09:12 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
09:13 < pinheadmz> anything around MTP should NOT, so csv or block tiemstamps, etc i think
09:13 < pinheadmz> er i guess some of the block timestamp check
09:13 < murtyjones> What's MTP?
09:13 < felixweis> median time past
09:13 < pinheadmz> median time past
09:13 < pinheadmz> yeah a mean of last 11 blocks timestamps
09:13 < pinheadmz> this is the value used to test check locktime and check sequence (relative lock time)
09:13 < jnewbery> s/mean/median :)
09:13 < felixweis> median timestamp not mean timestamp
09:14 < murtyjones> ah okay, thanks
09:14 < pinheadmz> er thanks, i priomise i will never get those straight
09:14 < felixweis> :)     
09:14 < jnewbery> pinheadmz: so those things are timestamps in the block data. I'm thinking more of timers in the code
09:14 < lightlike> at some places, a third time ("AdjustedTime") is used, a combination of our system time and what our peers think is the right time
09:15 < jnewbery> lightlike: right, that's a bit of a strange one, but it does have one of the best satoshi comments in the code
09:15 < jnewbery>  * "Never go to sea with two chronometers; take one or three."
09:16 < jnewbery> anyway, I digress
09:16 < pinheadmz> he     
09:16 < michaelfolkson> Lol that's great
09:16 < pinheadmz> i was actually surpirsed to see that ping timers could be mocked
09:16 < dhruvm> mocktime does not tick forward, are there use cases dependent on that?
09:16 < pinheadmz> but i suppose anything you want to test, it makes sense (test ping timeout)
09:16 < murtyjones> I would think just about anything that needs to be unit/functional tested would want use mockable time?
09:16 < jnewbery> so, I think we generally want to avoid using mockable time in the low level network stack. If those timers could be mocked, then everything would break
09:17 < pinheadmz> are there timers in the code we'd never want to test?
09:17 < jnewbery> *break when you call setmocktime
09:17 < pinheadmz> how low?
09:17 < pinheadmz> like, before seeing this PR i thought ping timeouts would be included in that
09:17 < jnewbery> generally stuff in net, I'd hazard
09:17 < jnewbery> pinheadmz: that's a reasonable assumption, since the ping timeouts were in net
09:18 < pinheadmz> i was thinking nack at first, since keeping connections alive seems like a low level (net) function but since `ping` is defined as a bitcoin p2p protocol message I changed my mind, it does belong up in the applciation level
09:18 < jnewbery> but if we want to test the behaviour of a specific timer, then we need to be able to mock it
09:18 < jnewbery> that leads us nicely on to the second question:
09:18 < jnewbery> 2. In CConnman::InactivityCheck(), why do we have a ping timeout? Why not just rely on the send buffer timeout and receive buffer timeout?
09:19 -!- prayank [~andr0irc@2402:8100:206c:22b2:dd42:3f8f:ab4e:e59d] has quit [Ping timeout: 260 seconds]     
09:19 < dhruvm> To occasionaly check connection health even if no data is being sent/received on it.
09:19 < pinheadmz> jnewbery i think specifically so it can be adjsuted / customized ?
09:19 < AnthonyRonning90> My guess: because pings have a different timeout threshold. Send/receive could take awhile depending on the size of the data while pings should be somewhat fast.
09:19 < amiti> so the idea is if the low level network stuff could be mocked, when we set mocktime to try to test higher level stuff, the low level stuff wouldn't work as expected? ... so we shouldn't use mocktime too far down?
09:20 < jnewbery> amiti: I think that's right
09:20 < pinheadmz> jnewbery and to be clear, this PR removes ping timeout from inactivtyCheck() right?
09:20 < jnewbery> generally the mockable stuff is up in the application layer. sipa wrote a nice review comment on it somewhere, but I can't quite put my finger on where it was
09:21 < felixweis> when are members being renamed to m_snake_case?
09:21 < jnewbery> ah yes, here it is: https://github.com/bitcoin/bitcoin/pull/20027#discussion_r501350411.
09:21 < glozow> how often do we just not really send our peers anything for 20 minutes?
09:21 < jnewbery> pinheadmz: absolutely correct. This PR moves that logic up into the application layer (PeerManager in net processing)
09:22 < jnewbery> glozow: never! We expect pings to be responded to pretty quickly, and they get sent out within a minute of receiving the last one I think
09:22 -!- prayank [~andr0irc@2402:8100:206c:22b2:b463:af3e:73bb:6a2b] has joined #bitcoin-core-pr-reviews     
09:23 < jnewbery> two minutes, sorry
09:23 < glozow> o okie, but if we didn't ping to check health, would there be occasions where we just don't really talk much?
09:23 < michaelfolkson> If a peer has disconnected for some reason do we stop pinging them immediately?
09:24 < glozow> wdym, i don't think we can ping them if we're disconnected?
09:24 < jnewbery> felixweis: if I move a data member, I'll add a scripted diff at the end to make the naming comply with current code style. All of the lines that the variable touches are being updated anyway, so it's no additional churn
09:24 < felixweis> thanks makes sense
09:24 < dhruvm> if a connection does not have much chatter/is dead, isn't that when we need the ping/pong most?
09:25 < michaelfolkson> glozow: If they are online we could attempt to open a connection up again but we can't ping them until that connection is established right?
09:25 < lightlike> glozow: if the connection is blocks-only and there are no incoming blocks for a while, what else would there be to send?
09:25 < michaelfolkson> glozow: We have to start the handshake again
09:25 < dhruvm> lightlike: that's a good one
09:25 < glozow> sorree, I was trying to answer the question "why do ping timeouts at all" and my guess was that if we didn't do that, we could accidentally be conflating "nothing to talk about" with "inactivity"
09:26 < glozow> lightlike: that makes sense
09:26 < jnewbery> so the ping timeout does seem at first glance to be slightly redundant. If the receive buffer timeout is hit (20 minutes of inactivity) then, by definition, we can't have received a pong in 20 minutes.
09:27 < jnewbery> however, I think they're both useful, and having timeouts on both the net/data layer and the application layer is a good separation of responsibilities
09:27 < jnewbery> ping timeouts are net processing's way to ensure that it has an active logical connection with a peer. It must do, since the peer is sending pongs
09:28 -!- Caralie [04355c72@4.53.92.114] has joined #bitcoin-core-pr-reviews     
09:28 < jnewbery> socket timeouts are net's way to ensure that it has an active connection on the transport layer. It must do, since the connection is receiving bytes
09:29 < jnewbery> I hope that makes sense!
09:29 < glozow> so, we distinguish between a networking-level "healthy/active connection" and an application-level "we want our peers to be following protocol and responding to pings?"
09:29 < pinheadmz> also ping/pong nonces are needed to avoid connection to self :-)
09:29 < troygiorshev> glozow: ah that's a great way to put it
09:29 < pinheadmz> dunno if the low level socket stuff could figure that out
09:30 < jnewbery> glozow: I distinguish between those things! This PR is an attempt to clarify that distinction :)
09:30 < jnewbery> pinheadmz: you're thinking of the nonce in the version message
09:30 < glozow> cool cool, just wanna make sure i follow
09:30 < pinheadmz> oh right thank oyu
09:30 < jnewbery> the nonce in the ping/pong is to correlate the pong response to the ping request
09:30 < jnewbery> onwards!
09:30 < jnewbery> 3. Why do certain tests need to be updated in the second commit Use -pingtimeout in tests that might have pings time out? Why could pings start timing out when the ping timeout logic is moved into net processing?
09:31 < sishir> because tests run for less than the peer connect timeout
09:31 < murtyjones> I'm guessing that those tests didn't previously execute ping-checking logic before the first commit ended up doing that as a side effect, so timeouts could occur if not mocked.
09:31 < AnthonyRonning90> Instead of only checking ping timeout when `InactivityCheck` runs & the peer has been connected longer than the threshold, pings timeouts are now checked during the `SendMessage` flow. Tests before would not have hit the 20 minute default, but now hit the ping check every `SendMessage`.
09:31 < nehan> jnewbery: i'm having trouble convincing myself that the net layer "needs" timeouts if the application layer can handle it. is there an example of why this might be so?
09:33 < pinheadmz> I think AnthonyRonning90 is close - the inactivity check loop runs less often
09:33 < jnewbery> sishir AnthonyRonning90: yes! (but it's 60 seconds, not 20 minutes for the initial peer connection timeout)
09:33 < jnewbery> I gave the answer away here yesterday: https://github.com/bitcoin/bitcoin/pull/20721#discussion_r568651714
09:33 < glozow> nehan: I'm imagining a case where the socket connection is still active, but there's a problem with the application-layer? we'd want to disconnect for inactivity in that case
09:33 < dhruvm> nehan: The redundancy is useful although not needed iiuc. For example, if we wanted to remove pings in a future protocol version, we could because the transport layer is still checking for connection health?
09:34 < AnthonyRonning90> jnewbery: oh gotcha, i saw `static const int TIMEOUT_INTERVAL = 20 * 60;` and thought it meant a default of 20 min
09:34 < jnewbery> if a test runs for less than 60 seconds, none of the inactivity logic is exercised at all (before this PR). After this PR, the ping timeout logic is exercised as soon as the connection is fully up (on receipt of the verack)
09:34 < sishir> Does this imply to all the tests or just P2Ps?
09:35 < nehan> glozow: we'd want to disconnect because the application layer is having a problem. not sure why the net layer would need a timeout in that case.
09:35 < glozow> nehan: true, if the net layer had a problem then application layer would be irrelevant
09:35 < jnewbery> nehan: your instinct is right. If the application layer is exchanging pings with a peer, then the lower layer connection *must* be healthy. However, I think this is just good defense in depth and separation of responsibilities: connman is responsible for maintaining good connections, and peerman is responsible for maintaining good peers
09:37 -!- Larsson [~l@2804:7f7:a6a9:95dc:d0cb:1c77:46a7:6e03] has joined #bitcoin-core-pr-reviews     
09:37 < jnewbery> I also don't think it's worth spending energy convincing ourselves and each other that we should remove socket inactivity checks.
09:37 < nehan> part of the reason i bring this up is because of the challenge of which times to mock. that seems pretty hard and not at all "settled"! it would be very tricky to make sure you're mocking/updating all the clocks appropriately
09:37 < jnewbery> (not to be dismissive - it's a good question to ask, but not a priority to change)
09:38 < glozow> for the "why could pings start timing out when the ping timeout logic is moved" question, I thought it boiled down to the fact that it's no longer preceded by the `m_peer_connect_timeout` check? so then even the `-peertimeout` config option wouldn't suffice
09:38 < nehan> jnewbery: definitely not arguing for removing them. more trying to understand if they are required or not.
09:38 < jnewbery> those socket inactivity checks use non-mockable time, so they should be just fine in all tests
09:38 < jnewbery> sishir: unit tests and functional tests
09:38 < sishir> Got it!
09:39 < jnewbery> glozow: eeeeexactly!
09:39 < jnewbery> I'm going to ask the next question, but if there's something unclear in what we've covered before, always feel free to go back and ask more questions about it
09:40 < jnewbery> 4. The first commit, Add -pingtimeout to configure ping timeout, adds a new configuration option. Is this desirable? When should we add new configuration options, and when should we avoid adding new options?
09:40 < AnthonyRonning90> My initial impression is this was more so added for tests to better support tests (I’ve done that myself before)
09:40 < AnthonyRonning90> better support time*
09:40 < lightlike> nehan, jnewbery: would it maybe make sense to make all times mockable, but have different mocktime groups (one for net processing, another one for net) that could be adjusted separately?
09:41 < dhruvm> We are going it here for tests. Could be a cli arg, or a regtest rpc - but cli arg is better because users in high latency regions could maybe use it?
09:41 < michaelfolkson> On the configuration option question I would guess it should have an important use case. We don't want to keep piling up configuration options that aren't needed
09:42 < pinheadmz> jnewbery perhaps if we are on a low bandwidth connection it makes sense to allow longer pings ?
09:42 < glozow> Adding it made sense to me since it was debug-only and existing `-peertimeout` doesn't work. idk what the good practice would be, interested in hearing about that. However, since the only option ever used is pretty magic-number-y, `-pingtimeout=9999` how come it isn't just a flag option to extend/ignore the ping timeout?
09:42 < michaelfolkson> Some configure options need to be set before starting the daemon and some can be set after
09:43 < jnewbery> lightlike: If it makes testing specific functionality easier and there's no other way to do that, then maybe. That needs to be weighed up against the confusion of having multiple timestamps. It's already a bit of a mess
09:43 < nehan> lightlike: i worry it might be tricky to figure out how to set them all appropriately. like maybe you want to fast forward a few days in blocktime, but don't want to trigger inactivity checks. and maybe something else besides inactivity checks will come to rely on net time being accurate
09:44 < jnewbery> glozow: yeah, I think a binary flag is a reasonable alternative. I just copied what was already there for peertimeout
09:45 -!- mango [~mango@c-73-71-224-94.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
09:45 < jnewbery> AnthonyRonning90: exactly. Here, we've used it to allow testing. The new -pingtimeout option is a debug option, so it won't show up when running bitcoind --help.
09:46 < murtyjones> Could you get your node into a bad state by configuring the timeout to be a really low number where you end up disconnecting peers frequently?
09:46 < jnewbery> In general, we should try to avoid adding more and more (publicly visible) command line options. It leads to a combinatorial explosion of different configurations to test
09:46 < glozow> what would be considered good/bad idea for debug option? are we cool with just adding whatever options are helpful for testing?
09:46 < AnthonyRonning90> Could `MaybeSendPing` instead also apply a similar “min peer connection time” before checking ping? Like one that the activity check made?
09:46 < jnewbery> murtyjones: sure
09:46 < pinheadmz> murtyjones i tried running with pingtimeout=1
09:47 < pinheadmz> surprinalgy not that many disconnects
09:47 < murtyjones> i guess if you have a good connection maybe that's not likely. but since this isn't publicly visible you'd have to know what you were doing to even find it anyways
09:48 < jnewbery> AnthonyRonning90: It could. But logically I don't think that makes sense. We want pings to be sent/tested as soon as we're fully connected. I don't like adding special case logic to the production code to work around difficulties in our testing
09:48 < AnthonyRonning90> jnewbery: yeah makes sense. Thought of it more like a way to mimic existing behavior, not as a testing workaround.
09:48 < dhruvm> murtyjones: https://github.com/bitcoin/bitcoin/pull/20721/files#diff-6875de769e90cec84d2e8a9c1b962cdbcda44d870d42e4215827e599e11e90e3R4324
09:49 < jnewbery> pinheadmz: your earlier comment about setting a high pingtimeout for low bandwidth connections is interesting, but I think if you're not receiving ping responses is 20 minutes, you're probably not going to have a good time :)
09:49 < pinheadmz> 20 minutes is the default?
09:50 < lightlike> I just built the PR, and for me wallet_resendwallettransactions.py fails intermittently (~40% of the time)
09:50 < pinheadmz> oh maybe then the idea is to crank it lower and only connect to other high bandwaidth nodes
09:51 < jnewbery> lightlike: oh no! Do you definitely have the latest version (commit 4180381f)
09:51 -!- sishir [47ca5b95@c-71-202-91-149.hsd1.ca.comcast.net] has quit [Quit: Connection closed]     
09:51 -!- maqusat [522fec0b@cpc73666-dals20-2-0-cust10.20-2.cable.virginm.net] has quit [Quit: Ping timeout (120 seconds)]     
09:51 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Ping timeout (120 seconds)]     
09:51 < lightlike> jnewbery: yes, just downloaded at the beginning of the session.
09:51 -!- maqusat [522fec0b@cpc73666-dals20-2-0-cust10.20-2.cable.virginm.net] has joined #bitcoin-core-pr-reviews     
09:51 < glozow> hm. resendwallettransactions sets mock time 12 hours ahead, that's 43200 seconds > 9999?
09:51 -!- Caralie [04355c72@4.53.92.114] has quit [Quit: Ping timeout (120 seconds)]     
09:51 -!- murtyjones [60ef6e85@pool-96-239-110-133.nycmny.fios.verizon.net] has quit [Quit: Ping timeout (120 seconds)]     
09:51 -!- n3wB3333 [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has quit [Quit: Ping timeout (120 seconds)]     
09:51 < jnewbery> lightlike: thanks, I'll investigate
09:52 -!- murtyjones [60ef6e85@pool-96-239-110-133.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
09:52 < jnewbery> glozow: oh! Maybe you've found my bug. Thanks!
09:52 < glozow> :salute:
09:52 < AnthonyRonning90> i didn't look very hard, but are there separate tests for testing if ping timeout works? I only saw the test updates making ping timeout ignored (w/ 9999 timeout)
09:52 -!- AnthonyRonning90 [6b4dc57a@mobile-107-77-197-122.mobile.att.net] has quit [Quit: Ping timeout (120 seconds)]     
09:52 < glozow> p2p_pingtimeouts.py
09:52 -!- AnthonyRonning [6b4dc57a@mobile-107-77-197-122.mobile.att.net] has joined #bitcoin-core-pr-reviews     
09:53 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews     
09:54 < jnewbery> pinheadmz: before this PR, there were two default timeouts: DEFAULT_PEER_CONNECT_TIMEOUT (60 seconds) - we don't do any inactivity timeout checks until the peer has been connected for this long. TIMEOUT_INTERVAL (20 minutes) - we'll disconnect a peer if there's no activity on their send/recv buffers or they haven't sent a pong for this long
09:54 < AnthonyRonning> *curses my ping timeouts today* :(
09:54 < jnewbery> ok, final question
09:54 < jnewbery> 5. If the goal of the PR is to move ping data into net processing, why is there still a PingReceived function in CNode (in net) after this PR?
09:54 < murtyjones> Ping data is used for eviction logic, which is a "Net" responsibility, so the data has to be kept up to date. It can also be used for debugging purposes.
09:54 < AnthonyRonning> the `CNode::m_min_ping_time` is used during `CConnman` eviction logic, so the ping processing data still needs to make it through to `Cnode` (as accomplished via `CNode::PingReceived`).
09:55 < jnewbery> murtyjones AnthonyRonning: YES!
09:55 < jnewbery> very good
09:55 < nehan> will the eviction logic move to net_processing?
09:55 < jnewbery> the net layer is currently responsible for inbound peer eviction, so net processing needs to inform it of interesting events that it can use in that decision-making
09:56 < jnewbery> nehan: that's a very good question. My vague, nebulous thought at this point is that it should be extracted into a separate module.
09:56 < jnewbery> it's not fully net and not fully net processing, since it requires data from both
09:56 -!- n3wB3333 [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has joined #bitcoin-core-pr-reviews     
09:57 -!- cguida [~cguida@2806:2f0:51c1:a46a:687a:7:5bed:8b3b] has joined #bitcoin-core-pr-reviews     
09:57 < jnewbery> it's trying to make an assessment of the quality of the peer based on connection-level and application-level metrics
09:57 < jnewbery> ok, three minutes left. Any final questions?
09:57 < jonatack> nehan asks the *best* questions. it's a super power. (hi)
09:58 < glozow> ya, what's a good way to decide whether or not something warrants a new debug config option?
09:58 < jnewbery> jonatack: nehan does indeed ask excellent questions :)
09:58 < troygiorshev> nehan: who exactly owns the connection does see to be a little in flux, I'm excited to see where it lands
09:59 < nehan> aw thanks, but i think jnewbery and others have been pondering this for quite some time
09:59 < jnewbery> glozow: I think probably "avoid it if you can" is the best guidance I could give. I wouldn't be surprised if I got some pushback somewhere for adding -pingtimeout
09:59 < murtyjones> dropping off. thanks for hosting jnewbery!
10:00 < shafiunmiraz0> Thank you jnewbery Thank you everyone
10:00 -!- murtyjones [60ef6e85@pool-96-239-110-133.nycmny.fios.verizon.net] has quit [Quit: Connection closed]     
10:00 < jnewbery> #endmeeting
10:00 < michaelfolkson> pinging thanks to jnewbery
10:00 < nehan> thanks!
10:00 < norisgOG> thanks
10:00 < troygiorshev> thanks jnewbery!
10:00 < AnthonyRonning> thank you jnewbery & all!
10:00 < lightlike> thanks jnewbery!
10:00 < dhruvm> thank you, jnewbery !
10:00 -!- troygiorshev [~troygiors@172-97-171-42.cpe.distributel.net] has quit [Quit: leaving]     
10:00 < maqusat> cheers!
10:00 < emzy> thanks jnewbery!
10:00 < svav> Thanks jnewbury
10:00 < glozow> jnewbery: i wonder if you could just consolidate to a "ignore timeouts" because in regtests you're pretty much manually deciding the p2p activity, unless you're testing timeouts?
10:00 < glozow> THANKS JNEWBERY
10:00 < pinheadmz> thanks! learn so much here every week
10:01 < jnewbery> thanks for stopPING by, everybody
10:01 < schmidty> thanks jnewbery
10:01 < prayank> Thanks everyone
10:01 < jonatack> thanks gmewbery
10:01 < pinheadmz> jnewbery PONG
10:01 < glozow> pr review club was poPING as usual
10:01 < pinheadmz> how long was that?
10:01 < glozow> popping* oops i messed that up
10:01 < jnewbery> glozow: close enough
10:02 -!- AnthonyRonning [6b4dc57a@mobile-107-77-197-122.mobile.att.net] has quit [Quit: Connection closed]     
10:02 < jnewbery> reminder that I'm always looking for hosts. Please DM me if you'd like to give it a go
10:02 < jnewbery> next week it's lightlike. He's going to be teaching us about ...
10:02 < jnewbery> ERLAY
10:02 < michaelfolkson> Cool
10:03 < michaelfolkson> cguida has some questions from bitcoin-core-dev channel.
10:03 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has quit [Quit: Leaving]     
10:03 < michaelfolkson> I discovered some misleading discussion in https://bitcoincore.reviews/17994. The intro to the review appears to claim that undo files are always in  block height order on disk, but I've recently been digging into the undo files and they're actually out of order at the file boundaries. In the  discussion, it's implied that if a block is too big to fit into 128MB,  it goes into the next blk file, so its corresponding
10:03 < michaelfolkson>  undo file m
10:04 < michaelfolkson> ust go into the next rev file. Then, if a  block is found that is small enough to fit in the original blk file, it's put there along with its undo data. But at no point in the discussion does anyone explicitly say "hey actually no, that's wrong, sometimes the undo files are out of order."
10:04 -!- svav [5245568f@82-69-86-143.dsl.in-addr.zen.co.uk] has left #bitcoin-core-pr-reviews []     
10:04 < michaelfolkson> I'm not sure if these  bitcoincore.reviews are meant to be authoritative, and I'm not sure if the site can be edited, but it definitely would have saved me a lot of time knowing that the undo blocks are sometimes not in block height order. So, just a heads up, and thanks for listening :)
10:04 < michaelfolkson> Messed that copy up and paste up :)
10:05 < cguida> Thanks michaelfolkson! Haha no worries, still readable to me :)
10:05 < jonatack> lightlike: erlay great, just the excuse i've been needing to get my review on of it
10:05 < jnewbery> hi cguida. Thanks for pointing this out. If there are errors in the notes/questions, we should definitely correct them.
10:06 < michaelfolkson> I would say in response these aren't authoritative resources. Obviously some people like jnewbery are more authoritative. But generally people will make mistakes (I certainly do everytime)
10:06 < jonatack> Meeting log is up https://bitcoincore.reviews/20721 🍰
10:06 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews     
10:06 < pinheadmz> jonatack fastest log uploader in the west
10:06 < jnewbery> The log is just the log of the irc chat, so we don't generally go back and edit (although have on occasion added a footnote if there's an egregious error)
10:06 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 272 seconds]     
10:06 -!- fodediop [~fode@41.83.7.234] has quit [Quit: WeeChat 3.0]     
10:07 < jnewbery> cguida: where exactly do you see the error?
10:08 < cguida> >In addition to the blk*.dat files, we also generate and store “undo” information for each block in corresponding rev*.dat files. This can be used to revert all the transactions from the block if we need to disconnect the block from the chain during a reorg. Unlike blocks, this information is always stored in block height order.
10:08 < cguida> Especially that last sentence
10:09 < luke-jr> sounds like it means within the file
10:09 < cguida> I guess I took that to mean that, on disk, they are stored in block height order. But I guess it could mean chronologically
10:10 < cguida> They are not in order on disk, but it sounds like chronologically they are indeed stored in block height order
10:10 < luke-jr> cguida: keyword *corresponding* rev*.dat files
10:10 < jnewbery> cguida: within an undo file, the data will be stored in block height order (a block's undo data cannot appear after the undo data for some descendant of that block)
10:11 < jnewbery> you're right that if you concatenate all the undo files, that statement is no longer true. A descendant block could appear in an earlier file.
10:13 -!- maqusat [522fec0b@cpc73666-dals20-2-0-cust10.20-2.cable.virginm.net] has quit [Quit: Connection closed]     
10:13 < jnewbery> That sentence in the notes is misleading. I'll try to clarify it.
10:15 < cguida> jnewbery: I must be misunderstanding your statement here: within an undo file, the data will be stored in block height order (a block's undo data cannot appear after the undo data for some descendant of that block)
10:15 < cguida> here's the border between file 0 and file 1:
10:15 < cguida> >>> pprint.pprint([(i.height, i.file, i.data_pos, i.undo_pos) for i in block_indexes[119950:120000]]) [(119950, 0, 134136224, 19489902),  (119951, 0, 134193436, 19491015),  (119952, 0, 134052842, 19491148),  (119953, 0, 134093972, 19491411),  (119954, 0, 134126093, 19492331),  (119955, 0, 134104218, 19492811),  (119956, 0, 134194255, 19495136),  (119957, 0, 134182203, 19495587),  (119958, 0, 134178063, 19496021),  (11995
10:15 < cguida> 9, 0, 134071196, 19496557),  (119960, 0, 134148382, 19496884),  (119961, 0, 134197669, 19500965),  (119962, 0, 134185851, 19501558),  (119963, 0, 134202214, 19501988),  (119964, 1, 43665, 8),  (119965, 1, 8, 1853),  (119966, 1, 35278, 3556),  (119967, 1, 83625, 3819),  (119968, 0, 134129761, 19502388),  (119969, 1, 110608, 4273),  (119970, 1, 65813, 4666),  (119971, 1, 96558, 5181),  (119972, 1, 117652, 6262),  (119973,
10:15 < cguida> 0, 134146577, 19502840),  (119974, 1, 129368, 6659),  (119975, 1, 76342, 6993),  (119976, 1, 57912, 7034),  (119977, 0, 134189030, 19503069),  (119978, 1, 124854, 8004),  (119979, 1, 87850, 8101),  (119980, 1, 140938, 9223),  (119981, 1, 189297, 9347),  (119982, 1, 144860, 9470),  (119983, 0, 134205429, 19503492),  (119984, 1, 23503, 10057),  (119985, 1, 73266, 11605),  (119986, 1, 113767, 12001),  (119987, 1, 125598, 12
10:15 < cguida> 506),  (119988, 1, 141777, 12979),  (119989, 1, 190259, 13380),  (119990, 1, 218609, 13818),  (119991, 1, 224514, 14185),  (119992, 1, 216007, 14968),  (119993, 1, 193396, 15287),  (119994, 1, 221752, 15385),  (119995, 1, 233639, 15730),  (119996, 1, 2802391, 16152),  (119997, 1, 37497, 17016),  (119998, 1, 330167, 17394),  (119999, 1, 106700, 18853)]
10:15 < cguida> oh dear, that doesn't format well, i apologize
10:16 < jonatack> cguida: it's great that you're using those notes as a resource, that's what we're hoping to do with them
10:16 < cguida> i'm a bit new to irc, lmk if there's a better way to format that
10:17 < jnewbery> cguida: paste to https://0bin.net/
10:17 < jnewbery> jonatack: +1 ❤️
10:17 -!- jonasschnelli [~jonasschn@2a01:4f9:2a:2510::2] has quit [Changing host]     
10:17 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-pr-reviews     
10:18 < cguida> jnewbery: ok yeah, this clears things up: you're right that if you concatenate all the undo files, that statement is no longer true. A descendant block could appear in an earlier file.
10:19 < cguida> so my misunderstanding comes from not realizing the note at the top was only referring to "within a rev file", not across all rev files, even though it says "always"
10:20 < jnewbery> cguida: exactly. That's the part that's misleading :)
10:21 < jonatack> cguida: jnewbery: who wants to make a PR? standing by to review :)
10:22 < cguida> jnewbery: https://0bin.net/paste/gzZRtqcV#g4dDo57UYtP8uc5iMWY+PskZMjQRArCz6gchhukiJW-
10:23 < jnewbery> cguida: https://github.com/bitcoin-core-review-club/website/pull/304
10:23 < jnewbery> let me know if that makes it clearer
10:23 < jnewbery> thanks again for pointing this out!
10:24 -!- cguida1 [~Adium@2806:2f0:51c1:a46a:2de7:29e0:859e:a50f] has joined #bitcoin-core-pr-reviews     
10:25 < cguida> jnewbery: looks perfect, thanks so much for editing that! :)
10:26 < jnewbery> no problem. I took a look at your data and it's consistent with what I'd expect to see
10:26 < cguida> sorry for the delays, my internet has suddenly decided to go on the fritz
10:28 < cguida> jonatack: sweet, they've definitely been useful so far! glad to do my small part to improve the experience for others :)
10:29 < jonatack> thanks cguida!
10:33 < cguida> jnewbery: One thing that could be confusing now, I guess, is that the quote you edited out was brought up in the conversation. Not sure if that's a big deal.
10:34 < cguida> felixweis was actually pressing on the issue but it was never resolved because the review needed to continue haha
10:34 -!- lightlike [~lightlike@p200300c7ef11d00045c791784d59404a.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
10:35 -!- cguida [~cguida@2806:2f0:51c1:a46a:687a:7:5bed:8b3b] has quit [Quit: Leaving.]     
10:41 < jonatack> cguida1: which lines(s)?
10:42 < jonatack> oh https://bitcoincore.reviews/17994#l-92
10:44 -!- kane90 [70c492d2@112.196.146.210] has joined #bitcoin-core-pr-reviews     
10:47 -!- kane90 [70c492d2@112.196.146.210] has quit [Client Quit]     
10:49 < jonatack> we could add a note that the notes were updated after the meeting to clarify that point
10:51 -!- n3wB3333 [4cdd98b9@76-221-152-185.lightspeed.clmboh.sbcglobal.net] has quit [Quit: Connection closed]     
10:51 -!- mango [~mango@c-73-71-224-94.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com]     
10:56 -!- cguida [~cguida@2806:2f0:51c1:a46a:3ae4:729b:70e6:32ec] has joined #bitcoin-core-pr-reviews     
11:02 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
11:03 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
11:22 < cguida> jnewbery: something like this? https://github.com/bitcoin-core-review-club/website/pull/305
11:30 -!- prayank [~andr0irc@2402:8100:206c:22b2:b463:af3e:73bb:6a2b] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]     
11:47 -!- worc3131 [~quassel@2a02:c7f:dcc4:6500:217b:6c7a:eac3:3be9] has joined #bitcoin-core-pr-reviews     
11:55 -!- prusnak [sid403625@gateway/web/irccloud.com/x-mzyynxklwhxatlbs] has joined #bitcoin-core-pr-reviews     
11:58 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 240 seconds]     
12:07 -!- worc3131 [~quassel@2a02:c7f:dcc4:6500:217b:6c7a:eac3:3be9] has quit [Ping timeout: 272 seconds]     
12:07 < jnewbery> thanks cguida!
12:12 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]     
12:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]     
12:23 -!- effexzi [uid474242@gateway/web/irccloud.com/x-dqlofxxxgkznmkxl] has quit [Quit: Connection closed for inactivity]     
12:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
12:25 -!- Larsson [~l@2804:7f7:a6a9:95dc:d0cb:1c77:46a7:6e03] has quit [Quit: Konversation terminated!]     
13:37 < jonatack> cguida: 🏆✨
13:56 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
13:56 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
14:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
14:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
14:26 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]     
14:26 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
14:26 -!- vasild_ is now known as vasild     
15:00 -!- davterra [uid458765@gateway/web/irccloud.com/x-rvllqygwiqauowdp] has quit [Quit: Connection closed for inactivity]     
15:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]     
15:41 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
16:10 < cguida1> Thanks so much for helping me out, jonatack & jnewbery! You guys are great!
16:25 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-pr-reviews     
16:34 -!- cguida1 [~Adium@2806:2f0:51c1:a46a:2de7:29e0:859e:a50f] has left #bitcoin-core-pr-reviews []     
16:39 -!- cguida [~cguida@2806:2f0:51c1:a46a:3ae4:729b:70e6:32ec] has quit [Read error: Connection reset by peer]     
16:45 -!- cguida1 [~cguida@2806:2f0:51c1:a46a:3ae4:729b:70e6:32ec] has joined #bitcoin-core-pr-reviews     
17:01 -!- cguida [~Adium@2806:2f0:51c1:a46a:1cae:1b01:12bb:b4a9] has joined #bitcoin-core-pr-reviews     
17:16 -!- cguida1 [~cguida@2806:2f0:51c1:a46a:3ae4:729b:70e6:32ec] has left #bitcoin-core-pr-reviews []     
17:33 -!- seven__ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews     
17:36 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Ping timeout: 240 seconds]     
17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
18:01 -!- davterra [uid458765@gateway/web/irccloud.com/x-emyvlrvgvpwonqxt] has joined #bitcoin-core-pr-reviews     
18:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]     
18:30 -!- seven__ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Ping timeout: 256 seconds]     
18:42 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
18:44 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
18:44 -!- da39a3ee5e6b4b0d [~da39a3ee5@49.228.239.163] has joined #bitcoin-core-pr-reviews     
18:46 -!- seven__ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews     
20:07 -!- da39a3ee5e6b4b0d [~da39a3ee5@49.228.239.163] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
20:18 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:77eb:108:ea2:a08f:6e8c] has joined #bitcoin-core-pr-reviews     
20:54 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:77eb:108:ea2:a08f:6e8c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
21:11 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:77eb:108:ea2:a08f:6e8c] has joined #bitcoin-core-pr-reviews     
21:25 -!- musdom [~Thunderbi@202.184.0.102] has joined #bitcoin-core-pr-reviews     
21:31 -!- caminus [~caminus@2601:645:4000:b3:47c:7254:4320:cce] has joined #bitcoin-core-pr-reviews     
21:49 -!- caminus [~caminus@2601:645:4000:b3:47c:7254:4320:cce] has quit [Quit: Textual IRC Client: www.textualapp.com]     
22:01 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
22:01 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
22:59 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews     
23:03 -!- seven__ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Ping timeout: 276 seconds]     
23:53 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:77eb:108:ea2:a08f:6e8c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
23:59 -!- jadijadi [~jadi@213.207.193.58] has joined #bitcoin-core-pr-reviews