--- Log opened Wed Aug 10 00:00:46 2022
00:07 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
00:11 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c4c9:566c:fea9:cb3b] has quit [Ping timeout: 268 seconds]
00:23 -!- laanwj [~laanwj@user/laanwj] has quit [Ping timeout: 260 seconds]
00:27 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has quit [Ping timeout: 268 seconds]
00:38 -!- pablomartin_ [~pablomart@185.183.106.228] has quit [Quit: Leaving]
00:39 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c4c9:566c:fea9:cb3b] has joined #bitcoin-core-pr-reviews
00:42 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
00:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c4c9:566c:fea9:cb3b] has quit [Ping timeout: 244 seconds]
00:49 -!- laanwj [~laanwj@user/laanwj] has joined #bitcoin-core-pr-reviews
01:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c4c9:566c:fea9:cb3b] has joined #bitcoin-core-pr-reviews
01:18 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c4c9:566c:fea9:cb3b] has quit [Ping timeout: 268 seconds]
01:33 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
01:44 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has quit [Ping timeout: 252 seconds]
02:06 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
02:11 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has quit [Ping timeout: 268 seconds]
02:34 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 255 seconds]
02:39 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
02:43 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has quit [Ping timeout: 268 seconds]
02:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c4c9:566c:fea9:cb3b] has joined #bitcoin-core-pr-reviews
03:12 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
03:17 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has quit [Ping timeout: 252 seconds]
03:46 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
03:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c4c9:566c:fea9:cb3b] has quit [Ping timeout: 268 seconds]
04:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c4c9:566c:fea9:cb3b] has joined #bitcoin-core-pr-reviews
04:06 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
04:46 < michaelfolkson> pinheadmz: Let me know if it works, I'll try it too. It can be a bit flaky especially on the new(ish) Taproot stuff
04:50 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has quit [Ping timeout: 268 seconds]
05:04 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
05:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c4c9:566c:fea9:cb3b] has quit [Ping timeout: 255 seconds]
05:09 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
05:53 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
05:53 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
05:54 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
05:54 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
06:06 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has quit [Ping timeout: 255 seconds]
06:12 -!- __gotcha [~Thunderbi@94.105.116.67.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
06:13 -!- __gotcha1 [~Thunderbi@94.105.116.67.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
06:14 -!- __gotcha [~Thunderbi@94.105.116.67.dyn.edpnet.net] has quit [Read error: Connection reset by peer]
06:14 -!- __gotcha1 is now known as __gotcha
06:39 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
06:43 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has quit [Ping timeout: 255 seconds]
06:52 -!- waxwing_ [~waxwing@193.29.57.116] has quit [Quit: ZNC 1.7.4+deb0+bionic0 - https://znc.in]
06:52 -!- waxwing [~waxwing@193.29.57.116] has joined #bitcoin-core-pr-reviews
07:06 -!- pablomartin_ [~pablomart@37.120.148.188] has joined #bitcoin-core-pr-reviews
07:06 -!- pablomartin_ is now known as pablomartin
07:16 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
07:21 -!- jgmontoya [~jgmontoya@186.107.8.163] has joined #bitcoin-core-pr-reviews
07:21 -!- jgmontoya [~jgmontoya@186.107.8.163] has quit [Client Quit]
08:03 -!- hernanmarino [~hernanmar@186.153.60.185] has joined #bitcoin-core-pr-reviews
08:10 -!- achow101 [~achow101@user/achow101] has quit [Quit: Bye]
08:11 -!- achow101 [~achow101@user/achow101] has joined #bitcoin-core-pr-reviews
08:19 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has quit [Ping timeout: 268 seconds]
08:20 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
08:24 -!- __gotcha [~Thunderbi@94.105.116.67.dyn.edpnet.net] has quit [Remote host closed the connection]
08:24 -!- __gotcha [~Thunderbi@94.105.116.67.dyn.edpnet.net] has joined #bitcoin-core-pr-reviews
08:29 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
08:33 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has quit [Ping timeout: 252 seconds]
08:58 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te58fre0it6iy9r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
09:09 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
09:21 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
09:21 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
09:24 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te58fre0it6iy9r.ipv6.telus.net] has quit [Remote host closed the connection]
09:24 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te58fre0it6iy9r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
09:29 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te58fre0it6iy9r.ipv6.telus.net] has quit [Ping timeout: 268 seconds]
09:32 -!- Amirreza [~Amirreza7@77.81.155.207] has joined #bitcoin-core-pr-reviews
09:32 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Remote host closed the connection]
09:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
09:33 -!- jonatack [~jonatack@user/jonatack] has quit [Quit: Connection closed]
09:34 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
09:38 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has quit [Ping timeout: 268 seconds]
09:42 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te58fre0it6iy9r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
09:44 -!- Kaizen_K_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
09:47 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te58fre0it6iy9r.ipv6.telus.net] has quit [Ping timeout: 255 seconds]
09:48 -!- Kaizen_K_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has quit [Remote host closed the connection]
09:48 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
09:49 -!- mixoflatsixo[m] [~mixoflats@2001:470:69fc:105::1:2b63] has joined #bitcoin-core-pr-reviews
09:52 -!- juancama [~juancama@pool-74-96-218-208.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
09:54 -!- Jennie [~Jennie@129.18.209.14] has joined #bitcoin-core-pr-reviews
09:58 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:58 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews
09:59 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:59 -!- adam2k [~adam2k@ip24-254-208-245.hr.hr.cox.net] has joined #bitcoin-core-pr-reviews
09:59 -!- Lov3r_Of_Bitcoin [~Lov3r_Of_@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
10:00 < dergoegge> #startmeeting
10:00 -!- vnprc [~vnprc@136.56.39.155] has joined #bitcoin-core-pr-reviews
10:00 < dergoegge> Hi everyone, welcome to this week's PR review club!
10:00 < effexzi> Hi every1 
10:00 < Lov3r_Of_Bitcoin> hello
10:00 < vnprc> hi
10:00 < dergoegge> Feel free to say hi to let people know you are here
10:00 < svav> Hi
10:00 < dergoegge> Anyone here for the first time?
10:00 < BlueMoon> Hello!!
10:01 < lightlike> Hi
10:01 < juancama> Hi everyone
10:01 < dergoegge> This week we are looking at #25720 “Reduce bandwidth during initial headers sync when a block is found”
10:01 -!- jgmontoya [~jgmontoya@186.107.8.163] has joined #bitcoin-core-pr-reviews
10:01 < larryruane_> hi
10:01 < dergoegge> Notes are in the usual place: https://bitcoincore.reviews/25720
10:01 < hernanmarino> Hi 
10:01 < pablomartin> hello
10:01 -!- Ifeanyichukwu [~Ifeanyich@197.210.227.182] has joined #bitcoin-core-pr-reviews
10:02 < dergoegge> OK let's get started with the usual first question: Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?
10:02 < juancama> yes
10:03 -!- ibaddesmukh [~ibaddesmu@103.244.177.22] has joined #bitcoin-core-pr-reviews
10:03 < hernanmarino> yes, tested ACK
10:04 < pablomartin> tested ACK
10:04 -!- ibaddesmukh [~ibaddesmu@103.244.177.22] has quit [Client Quit]
10:04 < adam2k> approach ACK
10:04 < dergoegge> hernanmarino: that's cool, i am curious how you tested it?
10:05 < dergoegge> did you run the functional tests or did you do anything more elaborate?
10:05 -!- ibaddesmukh [~ibaddesmu@103.244.177.22] has joined #bitcoin-core-pr-reviews
10:05 < hernanmarino> comilead and ran the tests. Also reviewed the code , I have some doubts but for later :)
10:06 < hernanmarino> compiled*
10:06 < pablomartin> same
10:06 < glozow> hi
10:06 < hernanmarino> I am actually thinking of adding a test later to answer my own doubt 
10:06 < dergoegge> Ok lets get to the doubts later then :)
10:07 < dergoegge> Next question: Why do nodes (mostly) receive inv block announcements while they are doing initial headers sync, even though they indicated preference for headers announcements (BIP 130)?
10:07 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
10:07 < Amirreza> Hi
10:08 < hernanmarino> I'm not sure but ... Is it a fallback for some errors conditions or large reorgs or your peer not having the headers you requested ?
10:08 < svav> What does inv stand for?
10:08 -!- dulce [~dulce@99-113-189-185.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
10:08 < Amirreza> @dergoegge, I think it is because inv can be received without request. So some node may notify me that new block is received.
10:08 < juancama> inventory
10:09 < juancama> It’s important to blocks-first nodes that the blocks be requested and sent in order because each block header references the header hash of the preceding block. That means the IBD node can’t fully validate a block until its parent block has been received.
10:09 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
10:09 < dergoegge> svav: inv stand for inventory, it is usually used as a short announcement (like a tx id or block hash) for a larger message
10:10 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Client Quit]
10:10 < larryruane_> and `inv` can contain many tx or block hashes, right? (not just 1)
10:10 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
10:10 < glozow> up to 50000, of multiple types
10:11 < larryruane_> https://en.bitcoin.it/wiki/Protocol_documentation#inv
10:11 < dergoegge> amirreza: headers can also be received without request (see the description for BIP 130 in the notes)
10:11 < svav> OK thanks all
10:12 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
10:12 < Amirreza> @dergoegge, I mean during I'm syncing my headers, a new block can be mined, and why not other nodes notify me to get that newly mined block?
10:13 < larryruane_> an `inv` message can be a mixture of blocks (actually that i have knowledge of different formats of blocks) and transactions https://en.bitcoin.it/wiki/Protocol_documentation#Inventory_Vectors
10:13 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d75-156-179-9.abhsia.telus.net] has quit [Remote host closed the connection]
10:13 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
10:14 < dergoegge> hernanmarino: you are close
10:14 < dergoegge> the reason is that a node will not announce a new block to a peer using a headers message if the peer has not previously sent a header to which the new header connects to
10:14 < dergoegge> See: https://github.com/bitcoin/bitcoin/blob/a6fc293c0a1f27ba1e573bfa16fd76d5f58988b2/src/net_processing.cpp#L4975-L4978
10:14 < hernanmarino> ohh, okey 
10:15 < juancama>  nodes (mostly) receive inv block announcements while they are doing initial headers sync bc block inventories show up in the inv message in the same order they appear in the chain, first inv message contains inventories for blocks 1 - 501. IBD node uses the received inventories to request 128 blocks from sync node in the “getdata” msg.
10:15 < dergoegge> the node only announces with a header if it is sure that the peer has already seen the parent block 
10:16 < hernanmarino> ok, but this is surely the case on reorgs that our node is no t aware of, right ? 
10:16 < hernanmarino> And also can happen without reorgs 
10:16 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 268 seconds]
10:16 < glozow> well this node is in IBD so it doesn't know the parent block of the new block
10:17 < vnprc> in this context what does "know" mean?
10:17 < ibaddesmukh> dergoegge if node doesn't find the header, it reverts to inventory?
10:17 < dergoegge> hernanmarino: yes, this can also happen for reorgs not just during initial sync
10:19 < dergoegge> ibaddesmukh: if a node doesn't have the header it self it won't announce it in any way
10:19 < ibaddesmukh> dergoegge thank you, got it!
10:19 < glozow> doesn't know = has not downloaded
10:20 -!- nassersaazi [~nassersaa@h1fcd.n1.ips.mtn.co.ug] has joined #bitcoin-core-pr-reviews
10:21 < dergoegge> i mostly asked this question to show that nodes doing initial headers sync will almost always receive block announcements through invs
10:21 < dergoegge> so only adding the logic for additional headers sync peers there makes sense
10:23 < dergoegge> Next question: Why is bandwidth wasted (during initial headers sync) by adding all peers that announce a block to us via an inv as headers sync peers?
10:23 < Amirreza> I have difficulty understanding the answer of this question, does it need to know the bip-130?
10:23 -!- jgmontoya [~jgmontoya@186.107.8.163] has quit [Quit: Connection closed]
10:24 < larryruane_> dergoegge: because you end up receiving duplicate headers (across multiple peers)
10:24 < Amirreza> @dergoegge, well not sure, but it may cause downloading same block headers from many peers.
10:24 < adam2k> In that situation are we getting repeated headers from some of the various message types?
10:24 < glozow> you'll probably get a lot of announcements -> a lot of headers syncing -> download the same headers repeatedly
10:25 < vnprc> I think you need some process to identify potential new headers sync peers in case your current one needs to be disconnected.
10:25 < pablomartin> yeah, dupes
10:25 < dergoegge> You are all correct! You only need to download the headers once
10:26 < glozow> we don't attempt to limit the number of peers we're requesting 1 header from, yes? unlike blocks
10:26 < larryruane_> This duplicate headers during IBD was attempted to be fixed back in 2016, but the fix had to be reverted: https://github.com/bitcoin/bitcoin/pull/8306
10:26 -!- Common [~Common@096-033-221-075.res.spectrum.com] has quit [Read error: Connection reset by peer]
10:26 < dergoegge> larryruane_: oh interesting, didn't know about that
10:27 < larryruane_> I'll mention it in a comment on the current PR 25720, doesn't seem to be mentioned there yet
10:27 -!- Ifeanyichukwu [~Ifeanyich@197.210.227.182] has quit [Ping timeout: 268 seconds]
10:27 < dergoegge> glozow: yeah once our header chain is close to today we request headers from all peers
10:29 < lightlike> larryruane: I think that problem (multiple getheaders with one peer) was already fixed by #25454 
10:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
10:30 -!- Ifeanyichukwu [~Ifeanyich@102.89.42.144] has joined #bitcoin-core-pr-reviews
10:30 < glozow> talking about https://github.com/bitcoin/bitcoin/issues/6755, yeah?
10:31 < larryruane_> lightlike: thanks, I didn't know about that, but the attempted fix that had to be reverted in 2016 involved not just one peer but across multiple peers (like the current PR)
10:31 -!- Amirreza [~Amirreza7@77.81.155.207] has left #bitcoin-core-pr-reviews [Leaving]
10:31 -!- nassersaazi [~nassersaa@h1fcd.n1.ips.mtn.co.ug] has quit [Quit: Connection closed]
10:32 < dergoegge> next question: What would be your estimate (lower/upper bound) of how much bandwidth is wasted? (There is no one true answer here, the estimate depends on a couple of variables)
10:33 -!- MacroFake_ [~none@72.5.34.65] has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
10:33 -!- MacroFake [~none@72.5.34.65] has joined #bitcoin-core-pr-reviews
10:33 < juancama> The amount of bandwidth wasted depends partially on if an inv for a block is received before headers chain is caught up, no?
10:34 < dergoegge> Probably best if the answer is a formula to estimate the waste
10:34 < larryruane_> wouldn't the upper bound of waste be something like 80 bytes times number of blocks (700k) times (number of peers - 1)?
10:34 < dergoegge> juancama: yes thats correct, you will download less duplicate data if a block is announced later in the initial sync
10:35 < hernanmarino> I don't have a number but my guess is (amount_of_peers - 1)* size_of_headers * remaining_headers
10:35 < dergoegge> larryruane, hernanmarino: good answers
10:36 < dergoegge> larryruane_: fun fact headers are actually 81 bytes on the wire not 80 :D
10:36 < larryruane_> oh cool, why is that (if not too much of a diversion)?
10:36 < hernanmarino> part of the protocol ? 
10:36 < dergoegge> because they are serialized as empty CBlock's, so you have one extra byte for the empty transaction vector
10:37 < larryruane_> OH got it, thanks, makes sense
10:37 < sipa> The notion of a block header as a protocol concept didn't exist originally.
10:37 < sipa> headers were just blocks without transactions
10:37 < hernanmarino> great
10:37 < larryruane_> (tx vector length is zero, varint)
10:37 < dergoegge> sipa: ah ok i was wondering why it was implemented like that!
10:39 < dergoegge> the estimate could be improved by accounting for the `getheaders` messages but they are probably small in comparison
10:39 < lightlike> I think it's weird that we tie the act of adding more headers-sync peers to a random event (when a block is found). Sometimes it's happening multiple times within 10 minutes, sometimes it doesn't happen for an hour or so.  Waiting for a fixed period (e.g. 10 minutes) before adding another peers would seem more natural to me.
10:40 < dergoegge> lightlike: we'll get there, question 6 will be about the approach :)
10:40 < larryruane_> lightlike: I think it's always been more of an accidental kind of thing... I traced through this code once, and when we get a new block from a peer, that naturally begins a new "thread" of getheaders and headers reply sequence to and from that peer
10:41 < larryruane_> (not thread in the linux sense, but in the p2p sense!)
10:41 < lightlike> oh ok, sorry, i forgot to read the notes...
10:42 < dergoegge> question 5: What’s the purpose of CNodeState’s members fSyncStarted and m_headers_sync_timeout, and PeerManagerImpl::nSyncStarted? If we start syncing headers with peers that announce a block to us via an inv, why do we not increase nSyncStarted and set fSyncStarted = true and update m_headers_sync_timeout?
10:42 < glozow> wait dergoegge, when you said "yeah once our header chain is close to today we request headers from all peers" were you saying that when we're not close to today we try fewer peers?
10:44 < dergoegge> glozow: when we are not close to today, we choose one peer to sync the headers from (and add additional peers if an inv announcement is received)
10:44 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
10:44 < dergoegge> if that chosen peer doesn't deliver within 20 minutes we will disconnect it and try a different one
10:44 < hernanmarino> dergoegge : the purpose is to evict unresponsive nodes, but i don know the answer to the seconda part of the question
10:45 < glozow> oh i got confused thinking that was about the additional inving peers, nvm
10:45 < larryruane_> if we're in that mode, not close to today, would it be good to round-robin among the peers that we request headers from? (instead of just one peer)?
10:45 < larryruane_> (that way we're not trusting a single peer as much)
10:45 < glozow> larryruane_ is round-robin not 1 peer at a time?
10:46 < larryruane_> yes, but i mean send getheaders to peer 1, get reply, then getheaders to peer 2, ... etc (still single-threaded)
10:46 < juancama> fsyncstarted tells us whether we've started headers synchronization with this peer, m_headers_sync_timeout tells us when to potentially disconnect peer for stalling headers download
10:46 < dergoegge> hernanmarino: yes, although m_headers_sync_timeout is only used for our initially chosen headers sync peer
10:47 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 255 seconds]
10:47 < lightlike> dergoegge: Do I understand it correctly that it doesn't really matter if the our peer sends us nothing at all for 20 minutes, or 99% of the headers within that time - they will get disconnected after 20 minutes for stalling either way.
10:47 < adam2k> For question 5: is this to prevent sending headers when another request is in-flight?
10:48 < dergoegge> juancama: yes! but m_headers_sync_timeout is only used on one peer and if nSyncStarted == 1
10:49 < hernanmarino> might it be the case that we only don trust our randomly chosen node, beacuse it will eventually be replaced if unresponsive, and we do not want to do that with the other peers we are adding with this new logic ?
10:49 < dergoegge> nSyncStarted corresponds to the number of peers with fSyncStarted = true
10:49 < dergoegge> lightlike: yes that is my understanding as well, if they don't catch us up within ~20minutes we disconnect
10:50 < glozow> `m_headers_sync_timeout` also depends on how much time we have between tip and today, right? https://github.com/bitcoin/bitcoin/blob/92f6461cfd39fff2fc885dd623fa47e7d8d53827/src/net_processing.cpp#L4904-L4910
10:51 < lightlike> dergoegge: I think it could make sense to also require some progress for them, and disconnecting them much earlier than 20min if they are just completely unresponsive.
10:51 < dergoegge> hernanmarino: I am actually not quite sure, i don't think anything would break if we did set those variables there
10:52 < dergoegge> its a review question that i was asking myself and i don't have a definitive answer yet :D
10:52 -!- Ifeanyichukwu [~Ifeanyich@102.89.42.144] has quit [Quit: Connection closed]
10:52 -!- nassersaazi [~nassersaa@154.0.128.44] has joined #bitcoin-core-pr-reviews
10:52 < dergoegge> lightlike: sounds reasonable
10:52 < lightlike> glozow: yes I think so! It's 15 minutes  + X, with X being close to 5 minutes currently if they sync from genesis.
10:53 < sipa> Historically, I think the case is just that it was never intended that we'd be syncing headers from non-nSyncStarted peers.
10:53 < hernanmarino> ohh, okey. Actually this question is related to my doubt I mentioned earlier so, I'm not sure 
10:53 < juancama> For the second part of question 5, do we not increase nSyncStarted and set fSyncStarted = true and update m_headers_sync_timeout if we start syncing headers with peers that announce a block to us via an inv because it would lead to even more wasted bandwidth?
10:53 < sipa> But it turned outs that (a) we actually do and (b) this is actually somewhat advantageous because it prevents a situation that the singular chosen nSyncStarted peer is malicious/broken/infinitely slow, and stalls your headers sync forever.
10:54 < sipa> (I can say this as the person who first introduced the headers syncing and nSyncStarted concept, until not too recently I wasn't actually aware that we'd start fetching headers from other peers as well if they'd announce a new block to us)
10:55 < dergoegge> sipa: yea i think this happens somewhat by accident, there is a comment about reorgs but not about starting initial sync
10:55 < larryruane_> Just for my historical understanding, it used to be that header and block download would proceed simultaneously (with headers obviously being ahead of blocks in height) ... then some years ago it was changed to download only headers until we're close to today, then start downloading blocks (this makes a lot more sense)
10:55 < dergoegge> sipa: thanks for the explainer, that serves as an answer to me!
10:56 < larryruane_> (i say makes more sense because the old way, we could end up downloading a bunch of blocks that turn out not to be part of the best chain)
10:56 < dergoegge> lets use the last 5 minutes for approach discussion: An alternative to the approach taken in the PR would be to add an additional headers sync peer after a timeout (fixed or random). What is the benefit of the approach taken in the PR over this alternative?
10:56 -!- Ifeanyichukwu [~Ifeanyich@102.89.42.144] has joined #bitcoin-core-pr-reviews
10:57 < larryruane_> less duplicate (wasted) bandwidth?
10:57 < dergoegge> i think a fixed timer for adding new peers would have roughly the same bandwidth usage
10:58 -!- ibaddesmukh [~ibaddesmu@103.244.177.22] has quit [Quit: Connection closed]
10:58 < dergoegge> suhas argues on the PR that peers that announce an inv to us have a higher probability of being responsive
10:58 -!- juancama88 [~juancama@pool-74-96-218-208.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
10:58 -!- juancama88 [~juancama@pool-74-96-218-208.washdc.fios.verizon.net] has quit [Client Quit]
10:58 < lightlike> I think one benefit is that the peer that manages to send us the block inv first is often also a very fast peer. So we'd not pick another slow peer if for some reason our initial peer is slow.
10:59 < dergoegge> lightlike: +1
10:59 < glozow> after this timeout, would we accept any number of peers or just 1 peer?
10:59 < adam2k> I think the benefit over the alternative suggestion is that we would reduce bandwidth usage over adding additional header sync peer?
11:00 < lightlike> (but that could also be achieved in other ways, e.g. picking a fast peer after 10 minutes)
11:00 < dergoegge> glozow: i meant just one peer
11:01 < dergoegge> oh that's time! feel free to stick around and discuss some more
11:01 < dergoegge> #endmeeting
11:01 < hernanmarino> i have a question ... 
11:01 < dergoegge> thank you all for coming!!
11:01 < larryruane_> thanks, @dergoegge, very informative meeting!
11:01 < glozow> okok
11:01 < glozow> thanks dergoegge!
11:01 < adam2k> thanks dergoegge
11:01 < lightlike> thanks dergoegge!
11:01 -!- vnprc [~vnprc@136.56.39.155] has quit [Quit: Connection closed]
11:01 < juancama> Thanks everyone
11:01 < hernanmarino> thanks ! 
11:01 < svav> Thanks dergoegge
11:02 -!- adam2k [~adam2k@ip24-254-208-245.hr.hr.cox.net] has quit [Quit: Connection closed]
11:02 < Lov3r_Of_Bitcoin> thanks a lot
11:02 < pablomartin> thanks dergoegge!
11:02 < dergoegge> hernanmarino: feel free to ask your question now :) 
11:02 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
11:02 -!- Lov3r_Of_Bitcoin [~Lov3r_Of_@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed]
11:03 < hernanmarino> My understanding is that this PR changes the "asking for headers" to ALL of our peers to SOME (but more than one, eventually) Am I correct ? Initially i thought i was strict limited to one , but i think not  
11:03 < hernanmarino> that there are some situations that might lead to our node synchronizing with many peers
11:04 < dergoegge> with the PR you add one additional peer for every block that is announced
11:04 < hernanmarino> exactly 
11:05 < hernanmarino> that was my doubt 
11:05 < dergoegge> so eventually if all the peers are slow you might end up with quite a few
11:05 < hernanmarino> now .. .is that correct ? bandwith-wise  
11:05 < dergoegge> but in that case you probably want to try a lot of peers because you want to catch up quickly
11:06 -!- ibaddesmukh [~ibaddesmu@103.244.177.22] has joined #bitcoin-core-pr-reviews
11:06 < hernanmarino> okey given that headers syncing is a fast process it's ok 
11:07 < hernanmarino> you can probably get at most 2 or 3 INVs with new blocks 
11:07 < dergoegge> also the headers sync only makes up a small portion of all the other data that a node downloads during IBD
11:07 < hernanmarino> yes , I agree
11:08 < lightlike> if your own bandwidth is the bottleneck, adding more peers might actually be make it slower - because you now divide it over multiple peers. Though I guess if you are *that* slow it'll  take you ages for the actual IBD anyway.
11:11 < hernanmarino> okey, thanks to everyone, specially dergoegge !
11:12 -!- juancama [~juancama@pool-74-96-218-208.washdc.fios.verizon.net] has left #bitcoin-core-pr-reviews []
11:13 -!- pablomartin [~pablomart@37.120.148.188] has quit [Quit: Leaving]
11:23 -!- ibaddesmukh [~ibaddesmu@103.244.177.22] has quit [Quit: Connection closed]
11:23 -!- ibaddesmukh [~ibaddesmu@103.244.177.22] has joined #bitcoin-core-pr-reviews
11:24 -!- ibaddesmukh [~ibaddesmu@103.244.177.22] has quit [Client Quit]
11:27 -!- anon [~anon@8.48.69.117] has joined #bitcoin-core-pr-reviews
11:27 -!- anon is now known as Guest1197
11:27 -!- Guest1197 [~anon@8.48.69.117] has quit [Client Quit]
11:30 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Quit: Connection closed]
11:34 -!- Jennie [~Jennie@129.18.209.14] has quit [Quit: Connection closed]
12:11 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:17 -!- nassersaazi [~nassersaa@154.0.128.44] has quit [Quit: Connection closed]
12:37 -!- nassersaazi [~nassersaa@154.0.128.44] has joined #bitcoin-core-pr-reviews
12:38 -!- nassersaazi [~nassersaa@154.0.128.44] has quit [Client Quit]
12:39 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
12:39 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
12:45 -!- Ifeanyichukwu [~Ifeanyich@102.89.42.144] has quit [Quit: Connection closed]
12:54 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
13:01 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
13:04 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 268 seconds]
13:07 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
13:08 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:09 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
13:18 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
13:23 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 268 seconds]
13:24 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
13:28 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 268 seconds]
13:34 -!- dongcarl [~dongcarl@cpe-66-65-184-36.nyc.res.rr.com] has quit [Ping timeout: 252 seconds]
13:35 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
13:38 -!- __gotcha [~Thunderbi@94.105.116.67.dyn.edpnet.net] has quit [Ping timeout: 252 seconds]
13:39 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
13:52 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
14:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has quit [Remote host closed the connection]
14:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
14:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has quit [Ping timeout: 268 seconds]
14:08 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
14:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has quit [Ping timeout: 268 seconds]
14:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
14:46 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
14:56 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 268 seconds]
15:09 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
15:13 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
15:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has quit [Remote host closed the connection]
15:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
15:25 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Read error: Connection reset by peer]
15:25 -!- evanlinjin [~root@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection]
15:25 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
15:26 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
15:26 -!- evanlinjin [~root@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
15:26 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
15:27 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
15:28 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
15:32 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 268 seconds]
15:43 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
15:44 -!- dulce [~dulce@99-113-189-185.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed]
16:13 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
16:13 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
16:44 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Read error: Connection reset by peer]
16:54 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
17:03 -!- evanlinjin [~root@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection]
17:04 -!- evanlinjin [~root@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
17:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has quit [Remote host closed the connection]
17:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
17:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has quit [Ping timeout: 255 seconds]
17:57 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
17:58 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 268 seconds]
18:02 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 268 seconds]
18:08 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
18:09 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
18:21 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
18:33 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
18:35 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Read error: Connection reset by peer]
18:50 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
18:54 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
19:05 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
19:09 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
19:12 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has quit [Ping timeout: 268 seconds]
19:18 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
19:22 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
19:32 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
19:34 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
19:39 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
19:51 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
19:54 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Read error: Connection reset by peer]
20:00 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
20:05 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 252 seconds]
20:11 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
20:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has quit [Ping timeout: 268 seconds]
20:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
21:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has quit [Ping timeout: 268 seconds]
21:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
21:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has quit [Ping timeout: 268 seconds]
21:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
23:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has quit [Ping timeout: 268 seconds]
23:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:59fe:9bfa:2706:c925] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Aug 11 00:00:47 2022