--- Log opened Wed Dec 29 00:00:15 2021
00:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
00:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 240 seconds]
00:09 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
00:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 268 seconds]
00:20 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
00:24 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 240 seconds]
00:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
00:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 268 seconds]
00:36 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
00:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 240 seconds]
00:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
00:49 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 252 seconds]
00:55 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
01:00 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 260 seconds]
01:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
01:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 250 seconds]
01:19 -!- Yihen [~textual@153.122.173.92] has joined #bitcoin-core-pr-reviews
01:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
01:39 -!- Yihen [~textual@153.122.173.92] has quit [Remote host closed the connection]
01:39 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 268 seconds]
01:40 -!- Yihen [~textual@114.113.238.18] has joined #bitcoin-core-pr-reviews
01:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
01:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 268 seconds]
02:08 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
02:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 268 seconds]
02:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
02:18 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 240 seconds]
02:18 -!- dr-orlovsky [~dr-orlovs@31.14.40.18] has quit [Ping timeout: 268 seconds]
02:36 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
02:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 252 seconds]
02:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
03:07 -!- dr-orlovsky [~dr-orlovs@31.14.40.18] has joined #bitcoin-core-pr-reviews
03:20 -!- dr-orlovsky [~dr-orlovs@31.14.40.18] has quit [Read error: Connection reset by peer]
03:21 -!- dr-orlovsky [~dr-orlovs@31.14.40.18] has joined #bitcoin-core-pr-reviews
04:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Remote host closed the connection]
04:19 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
04:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Remote host closed the connection]
04:52 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
04:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 268 seconds]
05:20 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
05:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 252 seconds]
05:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
05:39 < michaelfolkson> [19:30:54]  <jeremyrubin> pinheadmz: this is also a difference between CTV's digest algo and APO where CTV commits to all other scriptsigs + sequences, APO does not, if you were curious
05:40 < michaelfolkson> jeremyrubin: APO and APOAS both currently commit to sequences?
06:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Remote host closed the connection]
06:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
06:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 240 seconds]
07:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
07:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 240 seconds]
07:36 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
07:41 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 268 seconds]
07:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
07:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 252 seconds]
07:47 -!- scavr [~scavr@2a02:908:166:3020:7be9:202c:ce68:4fdf] has joined #bitcoin-core-pr-reviews
08:05 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
08:44 -!- shapleigh1842 [~shapleigh@96-92-170-77-static.hfc.comcastbusiness.net] has joined #bitcoin-core-pr-reviews
08:51 -!- zerotobtc [~zerotobtc@94.31.106.95] has joined #bitcoin-core-pr-reviews
08:53 -!- shapleigh1842 [~shapleigh@96-92-170-77-static.hfc.comcastbusiness.net] has quit [Quit: Connection closed]
08:58 -!- shapleigh1842 [~shapleigh@96-92-170-77-static.hfc.comcastbusiness.net] has joined #bitcoin-core-pr-reviews
09:00 < b10c> #startmeeting
09:00 < b10c> Welcome to the last Bitcoin Core review club meeting of 2021!
09:00 < b10c> Feel free to say hi!
09:00 < shapleigh1842> hi!
09:00 < scavr> hi
09:00 < b10c> Today we are talking about PR 20827 "During IBD, prune as much as possible until we get close to where we will eventually keep blocks" https://github.com/bitcoin/bitcoin/pull/20827
09:01 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:01 < b10c> Notes are on https://bitcoincore.reviews/20827
09:01 < michaelfolkson> hi
09:01 < b10c> anyone got a chance to have a look at this over the holidays?
09:02 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:02 < scavr> yes read the notes and had a look at the changes
09:02 < svav> Hi
09:03 < michaelfolkson> Yup read the notes too
09:04 < b10c> cool! the diff is only a few lines, this one is more about understanding how pruning in Bitcoin Core works. Let's dive right in with the questions, but feel free to ask questions any time!
09:04 < b10c> What does this PR do? What is the goal of this PR?
09:05 < svav> I read the notes too ...
09:05 < scavr> The goal is to optimize the pruning strategy during initial block download
09:06 < b10c> svav: was everything clear? any questions?
09:06 < michaelfolkson> More aggressive pruning to speed up IBD for a pruned node
09:06 < svav> Why was this PR felt necessary?
09:06 -!- zerotobtc [~zerotobtc@94.31.106.95] has quit [Quit: Connection closed]
09:07 < b10c> scavr michaelfolkson: correct! What do we prune now that we previously didn't prune?
09:07 < michaelfolkson> IBD speedups are always good. I was more unsure why there wasn't already aggressive pruning in the original code
09:07 < svav> I would say if the IBD acronym is used, it should be defined once as Initial Block Download for clarity for newbies
09:08 < shapleigh1842> ^^yes I just figured this acronym out
09:08 < michaelfolkson> ^
09:09 < b10c> svav: performance improvements are always welcome. This helps people running Bitcoin Core on lower end hardware. e.g. Raspberry Pi's
09:09 < michaelfolkson> b10c: Just more blocks right? blk.dat and rev.dat files
09:09 < svav> b1c: and do we know how significant a performance increase this gives?
09:09 < shapleigh1842> context Q: during an IBD on a "pruned" node, does the node still download the entire blockchain, albeit verifying and pruning as it goes?
09:10 < sipa> IBD is no different from normal synchronization really. It just changes some heuristics/policies.
09:10 < sipa> All blocks are still downloaded and verified the same, whether IBD or not.
09:11 < michaelfolkson> Random q: Are rev.dat files what undo.dat files used to be called?
09:11 < shapleigh1842> sipa: thank you.
09:12 < b10c> michaelfolkson: yes! we just free up more space once we decide to prune
09:12 < sipa> @michaelfolkson I can't remember Bitcoin Core ever having had an undo.dat file.
09:13 < b10c> I think it's called undo data in the code and the files are called rev*.dat (?)
09:13 < sipa> Yeah, rev*.dat files contain undo data.
09:13 < michaelfolkson> sipa: This comment refers to undo.dat files https://github.com/bitcoin/bitcoin/blob/8c0bd871fcf6c5ff5851ccb18a7bc7554a0484b0/src/validation.h#L405
09:13 -!- kuznechik [~kuznechik@cpe-184-153-102-43.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews
09:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Remote host closed the connection]
09:14 < b10c> hm this should probably be rev*.dat files, not sure if this got changed at some point
09:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
09:15 < b10c> Next question:  Where in the code do we check if we need to prune old block data?
09:15 < sipa> That's a typo I think.
09:15 < sipa> In what branch do you see that?
09:15 < michaelfolkson> Master
09:16 < svav> validation.cpp
09:16 < scavr> we check it in CChainState::FlushStateToDisk before we check if we need to flush the dbcache
09:17 < shapleigh1842> so just browsing this diff [and I'm sure I could look this up in a readme] it looks like the bitcoin codebase standard is to only provide parameter comments for [out] parameters? (i.e. no comments required for normal params or return?)
09:18 < sipa> michaelfolkson: It was introduced in commit f9ec3f0fadb11ee9889af977e16915f5d6e01944 in 2015, which introduced pruning in the first place. Even then the files were called rev*.dat.
09:19 < b10c> svav scavr: correct! I somehow assumed it would it's done when connecting a new block, but I guess we call FlushStateToDisk often enough (but don't actually flush the cache)
09:20 < b10c> sipa: maybe they were called undo*.dat in a first interation of the pruning feature, but got renamed during development
09:20 < michaelfolkson> sipa: So a typo then. I'll open a PR to correct (or someone new can)
09:21 < sipa> No, because the rev*.dat files predate pruning. I introduced the concept of rev*.dat files ;)
09:21 < b10c> sipa: oh, I see :D
09:21 < b10c> next question: Under which conditions do we prune and what is removed? What is not pruned?
09:22 -!- azor [~azor@201.208.224.235] has joined #bitcoin-core-pr-reviews
09:22 < scavr> we prune once disk_usage + buffer >= prune target
09:23 -!- shapleigh1842 [~shapleigh@96-92-170-77-static.hfc.comcastbusiness.net] has quit [Quit: Connection closed]
09:23 < svav> Pruning will never delete a block within a defined distance (currently 288) from the active chain's tip.
09:23 < scavr> and we stop once that's no longer the case
09:23 < b10c> scavr svav: correct!
09:24 < b10c> svav: to be clear, we don't delete a block file with a block 288 blocks from tip 
09:25 < b10c> rev*.dat files are also pruned
09:25 < michaelfolkson> There is a block index and a UTXO database in dbcache... https://bitcoin.stackexchange.com/questions/99098/what-is-in-the-bitcoin-core-leveldb-dbcache-is-it-full-records-or-metadata
09:25 < michaelfolkson> The block index isn't deleted?
09:26 < sipa> No, only the blocks.
09:26 < sipa> We don't want to forget about old blocks, just their contents is forgotten.
09:27 < b10c> There are flags in the index that indicate if we HAVE_BLOCK_DATA and HAVE_UNDO_DATA
09:27 < b10c> I guess they are set to false when we prune?
09:28 < sipa> Yeah, I believe so.
09:28 < b10c> What is the variable nBuffer in BlockManager:FindFilesToPrune() being used for? How large is the buffer (in MB)?
09:29 < sipa> In the very first commit that added undo files they were called "<HEIGHT>.und", actually: 8adf48dc9b45816793c7b98e2f4fa625c2e09f2c.
09:29 < michaelfolkson> I think of blocks as transactions (rather than UTXO diffs) and deleting transactions but this is deleting from a UTXO database right? Effectively spent txo
09:29 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:29 < sipa> No, pruning is unrelated to the UTXO set.
09:30 < scavr> the nBuffer and the current disk usage are summed up when checking if the prune target has been reached
09:30 -!- shapleigh1842 [~shapleigh@96-92-170-77-static.hfc.comcastbusiness.net] has joined #bitcoin-core-pr-reviews
09:30 < sipa> The UTXO set is already UTXO: it only contains spent outputs already.
09:30 < sipa> unspent, sorry
09:31 < b10c> another acronym worth mentioning: UTXO = unspend transaction output
09:31 < sipa> Pruning is literally deleting the block files (blk*.dat) and undo files (rev*.dat) from disk, nothing more. It does not touch the UTXO set, and doesn't delete anything from any database.
09:31 < michaelfolkson> Ok thanks
09:31 < sipa> (apart from marking the pruned blocks as pruned in the database).
09:31 < b10c> scavr: do you know how big the buffer is?
09:32 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
09:32 < scavr> it starts as 17 MB (16MB block chunk size + 1 MB undo chunk size)
09:34 < b10c> correct! we pre-allocate the files in chunks so we want to keep this as a buffer
09:35 < scavr> when in IBD we add 10% of the prune target to the buffer
09:35 < scavr> so 17MB + 55MB = 72MB?
09:35 < scavr> with a prune target of 550MB
09:36 < michaelfolkson> 550 being the minimum
09:36 < scavr> this is similar to PR 20827 also an optimization, right?
09:36 < b10c> yes! that's my understanding too. why?
09:37 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
09:37 < b10c> yep, we leave a bit bigger buffer to have to flush too soon again (causing another dbcache flush)
09:38 < b10c> With 20827 the buffer will be 17 MB + `number of blocks left to sync` * 1 MB
09:39 < michaelfolkson> The downside of having a big dbcache is that when it fills it takes longer to flush so time trade-offs I'm guessing. Saves time overall as infrequent flushing
09:39 < sipa> That point is that any pruning involves flushing, whether it's deleting a small or large amount of blocks.
09:40 < b10c> michaelfolkson: yes, with a large dbcache you could do IBD without ever flushing
09:40 < sipa> And frequent flushing is what kills IBD performance.
09:40 -!- azor [~azor@201.208.224.235] has quit [Quit: Connection closed]
09:40 < sipa> So by deleting more when we prune, the pruning (and thus flushing) operation needs to be done less frequently.
09:40 < michaelfolkson> Frequent flushing of small dbcaches is a lot worse than infrequent flushing of big dbcaches, right
09:41 < sipa> The size isn't relevant. If you flush frequently, the dbcache just won't grow big.
09:41 < b10c> not really about dbcache size in this PR, more about number of flushes we do
09:41 < sipa> Speed is gained by having lots of things cached. When you flush, the cahce is empty.
09:42 < sipa> These two are related: the longer you go without flushing, the bigger the database cache grows.
09:42 < sipa> The dbcache parameter sets when you have to forcefully flush because otherwise the cache size would exceed the dbcache parameter.
09:42 < b10c> The PR assumes 1MB for average_block_size. How accurate does this assumption have to be?
09:44 < michaelfolkson> b10c: Presumably not very accurate :) 
09:44 < scavr> i don't know but guess not too accurate as may blocks are >1MB
09:44 < michaelfolkson> The average for the first few years must have been much lower than 1MB
09:44 < michaelfolkson> The start of IBD
09:45 < michaelfolkson> Today's blocks are consistently much bigger than 1MB, 1.6MB average?
09:46 < Kaizen_Kintsugi_> I'm surprised at this as-well, intuitively with my limited knowledge, I come to the conclusion that the average block size could be computed.
09:46 < svav> b10c: Were people having performance problems that made this PR necessary? When is it hoped that this PR will be implemented?
09:47 < b10c> agree with both of you, yes. It doen't matter for the early blocks and it's an OK assumption for the later blocks. Might leave us with one more or one fewer set of blk/rev dat files when IBD is done
09:47 < sipa> I mean, what counts as "performance problem"? Faster is always nicer, no?
09:47 < michaelfolkson> I think if the estimate was totally wrong e.g. 0.1 MB or 6 MB it would be a problem
09:47 < sipa> And certainly on some hardware IBD is painfully slow... hours to days to weeks sometimes
09:47 < b10c> It is totally wrong for regtest, signet and testnet
09:48 < michaelfolkson> Hmm but on the high side right
09:48 < michaelfolkson> So just a massive underestimate would be a problem?
09:49 < b10c> Kaizen: computing would be possible for sure, but this would probably be to complex here
09:49 -!- azor [~azor@201.208.224.235] has joined #bitcoin-core-pr-reviews
09:49 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Remote host closed the connection]
09:49 < michaelfolkson> So 0.1 MB would be a problem but 6MB wouldn't be a problem?
09:50 < michaelfolkson> Just less efficient
09:50 < b10c> e.g. on testnet you could finish IBD with only one pair of blk/rev files left when we prune just before we catch up with the tip
09:51 < b10c> as we assume the next blocks will all be 1MB each and make space for them
09:52 < michaelfolkson> So the pruning is too aggressive for testnet
09:52 < b10c> could maybe even be a problem if there is a big reorg on testnet as we can't reverse to a previous UTXO set state?
09:52 < b10c> michaelfolkson: yes, maybe. I need to think about this a bit more
09:53 < sipa> During IBD there shouldn't be reorgs in the first place.
09:53 < sipa> Which is presumably the justification why more aggressive pruning is acceptable there.
09:53 -!- shapleigh1842 [~shapleigh@96-92-170-77-static.hfc.comcastbusiness.net] has quit [Quit: Connection closed]
09:53 < b10c> I mean after
09:53 -!- shapleigh1842 [~shapleigh@96-92-170-77-static.hfc.comcastbusiness.net] has joined #bitcoin-core-pr-reviews
09:53 < sipa> Oh, oops.
09:54 < b10c> assume we just finished IBD with only a few blocks+undo data left on disk
09:54 < b10c> (you anwered question 7 :) )
09:54 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
09:55 < b10c> we do a headers first sync, so we don't download and blocks from stale chains
09:56 < b10c> (that's the answer to questions 7, let's do question 6 now):
09:56 < b10c> The PR description mentions IBD speed improvements for pruned nodes. What can we measure to benchmark the improvement? With which prune targets and dbcache sizes should we test?
09:56 < michaelfolkson> A non-zero very low probability of having to deal with re-orgs during IBD. Even lower probability with headers first sync
09:57 < michaelfolkson> (if someone provides wrong headers)
09:57 < scavr> ohh I didnt know about headers first sync. you mean once we have the longest chain we ignore forks in IBD?
09:58 < b10c> yes!
09:58 < sipa> even with headers-first sync we download blocks simultaneously with headers
09:58 < sipa> but we only fetch blocks along the path of what we currently know to be the best headers chain
09:58 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 240 seconds]
09:59 < sipa> and i'm not sure "probability" is the issue to discuss here; you can't *randomly* end up with an invalid headers chain if your peers are honest
09:59 < sipa> if you peers are dishonest however, it is possible, but that's a question of attack cost, not probability
09:59 < svav> To benchmark the improvement, can we measure IBD download time?
10:00 < michaelfolkson> The header has the PoW in it.. so massive attack cost :)
10:00 < b10c> svav: yes!
10:00 < shapleigh1842> We should measure / benchmark IBD sync time with low cost hardware and default dbcache and other settings
10:00 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
10:01 < b10c> yup, preferably with different prune targets (more important) and dbcache sizes
10:01 < shapleigh1842> yeah, well def with the minimum 550
10:02 < b10c> I'd assume this has a bigger effect for people pruning with larger prune targets
10:03 < b10c> since you still flush quite often with the 550 prune target, but if you can download 10GB and only need to flush (for pruning) once, that's a lot better than before
10:03 < sipa> It should mostly matter for people with large prune target and large dbcache, I think.
10:03 < b10c> Ok, time to wrap up! Thanks for joining, I wish everyone a happy new year.
10:04 < Kaizen_Kintsugi_> Thanks for hosting!
10:04 < b10c> #endmeeting
10:04 < shapleigh1842> happy new year!
10:04 < svav> Thanks b10c and all. Happy New Year all!
10:04 < Kaizen_Kintsugi_> Happy new year everyone.
10:04 < michaelfolkson> Thanks b10c and everyone!
10:04 < scavr> thanks b10c and sipa (for the additional knowledge drops)!
10:05 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
10:06 < azor> Thanx Happy New Year everyone
10:07 -!- azor [~azor@201.208.224.235] has quit [Quit: Connection closed]
10:09 -!- kuznechik [~kuznechik@cpe-184-153-102-43.nyc.res.rr.com] has quit [Quit: Connection closed]
10:10 -!- scavr [~scavr@2a02:908:166:3020:7be9:202c:ce68:4fdf] has quit [Remote host closed the connection]
10:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Remote host closed the connection]
10:15 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Ping timeout: 256 seconds]
10:18 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
10:23 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 252 seconds]
10:23 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
10:23 -!- shapleigh1842 [~shapleigh@96-92-170-77-static.hfc.comcastbusiness.net] has quit [Quit: Connection closed]
10:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 240 seconds]
10:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
10:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 240 seconds]
10:56 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has joined #bitcoin-core-pr-reviews
11:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:60de:eeb5:73ac:b58f] has quit [Ping timeout: 252 seconds]
11:02 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
11:16 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
11:16 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
11:25 -!- brunoerg [~brunoerg@187.183.47.88] has quit []
12:21 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:38 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Remote host closed the connection]
12:39 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
12:43 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Remote host closed the connection]
12:43 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
12:59 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Remote host closed the connection]
13:00 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
13:00 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
13:04 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Ping timeout: 250 seconds]
13:12 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
15:43 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Remote host closed the connection]
15:44 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
15:48 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Ping timeout: 260 seconds]
16:38 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
16:43 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Ping timeout: 268 seconds]
16:55 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
17:00 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Ping timeout: 252 seconds]
17:22 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d137-186-175-39.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
17:27 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d137-186-175-39.abhsia.telus.net] has quit [Ping timeout: 240 seconds]
17:57 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
18:03 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Ping timeout: 250 seconds]
18:23 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
18:28 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Ping timeout: 260 seconds]
18:56 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d137-186-175-39.abhsia.telus.net] has joined #bitcoin-core-pr-reviews
19:00 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@d137-186-175-39.abhsia.telus.net] has quit [Ping timeout: 240 seconds]
19:05 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
19:10 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Ping timeout: 252 seconds]
19:25 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
19:45 -!- jb55 [~jb55@user/jb55] has quit [Ping timeout: 268 seconds]
20:27 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Ping timeout: 268 seconds]
20:51 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
21:05 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4v7uscpmnqj4r.ipv6.telus.net] has quit [Ping timeout: 252 seconds]
21:16 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4t8cb8pars00v.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
21:21 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4t8cb8pars00v.ipv6.telus.net] has quit [Ping timeout: 260 seconds]
21:35 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4t8cb8pars00v.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
21:51 -!- jb55 [~jb55@user/jb55] has joined #bitcoin-core-pr-reviews
22:38 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4t8cb8pars00v.ipv6.telus.net] has quit [Ping timeout: 268 seconds]
23:08 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4t8cb8pars00v.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
23:13 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4t8cb8pars00v.ipv6.telus.net] has quit [Ping timeout: 250 seconds]
23:27 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@node-1w7jr9yi65te4t8cb8pars00v.ipv6.telus.net] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Dec 30 00:00:16 2021