--- Log opened Wed Apr 13 00:00:54 2022
00:36 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
00:40 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 256 seconds]
02:00 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
02:04 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
02:15 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has quit [Ping timeout: 240 seconds]
02:21 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
02:45 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
02:49 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
03:22 -!- duderonomy [~duderonom@c-73-158-190-156.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
03:47 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
03:51 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 250 seconds]
04:10 -!- TheRec [~toto@user/therec] has quit []
06:11 -!- meshcollider [meshcollid@meshcollider.jujube.ircnow.org] has joined #bitcoin-core-pr-reviews
06:11 -!- otech [~otech@80.251.179.171] has joined #bitcoin-core-pr-reviews
07:14 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
07:19 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 250 seconds]
08:00 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has quit [Remote host closed the connection]
08:01 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
08:02 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
08:03 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Client Quit]
08:03 -!- s10s [~s10s@071-085-248-057.res.spectrum.com] has joined #bitcoin-core-pr-reviews
08:05 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
08:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has joined #bitcoin-core-pr-reviews
08:10 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has quit [Ping timeout: 240 seconds]
08:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has joined #bitcoin-core-pr-reviews
08:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has quit [Ping timeout: 240 seconds]
08:22 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
08:27 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 256 seconds]
08:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has joined #bitcoin-core-pr-reviews
08:42 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews
08:42 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host]
08:42 -!- TheRec [~toto@user/therec] has joined #bitcoin-core-pr-reviews
09:13 -!- DavidHeinrich [~DavidHein@bras-base-hmtnon0109w-grc-30-76-64-174-102.dsl.bell.ca] has joined #bitcoin-core-pr-reviews
09:25 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:40 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
09:45 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
09:54 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
09:54 -!- a_GucciPoet [~a_GucciPo@068-188-185-025.res.spectrum.com] has joined #bitcoin-core-pr-reviews
09:59 -!- Robin [~Robin@c-76-26-186-115.hsd1.fl.comcast.net] has joined #bitcoin-core-pr-reviews
09:59 -!- Robin is now known as Guest3679
09:59 -!- Guest3679 [~Robin@c-76-26-186-115.hsd1.fl.comcast.net] has quit [Client Quit]
10:00 < lightlike> #startmeeting
10:00 < larryruane> hi
10:00 -!- RobinAdams [~RobinAdam@c-76-26-186-115.hsd1.fl.comcast.net] has joined #bitcoin-core-pr-reviews
10:00 < danielabrozzoni> hi
10:00 < lightlike> Hi, welcome to the PR Review Club!
10:01 < theStack> hi
10:01 -!- Guest3602 [~Cass@50.80.188.244] has joined #bitcoin-core-pr-reviews
10:01 -!- Guest3602 [~Cass@50.80.188.244] has quit [Client Quit]
10:01 < ls55> hi
10:01 < lightlike> Feel free to say hi if you're here - any first-timerst today?
10:01 < RobinAdams> First time
10:01 < a_GucciPoet> Hey everyone
10:01 < b10c> hi (lurking-only today)
10:02 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
10:02 < lightlike> Welcome RobinAdams!
10:02 < lightlike> Today's meeting is on #21726 (Improve Indices on pruned nodes via prune blockers)
10:02 < lightlike> notes are at https://bitcoincore.reviews/21726
10:02 < svav> Hi
10:02 < lightlike> Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?
10:03 < RobinAdams> I have it open now, looking at it
10:03 < ls55>  Approach ACK. What is the best way to test this PR? Because indexing takes a lot of time.
10:03 < danielabrozzoni> Approach ACK, I still need to test 🙂 
10:04 < theStack> light concept ack -- seems reasonable to allow more indices to be run on pruned nodes and clean up some circular dependencies by the way
10:04 < lightlike> ls55: If you test on other networks than mainnet, it doesn't take that much time.
10:05 < larryruane> theStack: +1 same for me
10:05 < lightlike> ls55: one way is to test with the pyhton framework on regtests (there is a functional test added in this PR)
10:05 < lightlike> another possibility would be to test on signet.
10:06 < a_GucciPoet> can someone explain circular dependency
10:06 < lightlike> a_GucciPoet: We'll come to this soon, it's the second question :)
10:07 < a_GucciPoet> ok thanks
10:07 < lightlike> Let's start with a general one:
10:07 < lightlike> Can you summarize what indexes currently exist in bitcoin core, and what each of them does?
10:07 -!- azor [~azor@190-36-225-125.dyn.dsl.cantv.net] has joined #bitcoin-core-pr-reviews
10:08 < larryruane> I think they're all nicely organized into the `src/index` directory
10:08 < danielabrozzoni> coin stats index - statistics on the utxo set; block filter index - to retrieve BIP157 block filters, hashes and headers; tx index - to retrieve transactions by hash
10:08 < lightlike> danielabrozzoni: correct!
10:09 < larryruane> what's listed there are base (common stuff), and then blockfilterindex, coinstatsindex, disktxpos, txindex (4 of them)
10:09 < lightlike> larryruane: yes, I think it started with the txindex, and was then organized into a common framework when blockfilterindex was added
10:10 < lightlike> yes, disktxpos is not an index by itself, it's just an auxiliary file I think
10:11 < lightlike> ok, so all of these indexes use a common framework (index/base) and on top of that have their own specific code relating to what data they index and how to handle this
10:12 -!- schmidt [~schmidt@50.80.188.244] has joined #bitcoin-core-pr-reviews
10:12 < theStack> the block filter index is the most recent one of the indices i think? (remember some weekly review club sessions in summer 2020)
10:12 < larryruane> and i think these are all leveldb indices (?)
10:13 < ls55> -coinstatsindex: coinstats index used by the gettxoutsetinfo RPC
10:13 < ls55> -txindex: a full transaction index, used by the getrawtransaction rpc call
10:13 < ls55> -blockfilterindex: an index of compact filters by block
10:13 < lightlike> theStack:  I think coinstatsindex is newer, https://github.com/bitcoin/bitcoin/pull/19521 
10:14 < lightlike> larryruane: yes! although blockfilterindex has the special property that the filters themselves are not saved in the levelDB, but in a flatfile - the levelDB has the file positions where one finds the filter.
10:14 < theStack> lightlike: oh good to know; i thought coinstatsindex was there for a longer time and only muhash was added more recently
10:16 < lightlike> Moving on: What is a circular dependency? Why do we want to avoid these when possible?
10:16 < ls55>  If A uses B and conversely then there is a circular dependency. However, the circular dependency maybe subtler. For instance, it may be A that uses B that uses C that uses A.
10:17 < larryruane> (sorry I'm late with this:) I always wonder how stuff is laid out on disk, it looks like the `$HOME/.bitcoin/index` directory has subdirectories for each kind of index
10:17 < larryruane> so they can easily be removed if disabled
10:18 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
10:18 < larryruane> I think circular dependencies make testing harder, because it's hard to link in only the code you want to test? (i'm not exactly sure)
10:18 < lightlike> larryruane: yes, that's where the data is saved. one could also just delete the respective folder and reindex again. I find myself doing that a lot doing testing.
10:18 < ls55> I think all these indexes are saved in levelDB
10:19 < larryruane> if you remove an index from the config, does the node automatically delete its corresponding directory?
10:19 < lightlike> ls55: yes, good explanaion on a circular dependency. there is actuall a script (part of th linter?) which detects new ones.
10:19 < sipa> note that circular dependency can mean two different things
10:20 < sipa> there are "code dependencies", as in: file X includes file Y - if these form a cycle, you code will often just not compile
10:20 < lightlike> ls55: yes, and all indexes hava a separate levelDB database, each in a different directory.
10:21 < sipa> code dependencies can be broken by just using forward declarations or so
10:21 < lightlike> larryruane: no, it won't. You can enable it back on later on, and the index will catch up with the chain, starting from the point it was synced before (and not from genesis)
10:21 < a_GucciPoet> is a circular dependency a security issue?
10:21 < sipa> there are also "conceptual circular dependencies" or so... as in: "module X cannot really be used without module Y"; this is much broader, and not necessarily a problem in the code - just in your design
10:22 < sipa> ideally, modules in your code, if well-organized, are layers - they build on top of each other. If two modules both cannot be used without the other, that's a sign that they should be either just one module, or the interface between them is bad
10:23 < sipa> a_GucciPoet: No, they're just "code smell"
10:23 < sipa> The script can detect some forms of circular dependencies but not all (e.g. it won't catch ones you work around using forward declarations)
10:24 -!- BlueMoon [~BlueMoon@189.233.142.104] has joined #bitcoin-core-pr-reviews
10:24 -!- BlueMoon [~BlueMoon@189.233.142.104] has left #bitcoin-core-pr-reviews []
10:24 < larryruane> I think an easy code circular dependency to get your mind around, that I've seen often in other projects I've worked on, involves logging. If logging takes a mutex, and if the mutex code can possible write log messages... !
10:24 -!- BlueMoon [~BlueMoon@189.233.142.104] has joined #bitcoin-core-pr-reviews
10:25 < lightlike> for example, I think that the existing circular dependency between validation and index caused the indexes to be part of the initial draft of Carl's libbitcoinkernel library for consensus code - as an optional module they really shouldn't be there, but it takes refactoring to make that possible.
10:25 < sipa> Right. Ideally it's always possible for any two modules to use at least one of them without the other one. Circular dependencies break that ability.
10:28 < lightlike> ok, next question: 
10:28 < lightlike> Please explain in your own words how the prune blockers introduced in this PR work.
10:30 < ls55> Are you referring to `m_prune_locks` ?
10:30 < lightlike> ls55: yes!
10:31 < ls55> It is a map representing the index name ("txindex", "coinstatsindex" or "basic blockfilterindex") and the height of the earliest block that should be kept and not pruned for each index.
10:31 < larryruane> prune blockers are a beautiful thing, it's a list of heights, one per kind of index, which set a lower bound on what can be pruned away (removed)
10:31 < lightlike> right! and when are these updated (and by whom?)
10:32 < ls55> It is read in `CChainState::FlushStateToDisk`  
10:32 < otech> Every time any of the 3 indices (since they all inherit the Base Index class) updates the best block index
10:32 < larryruane> if we maintained just a single lowest-height (across all index types), then when that lowest index can advance to a higher height, we wouldn't know what would be the new "lowest" ... so they must be kept separately per-index
10:33 < lightlike> otech: exactly!  The index code tells validation to update the prune locks.
10:33 < ls55> In `BaseIndex::SetBestBlockIndex()`
10:34 < larryruane> if not too much of a side point, I did have a question on this loop https://github.com/bitcoin-core-review-club/bitcoin/commit/527ef4463b23ab8c80b8502cd833d64245c5cfc4#diff-97c3a52bc5fad452d82670a7fd291800bae20c7bc35bb82686c2c0a4ea7b5b98R2282 Could "destructering" be used here so we wouldn't have to reference `.second` which is not very symbolic?
10:34 < lightlike> yes. and ls55 is right too, they are read in CChainState::FlushStateToDisk , which is the point where the node decides whether it should prune away blocks or not.
10:36 < lightlike> larryruane:  what do you mean by "destructuring"?
10:37 < larryruane> (i'm finding an example)
10:38 < lightlike> ok, I'll move to the next q then: Now that we have talked about the new approach, which is the difference to the old one?
10:38 < lightlike> (which is removed in https://github.com/bitcoin-core-review-club/bitcoin/commit/3b8b898d96f570489238a4aa21cf4fe27a4a7e73#diff-97c3a52bc5fad452d82670a7fd291800bae20c7bc35bb82686c2c0a4ea7b5b98L2278-L2281 )
10:40 < ls55> The old code handled only the "blockfilterindex" and this new code iterates over all available indexes to find last height the node can prune. This data is got from `CBlockIndex BaseIndex::m_best_block_index`.
10:40 < ls55> The new code also subtracts `PRUNE_LOCK_BUFFER - 1` from the height of earliest block that should be kept and not pruned.
10:40 < ls55> Regarding the cost, the number of iterations has increased, but it doesn't seem to add much more processing than the previous code.
10:40 < larryruane> lightlike: like this https://github.com/bitcoin/bitcoin/blob/master/src/wallet/scriptpubkeyman.cpp#L1272
10:41 < larryruane> it just makes `first` and `second` into local variables with nice names
10:41 < lightlike> ls55: Yes! So previously, validation would reach into the indexes, and query for their best height.
10:42 < lightlike> Now, the indexes tell validation their best height by themselves. So validation doesn't need to know about the indexes anymore, and there is no longer a circular dependency.
10:43 < lightlike> ls55: what do you mean with "number of iterations"? 
10:43 < lightlike> (this refers to the next question): Is there a cost related to the new approach?
10:44 < ls55> Yes. I thought they were the same question.
10:45 < lightlike> larryruane: looks sensible to me, without knowing too much about it.
10:45 -!- DavidHeinrich [~DavidHein@bras-base-hmtnon0109w-grc-30-76-64-174-102.dsl.bell.ca] has quit [Quit: Connection closed]
10:46 -!- schmidt [~schmidt@50.80.188.244] has quit [Quit: Client closed]
10:47 < lightlike> I also think that there is no meaningful cost related to it. I think one difference is that the prune locks might be updated more often (even when our node doesn't want to prune), but that should be completely negligible.
10:48 < lightlike> I meant "when our node doesnt call FlushStateToDisk"
10:48 -!- a_GucciPoet [~a_GucciPo@068-188-185-025.res.spectrum.com] has quit [Quit: Connection closed]
10:49 < lightlike> Ok, moving on to the last q: Why do you think a buffer of 10 blocks (PRUNE_LOCK_BUFFER) was introduced?
10:49 < lightlike> or maybe first: what does this buffer do?
10:49 < ls55> Because it's higher than expected in regular mainnet reorgs.
10:50 -!- a_GucciPoet [~a_GucciPo@068-188-185-025.res.spectrum.com] has joined #bitcoin-core-pr-reviews
10:50 < theStack> the point of the buffer seems for taking potential reorgs into account
10:50 < ls55> But how many blocks do mainnet reorgs usually involve and how often does this happen?
10:51 < danielabrozzoni> I think 1-2 block reorgs happen quite frequently, but I might be wrong 
10:52 < lightlike> I think that if we are in prune mode, we'll still keep at least 550MB of block data and don't prune it (irrespective of any index code).
10:53 -!- duderonomy [~duderonom@c-73-158-190-156.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
10:53 < otech> I think more than a few blocks reorg would be rare, but I can see it being prudent to set the buffer a bit higher in case of an targeted eclipse attack especially since the use case is for pruned nodes... but not sure if that intuition is wrong...
10:54 < lightlike> so even without the buffer, we wouldn't prune anywhere near the range of blocks that could be affected by a reorg.
10:54 < RobinAdams> I would think putting this value in a config file would make sense, hardcoded seems bad
10:55 < sipa> Rule for making something configurable: you need to be able to express when someone would want to change it, and give advice about it.
10:55 < RobinAdams> Agreed, but then would need rationale for a default as well
10:55 < lightlike> RobinAdams: the prune threshold is configurable "-prune=XYZ" you just have to pick a number >550, otherwise there will be an error.
10:56 < sipa> that's just a guideline of course, but my point is more: "being unable to decide" or "feeling bad about hardcoding" should not be reasons to make something configurable. It's just you as designer not doing your job and trying to shove it off to the user.
10:56 < larryruane> I'm curious to know what happens if we DO have a very large reorg (such that some indices "break" because height decreases too much) ... does the node shut down? No, couldn't be, that would be bad!
10:57 < theStack> didn't look deeper into the code, but is there the theoretical possibility of an integer underflow? "const int lock_height{prune_lock.second.height_first - PRUNE_LOCK_BUFFER - 1};" (if height_first is <= 10)
10:57 < larryruane> sipa: very interesting ... would you ever be in favor of a temporary hidden config option so that if there's some unexpected problem, nodes can be "patched" without needing a new binary?
10:58 < larryruane> theStack: since it's signed and not unsigned, should be ok?
10:58 < sipa> larryruane: Sure, like the "invalidateblock" RPC? I can easily express when I'd advise someone to use it.
10:58 < larryruane> sipa: +1
10:59 < lightlike> theStack: I think the following line makes sure that last_prune is  > 1
10:59 < theStack> larryruane: true! even if it's not a real underflow, i wonder if it has any bad consequences if that number is negative
10:59 < theStack> lightlike: oh, right
11:00 -!- azor [~azor@190-36-225-125.dyn.dsl.cantv.net] has quit [Quit: Connection closed]
11:00 < lightlike> larryruane: The functional test looks at such a case. 
11:00 < lightlike> oh, it's time already
11:00 < lightlike> #endmeeting
11:00 < larryruane> lightlike: thanks, this was great!
11:00 < lightlike> Thanks everyone!
11:00 < a_GucciPoet> good meeting, everyone take care
11:00 < svav> Thanks all
11:00 < danielabrozzoni> Thanks a lot! 😀 
11:01 < RobinAdams> thanks!
11:01 < theStack> thanks for hosting lightlike!
11:01 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
11:01 < otech> ty
11:01 -!- s10s [~s10s@071-085-248-057.res.spectrum.com] has left #bitcoin-core-pr-reviews [Leaving]
11:01 -!- otech [~otech@80.251.179.171] has quit [Quit: Connection closed]
11:02 -!- RobinAdams [~RobinAdam@c-76-26-186-115.hsd1.fl.comcast.net] has quit [Quit: Connection closed]
11:02 < larryruane> sipa: just curious if you agree, I've heard that `invalidateblock` might be useful if there's a 51% empty-block (censoring) attack, there could be a social consensus to invalidate the block that starts that attack (I think Jimmy Song made that point)
11:04 < ls55> Thanks lightlike 
11:05 < sipa> I think it's kind of a mutually-assured-destruction mechanism. The fact is that `invalidateblock` may be used for exactly that purpose, if the situation gets dire enough. Actually needing to use it at scale on the mainchain would be devastating to Bitcoin I think (though perhaps not fatal). And that on its own is on itself a mechanism that can be seen as a deterrent for anyone trying (various kinds of) 51% attacks.
11:06 < larryruane> I see, yes, great point ... the hydrogen bomb of bitcoin
11:06 < a_GucciPoet> sipa: agree
11:22 -!- a_GucciPoet [~a_GucciPo@068-188-185-025.res.spectrum.com] has quit [Quit: Connection closed]
11:37 -!- BlueMoon [~BlueMoon@189.233.142.104] has quit [Quit: Connection closed]
11:38 -!- lowhope [~lowhope@2602:fffa:fff:108a:0:16:3e86:c70e] has quit [Ping timeout: 256 seconds]
12:07 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:36 -!- lowhope [~lowhope@cow9.org] has joined #bitcoin-core-pr-reviews
12:47 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
12:47 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
12:58 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:03 -!- duderonomy [~duderonom@c-73-158-190-156.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer]
13:03 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 256 seconds]
13:12 -!- duderonomy [~duderonom@c-73-158-190-156.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
13:53 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has quit [Remote host closed the connection]
13:58 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has joined #bitcoin-core-pr-reviews
14:05 -!- hashfuncb3b [~user@2601:5c0:c280:7090:fd34:28ad:6238:526d] has joined #bitcoin-core-pr-reviews
14:43 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
15:03 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: Client closed]
15:16 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
15:17 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
15:35 -!- hashfuncb3b [~user@2601:5c0:c280:7090:fd34:28ad:6238:526d] has quit [Ping timeout: 250 seconds]
15:41 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
15:41 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
15:57 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
15:57 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
16:16 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
16:16 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
16:26 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
16:27 -!- shesek [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
16:34 -!- shesek_ [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
16:36 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection]
17:05 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
17:05 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
17:08 -!- shesek_ [~shesek@user/shesek] has quit [Remote host closed the connection]
17:09 -!- shesek_ [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
17:12 -!- shesek__ [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
17:13 -!- shesek_ [~shesek@user/shesek] has quit [Read error: Connection reset by peer]
17:25 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
17:25 -!- shesek__ [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
17:37 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
17:38 -!- shesek__ [~shesek@user/shesek] has joined #bitcoin-core-pr-reviews
17:42 -!- shesek__ [~shesek@user/shesek] has quit [Remote host closed the connection]
19:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has quit [Ping timeout: 260 seconds]
19:52 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has joined #bitcoin-core-pr-reviews
20:58 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has quit [Ping timeout: 248 seconds]
21:00 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has joined #bitcoin-core-pr-reviews
23:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:64b8:125d:e5cc:33b9] has quit [Ping timeout: 248 seconds]
23:21 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Apr 14 00:00:56 2022