--- Log opened Wed Dec 07 00:00:38 2022
00:44 -!- lowhope [~lowhope@2602:fffa:fff:108a:0:16:3e86:c70e] has quit [Ping timeout: 260 seconds]
00:46 -!- lowhope_ [~lowhope@2602:fffa:fff:108a:0:16:3e86:c70e] has joined #bitcoin-core-pr-reviews
00:55 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
00:57 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 255 seconds]
01:26 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
01:29 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 255 seconds]
01:58 -!- windsok [~windsok@rarepepe.cash] has quit [Quit: No Ping reply in 180 seconds.]
02:00 -!- windsok [~windsok@rarepepe.cash] has joined #bitcoin-core-pr-reviews
03:03 -!- ajonas [sid385278@id-385278.helmsley.irccloud.com] has quit [Quit: Connection closed for inactivity]
03:58 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:5122:644c:c142:5646] has joined #bitcoin-core-pr-reviews
04:50 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
04:52 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
05:24 -!- __gotcha [~Thunderbi@79.132.232.211] has quit [Ping timeout: 256 seconds]
05:53 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
05:59 -!- jonatack1 [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
06:00 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
06:36 -!- jtraub91 [~jason@2601:581:8100:7cb0:8107:b66:e649:b1a8] has joined #bitcoin-core-pr-reviews
06:46 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
06:47 -!- jonatack1 [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
06:59 -!- josie[m] [~josiem]@2001:470:69fc:105::2:47a6] has left #bitcoin-core-pr-reviews []
07:57 -!- pablomartin [~pablomart@195.234.124.17] has joined #bitcoin-core-pr-reviews
08:03 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
08:05 -!- __gotcha [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
08:24 -!- rozehnal_paul [~rozehnal_@198.168.27.218] has joined #bitcoin-core-pr-reviews
08:24 -!- rozehnal_paul42 [~rozehnal_@198.168.27.218] has joined #bitcoin-core-pr-reviews
08:25 -!- rozehnal_paul42 [~rozehnal_@198.168.27.218] has quit [Client Quit]
08:25 -!- ss [~ss@137.165.178.213] has joined #bitcoin-core-pr-reviews
08:25 -!- ss is now known as Guest9072
08:26 < Guest9072> hi
08:26 -!- Guest9072 [~ss@137.165.178.213] has quit [Client Quit]
08:27 < lightlike> hi - today's review club will start in ~30 minutes.
08:39 -!- pablomartin4btc [~pablomart@109.69.107.225] has joined #bitcoin-core-pr-reviews
08:42 -!- pablomartin [~pablomart@195.234.124.17] has quit [Ping timeout: 248 seconds]
08:48 -!- hernanmarino [~hernanmar@181.99.169.107] has joined #bitcoin-core-pr-reviews
08:50 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
08:50 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
08:50 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 255 seconds]
08:59 -!- d33r_gee [~d33r_gee@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:00 < lightlike> #startmeeting
09:00 < pablomartin4btc> hello
09:00 < lightlike> hi!
09:00 < rozehnal_paul> hi
09:01 < LarryRuane> hi
09:01 < b_101> hi!
09:01 < lightlike> welcome to review club - today's meeting is about the VerifyDB checks
09:01 < d33r_gee> hello
09:02 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has joined #bitcoin-core-pr-reviews
09:02 < lightlike> notes are at https://bitcoincore.reviews/25574
09:02 < hernanmarino> hi !
09:02 < glozow> hi
09:02 < lightlike> anyone here for the first time?
09:02 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
09:02 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
09:03 < lightlike> ok, let's start. Who had a chance to review the PR? (y/n)
09:03 < pablomartin4btc> y
09:04 < hernanmarino> yes 
09:04 < d33r_gee> yes
09:04 < rozehnal_paul> yes
09:04 < b_101> y
09:04 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:04 < LarryRuane> 0.4
09:05 < lightlike> that's a lot! what's your impression (Concept ACK, approach ACK, tested ACK, or NACK?)
09:05 < hernanmarino> tested 
09:05 < pablomartin4btc> tested ACK
09:05 < hernanmarino> ACK
09:05 < hernanmarino> :)
09:05 < d33r_gee> tested ACK
09:05 < LarryRuane> concept ACK, almost finished with tested ACK
09:05 < rozehnal_paul> concept ack
09:06 < b10c> hi
09:06 < effexzi> Hey every1
09:06 < lightlike> great - let's move to the first question!
09:06 < lightlike> What is the reason the VerifyDB checks are important? Considering that they can delay the startup by several seconds, what would be possible consequences of not having these checks in place?
09:06 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:06 < b_101> concept Ack
09:07 < rozehnal_paul> relaying corrupted blocks?
09:07 < LarryRuane> basic question, the DB being verified is levelDB? is that correct?
09:07 < d33r_gee> they are are important for ensuring the integrity and reliability of the local bitcoin database.
09:07 < hernanmarino> it s important to verify the integrity of the db 
09:08 -!- sdaftuar [~sdaftuar@user/sdaftuar] has joined #bitcoin-core-pr-reviews
09:08 < hernanmarino> As to the consecuences, I'm not really sure, but I guess that greater problems might arise later 
09:08 < lightlike> LarryRuane: it's a mix. there are different levels of check - some verify the blocks stored on disk, others also the chainstate.
09:08 < LarryRuane> I think when bitcoind experiences a non-clean shutdown (such as system OOM or power), there's a fear that the ondisk DB could get corrupted (even though it shouldn't in theory)
09:08 < pablomartin4btc> Without these checks, there is a risk that the database could become corrupted, either due to bugs in the software or due to external factors such as hardware failures or malicious attacks.
09:09 < lightlike> Good answers!
09:10 < pablomartin4btc> If the database were to become corrupted, it could cause the Bitcoin software to crash or behave unpredictably, which could potentially lead to the loss of funds or other problems.
09:10 < andrewtoth_> LarryRuane chainstate is leveldb, blocks are custom file format and also checked
09:10 < LarryRuane> andrewtoth_: lightlike: thanks
09:11 < lightlike> I think another possiblity is that we could fall out of consensus, e.g. rejecting a valid block because of some inconsistency with our chainstate. That would be really bad, maybe worse than crashing.
09:11 < andrewtoth_> it could cause the node to fork off the network if it doesn't just crash from other checks while activating the best chain
09:11 < LarryRuane> and it is possible to check the blocks (`blk*.dat` and `rev*.dat`) on pruned nodes, but only back to the prune height (IIUC)
09:12 < lightlike> LarryRuane: yes, the VerifyDB code accounts for that - if we are pruning and the files aren't there, we don't check any further.
09:12 < rozehnal_paul> an affected node could also lose reputation by relaying corrupted blocks?
09:13 < andrewtoth_> rozehnal_paul yes, relaying corrupted blocks would cause peers to immediately disconnect
09:14 < andrewtoth_> but I don't think this checks all historical blocks for corruption
09:14 < LarryRuane> and just to make sure ... VerifyDB does not check the wallet's DB in any way, does it? (i don't think so)
09:14 < lightlike> andrewtoth: yes, that is important. Does anyone know how many blocks we check by default?
09:15 < lightlike> LarryRuane: no, no connection with the wallet
09:15 < rozehnal_paul> 6 blocks by default
09:15 < b_101> lightlike: only 6
09:15 < LarryRuane> 6 blocks .. wonder if that's purposely the same as what's considered enough to "confirm" a tx?
09:15 < lightlike> rozehnal_paul b_101 correct!
09:17 < lightlike> It's a tradeoff between the time it takes and thouroughness. Probably many of you have seen this slightly annoying 15%...30%... progress in the debug log during startup.
09:18 < LarryRuane> when i first started running bitcoind, i thought it could / should be more than 6 blocks, because that takes so few seconds on my laptop ... but after I got a RPi I noticed it takes quite there! So for that platform at least, it would be bad to be much more than 6
09:18 < lightlike> if we'd scan the entire chain, it would take us hours (and we'd probably run out of memory, but we'll come to that later)
09:18 < andrewtoth_> It does verify the entire chainstate though right? It loads the entire block *index* into memory, just not blocks?
09:19 < LarryRuane> whoops i just started that (entire chain), but on signet, maybe it will be ok (and it has your PR fix)
09:19 < glozow> larryruane: how long did it take on your rpi? like, on the order of seconds or minutes?
09:19 < andrewtoth_> A -reindex basically does a verification on the entire blocks db though I believe
09:19 < LarryRuane> to do 6 blocks, i would say on the order of a minute.. but i'll check and get back to you!
09:20 < lightlike> andrewtoth_: what do you mean with "it" - the VerifyDB checks, or bitcoind in general?
09:20 < glozow> oh wow that's slow! cool to know
09:20 < andrewtoth_> the VerifyDB checks
09:20 < LarryRuane> andrewtoth_: a -reindex actually *rebuilds* the block index and chainstate
09:21 < lightlike> andrewtoth_: ok, in that case I don't think so. But this leads to the next question, what the checks actually do:
09:21 < lightlike> Can you describe the checks that each of the four levels of VerifyDB perform? For which of the levels is the dbcache size relevant?
09:21 < lightlike> actually, it's five levels, I forgot it starts with 0...
09:22 < rozehnal_paul> Sipa commented in january 2013 the following :
09:22 < rozehnal_paul> -checklevel gets a new meaning:
09:22 < rozehnal_paul> 0: verify blocks can be read from disk (like before)
09:22 < rozehnal_paul> 1: verify (contextless) block validity (like before)
09:22 < rozehnal_paul> 2: verify undo data can be read and matches checksums
09:22 < rozehnal_paul> 3: verify coin database is consistent with the last few blocks (close to level 6 before)
09:22 < rozehnal_paul> 4: verify all validity rules of the last few blocks (including signature checks)
09:22 < LarryRuane> glozow: I was off by a little, it takes 31 seconds (for the default 6 blocks, level 3) on raspberry pi
09:22 < glozow> larryruane: ah nice, thanks!
09:23 < d33r_gee> Check 0: reads blocks from diskfrom disk and returns and error if ReadBlockFromdisk is false
09:23 < d33r_gee> Check 1: runs CheckBlock returns error if false
09:23 < d33r_gee> Check 2: runs CBlockUndoin pindex  returns false if bad data is found
09:23 < d33r_gee> Check 3: confirms that the best block matches pindex block hash
09:23 < d33r_gee> Check 4: last check try to reconnect if failure if previously interrupted (?)
09:23 < LarryRuane> you can see what each level does with `bitcoin-cli help verifychain`, it's pretty nice
09:23 < yashraj> what does 2 mean?
09:24 < lightlike> rozehnal_paul d33r_gee: yes exactly!
09:24 < rozehnal_paul> LarryRuane thx for the cmd tip
09:24 < b_101> lightlike: level 3 test can fail due to insuficient dbcache size
09:25 < b_101> LarryRuane: +1, thx
09:25 < lightlike> b_101: yes! 
09:27 < lightlike> so it's important to note that Level 0-2 are note independent of context ("the chain"), including  the CheckBlock at level 1. They just test the blocks in isolation.
09:29 < pablomartin4btc> yeah
09:29 < lightlike> fun fact, until very recently VerifyDB wasn't able to verify the entire main chain. Does anyone have an idea why that might have been the case?
09:31 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:32 < hernanmarino> lightlike: just guessing ... memory constraints combined with the implementation ?
09:32 < lightlike> that's an issue, but with enough memory it should be solvable.
09:32 < LarryRuane> is it this maybe? (i'm sort of guessing) https://github.com/bitcoin/bitcoin/pull/21523
09:33 < lightlike> It was because it couldn't deal with the duplicate coinbase transactions (BIP30) which are in the history of the chain. https://github.com/bitcoin/bitcoin/pull/24851 fixed that, I think.
09:33 < LarryRuane> oh that's amazing!
09:33 < hernanmarino> ohh, okey  I understand 
09:33 < rozehnal_paul> I thought I remembered reading that!
09:34 < lightlike> yes, I should have included that in the questions, thought about it too late...
09:34 < lightlike> moving on to the next q:
09:34 < LarryRuane> that was from before the soft-fork requiring the block height to be encoded into the coinbase tx
09:34 < lightlike> In the failure case, why exactly is the Assertion hashPrevBlock == view.GetBestBlock() in Chainstate::ConnectBlock() hit?
09:35 < LarryRuane> i'm sort of guessing here, but is it because `view` isn't populated (enough) due to the low value for dbcache?
09:35 < lightlike> LarryRuane: yes, there are two pairs of identical txids around block ~100000 or so.
09:37 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
09:38 < d33r_gee> There a mismatch between the current block and what the previous block should be, hinting at perhaps tampering or corruption of the database
09:38 < lightlike> What do the level 3 checks do if the memory is insufficient?
09:39 < b_101> lightlike: skip tests and continue with level 4?
09:39 < LarryRuane> (this is probably wrong but...) seems like level 3 checks are skipped completely in that case
09:40 < lightlike> yes, correct. We skip the level 3, not disconnecting the block in our in-memory copy, but we continue to the next block (because level 0-3 are done in a loop, together for each block)
09:41 < lightlike> and why does level 4 have a problem with that?
09:45 < lightlike> Ok, I'll answer myself:
09:45 < lightlike> Because Level 4 tries to re-connect all the blocks that were meant to be disconnected before - including the blocks that we skipped. So it tries to reconnect a block of a height that was previously never disconnected.
09:45 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 252 seconds]
09:45 < lightlike> does that explanation make sense?
09:46 < LarryRuane> yes, definitely makes sense!
09:46 < hernanmarino> yes, thanks !
09:46 < d33r_gee> yep it makes sense...
09:46 < lightlike> next question: Were you able to reproduce the VerifyDB crash on master and verify that this branch prevents it? (Hint: use -dbcache=1 as a startup arg to bitcoind)
09:47 < pablomartin4btc> yes
09:47 < d33r_gee> nope
09:47 < LarryRuane> yes i was able to reproduce, but I had to specify a larger depth than 1000 ... 5000 worked to reproduce the problem for me
09:47 < rozehnal_paul> no, not spinning a full node right now.
09:47 < hernanmarino> yes, tested both on master and on the PR branch
09:47 < LarryRuane> (that was on signet, in case it matters)
09:48 < rozehnal_paul> LarryRuane what values do 1000 and 5000 refer to? block depth?
09:48 < rozehnal_paul> separate question, what are the units for dbcache = x ?
09:49 < lightlike> LarryRuane: I think it could depend on how large the recent blocks were. If they were empty, disconnecting them doesn't need a lot of memory.
09:50 < LarryRuane> rozehnal_paul: yes that number (last argument to verifydb RPC) indicates how far back in history from the current tip to check
09:50 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has quit [Remote host closed the connection]
09:50 < lightlike> rozehnal_paul: It's MiB
09:50 < LarryRuane> lightlike: i see, that makes sense.. i would imagine signet blocks are pretty light
09:50 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has joined #bitcoin-core-pr-reviews
09:51 < LarryRuane> lightlike: I think he was referring to the depth or nblocks argument not -dbcache
09:51 < lightlike> LarryRuane: I guess it depends on whether someone is currently using signet to test something. When I opened the PR, it did fail for me with these parameters, but maybe the recent blocks of signet are less full than the ones back then.
09:52 < rozehnal_paul> LarryRuane did you use the bitcoin cli sandbox on bitcoindev.network or a node in signet? for next weeek my goal is to test-ack from with th sandbox version
09:52 < LarryRuane> also if you specify 0 for this argument, just FYI, it checks all blocks back to the beginning
09:53 < LarryRuane> rozehnal_paul: interesting, i'm not aware of that sandbox ... I'm running a local node
09:53 < lightlike> Next q: In addition to fixing the crash, this PR also changes the way both init and the verifychain RPC handle errors. Can you describe these?
09:53 < rozehnal_paul> I imagine the error thrown is more detailed
09:54 < lightlike> rozehnal_paul: I also never use a sandbox. I have a local datadir for signet / testnet that I use when I need to test something.
09:54 < hernanmarino> they are more verbose / descriptive when logging / reporting
09:55 < lightlike> they also change the behavior in case of an incomplete check due to insufficient cache.
09:55 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has quit [Ping timeout: 256 seconds]
09:55 < hernanmarino> rozehnal_paul: if you want to run a local node, you can sync the whole signet chain in just under an hour 
09:56 < lightlike> the question is basically: do we want to fail init in this case? There is no error, but we also didn't check everything we wanted.
09:56 < hernanmarino> lightlike: are you referring to the return value, for example ?
09:56 < lightlike> hernanmarino: yes, the return value of the -verifychain RPC
09:56 < rozehnal_paul> hernanmarino looks like with these commands i can get it going https://en.bitcoin.it/wiki/Signet#Why_run_Signet.3F
09:57 < rozehnal_paul> lightlike i think a warning error suffices, if it tells the node operator to increase dbcache in order to complete the tests.
09:58 < LarryRuane> lightlike: "do we want to fail init in this case?" -- not to spoil the party too much, but you answered this in the PR description (third bullet point)
09:58 < lightlike> so my thoughts were: If we actually fire up an RPC verifychain, the result should be false if we didn't complete the checks, so the user can do something about this (like increasing the cache).
09:58 < pablomartin4btc> lightlike: I agree with it
09:59 < LarryRuane> yes this is a nice PR! I hope it gets merged soon
10:00 < LarryRuane> i'll review in detail this week
10:00 < lightlike> In case of Init, my thinking was if we actually deviate from the defaults (e.g. to check more and deeper) then aborting is ok. However, if we just want to get our node starting (not touching the defaults) we don't want to abort if the checks are incomplete.
10:00 < LarryRuane> lightlike: +1
10:00 < rozehnal_paul> +1
10:00 < lightlike> That's it - thanks for attending!
10:00 < lightlike> #endmeeting
10:00 < LarryRuane> thanks lightlike: this was really informative!
10:00 < d33r_gee> thanks every1
10:01 < rozehnal_paul> thanks lightlike
10:01 < andrewtoth_> thanks lightlike!
10:01 < hernanmarino> thanks !
10:02 -!- d33r_gee [~d33r_gee@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed]
10:02 < pablomartin4btc> thanks lightlike and all!
10:02 < glozow> thank you lightlike!
10:05 < effexzi> Thanks every1
10:27 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Ping timeout: 264 seconds]
10:34 -!- rozehnal_paul [~rozehnal_@198.168.27.218] has quit [Quit: Connection closed]
10:34 -!- __gotcha [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
10:37 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
10:38 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
10:38 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Ping timeout: 260 seconds]
10:41 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
10:41 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
11:19 -!- jonatack1 [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
12:14 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:31 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:47 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
12:49 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
12:53 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
13:01 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
13:01 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
13:05 -!- jtraub91 [~jason@2601:581:8100:7cb0:8107:b66:e649:b1a8] has quit [Ping timeout: 260 seconds]
13:29 -!- pablomartin4btc [~pablomart@109.69.107.225] has quit [Ping timeout: 260 seconds]
13:36 -!- jtraub91 [~jason@2601:581:8100:7cb0:8107:b66:e649:b1a8] has joined #bitcoin-core-pr-reviews
13:40 -!- jtraub91 [~jason@2601:581:8100:7cb0:8107:b66:e649:b1a8] has quit [Ping timeout: 260 seconds]
13:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:5122:644c:c142:5646] has quit []
13:55 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
13:59 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
14:39 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
17:05 -!- aureleoules [~aureleoul@82-64-162-213.subs.proxad.net] has quit [Ping timeout: 248 seconds]
17:06 -!- aureleoules [~aureleoul@82-64-162-213.subs.proxad.net] has joined #bitcoin-core-pr-reviews
17:38 -!- hernanmarino [~hernanmar@181.99.169.107] has quit [Quit: Leaving]
17:48 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 255 seconds]
17:49 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
17:51 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
17:52 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
19:13 -!- b_101_ [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
19:16 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 264 seconds]
19:30 -!- jtraub91 [~jason@2601:581:8100:7cb0:8107:b66:e649:b1a8] has joined #bitcoin-core-pr-reviews
19:50 -!- jtraub91 [~jason@2601:581:8100:7cb0:8107:b66:e649:b1a8] has quit [Quit: WeeChat 3.7.1]
20:13 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 255 seconds]
20:18 -!- jonatack1 [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
20:20 -!- b_101_ [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 264 seconds]
20:32 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
20:37 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 268 seconds]
20:42 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
20:50 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
21:07 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
21:13 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 252 seconds]
21:26 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
21:30 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 252 seconds]
21:44 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
21:50 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 268 seconds]
22:18 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
22:23 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 252 seconds]
22:35 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
22:40 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 256 seconds]
22:54 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
22:59 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 248 seconds]
23:11 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
23:16 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 246 seconds]
23:45 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
23:50 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 256 seconds]
23:51 -!- __gotcha [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
23:55 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Ping timeout: 260 seconds]
23:56 -!- NorrinRadd [~me@102.67.16.112] has joined #bitcoin-core-pr-reviews
23:57 -!- NorrinRadd [~me@102.67.16.112] has quit [Client Quit]
--- Log closed Thu Dec 08 00:00:40 2022