--- Log opened Wed Jun 11 00:00:10 2025
00:09 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 260 seconds]
00:35 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
00:40 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
00:53 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
00:59 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 265 seconds]
01:14 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
01:29 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 272 seconds]
01:55 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
02:00 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
02:14 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
02:20 -!- bob_x1 [~bob_x@user/bob-x1/x-8934932] has quit [Quit: MirC]
02:22 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-pr-reviews
02:57 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
03:02 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 248 seconds]
03:32 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
03:37 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 244 seconds]
03:53 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
03:56 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
04:01 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 260 seconds]
04:11 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
04:38 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 248 seconds]
04:41 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
04:54 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
04:54 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
06:33 -!- robszarka [~szarka@2603:3003:4eac:100:29ca:6320:d90c:7c65] has quit [Quit: Leaving]
06:34 -!- szarka [~szarka@2603:3003:4eac:100:29ca:6320:d90c:7c65] has joined #bitcoin-core-pr-reviews
07:06 < marcofleon> review club in ~3 hours
07:20 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-pr-reviews
08:01 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
08:03 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Ping timeout: 268 seconds]
08:05 -!- ___nick___ [~quassel@82-132-215-128.dab.02.net] has quit [Ping timeout: 260 seconds]
08:05 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-pr-reviews
08:09 -!- ___nick___ [~quassel@82-132-212-221.dab.02.net] has joined #bitcoin-core-pr-reviews
08:20 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 276 seconds]
08:48 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
09:21 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 272 seconds]
09:22 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
09:29 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 276 seconds]
09:34 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
09:39 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-pr-reviews
09:58 -!- monlovesmango [~monlovesm@146.70.174.216] has joined #bitcoin-core-pr-reviews
10:00 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
10:00 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Client Quit]
10:00 < marcofleon> #startmeeting
10:00 < corebot`> marcofleon: Meeting started at 2025-06-11T17:00+0000
10:00 < corebot`> marcofleon: Current chairs: marcofleon
10:00 < corebot`> marcofleon: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
10:00 < corebot`> marcofleon: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
10:00 < corebot`> marcofleon: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
10:00 < sliv3r__> Hi!
10:01 < stickies-v> hi
10:01 < monlovesmango> heyy
10:01 < sipa> hi
10:01 < marcofleon> welcome! we'll be going over https://bitcoincore.reviews/30605
10:02 < marcofleon> litte re run of last week, we can actually go over the questions this time
10:02 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
10:02 < marcofleon> Did you review the PR/notes? Concept ACK, approach ACK, tested ACK, or NACK?
10:02 < stickies-v> didn't review, just lurking today
10:03 < marcofleon> lurkers are welcome
10:03 < sliv3r__> tried to :) was not an easy one
10:03 < monlovesmango> yes a bit. tested too.
10:03 < marcofleon> agreed, the cluster linearization code can be tough
10:04 < sipa> i hope the testing code for it is easier!
10:04 < marcofleon> monlovesmango: ran the fuzz tests? nice! I guess we can go over that a bit with question 4
10:04 < marcofleon> okay, let's dive in
10:04 < marcofleon> What are the two new fuzz targets introduced and what are they testing? In terms of what they’re testing, how are they different from the other targets?
10:05 < sliv3r__> clusterlin_simple_finder and clusterlin_simple_linearize
10:06 < sipa> ✔️
10:06 -!- Talkless [~Talkless@138.199.6.197] has joined #bitcoin-core-pr-reviews
10:06 < sliv3r__> here I have a question bc I though ones were testing the functionality and the other ones were testing the tests but when I checked the functions I saw that were just simpler re-implementations of the ones found in cluster_linearize.h
10:06 < sliv3r__> why is that?
10:07 < monlovesmango> clusterlin_simple_finder and clusterlin_simple_linearize. they are different than other targets bc they are fuzz testing functions implemented for fuzz tests
10:07 < sipa> sliv3r__: let me explain
10:07 < marcofleon> sliv3r__: That could be related to the next question actually
10:07 < marcofleon> in terms of what are the benefits of doing that
10:08 < sliv3r__> marcofleon: that could be the reason why I wrote IDK as an answer to the next one in my notes :)
10:08 < sipa> sliv3r__: the short answer is that SimpleCandidateFinder, ExhaustiveCandidateFinder, SimpleLinearize are part of the test suite, not of production code, even though they mimick the functionality of production code funcstions/classes
10:09 < sipa> the point is that the production code is complicated, which means it may be hard for reviewers to get confidence in their correctness
10:09 < sliv3r__> and how can we be sure that the behaviour is equal or at least equivalent?
10:10 < marcofleon> and so the simpler implementations provide an oracle to check against
10:10 < sipa> one tool that we (or i, as author, in this case) have available to make it easier on reviewers, is by writing a simpler, more obviously correct, but potentially slower/less feature-rich reimplementation that does the same thing, plus tests that they are identical
10:10 < sipa> so then if you as a reviewer have confidence in the reimplementation + the equivalence test, you also gain confidence in the original implementation
10:11 < sipa> sliv3r__: well that is what the fuzz tests do: run a scenario (controlled by the fuzzer) of operation to both the production version and the simpler version, and see they produce the same result
10:11 < sipa> that's not a proof of course, but it is one tool that can increase confidence if no such differences are found
10:11 < sliv3r__> make sense
10:11 < sipa> if you want to get an idea of how good it is, you can try inserting deliberate bugs and see how long it takes for the fuzzer to find it
10:11 < abubakarsadiq> hi
10:12 < marcofleon> abubakarsadiq: welcome
10:12 < sliv3r__> nice thanks, more clear now
10:12 < sipa> and in this case, even the "simpler" version is fairly nontrivial, so in addition, there is a third, *even* simpler and *even* slower version implemented
10:13 < marcofleon> i'll move on to question 4, unless there's more benefits other than increasing confidence of correctness? for question 3 I mean
10:13 < sipa> where the current fuzz tests compare all 3 with each other
10:13 < marcofleon> That's the exhaustive one yes?
10:13 < sipa> marcofleon: yeah
10:13 < monlovesmango> I think that makes sense for clusterlin_simple_finder bc it doesn't seem to compare with other prod code, but for clusterlin_simple_linearization it is comparing to ChunkLinearization which doesn't necessarily feel simpler
10:13 < sipa> marcofleon: there are 2 dimensions i think
10:14 < sipa> marcofleon: there is the candidate-finding logic, where we have SearchCandidateFinder (prod), SimpleCandidateFinder (simpler), ExhaustiveCandidateFinder (simplest)
10:14 < sipa> and there is the linearization logic on top, where there are also 3 version: Linearize (prod), SimpleLinearize (simpler), and the std::next_permutation based exhaustive search (simplest, but not a separate function)
10:15 < abubakarsadiq> sipa: haven't look yet, but after SFL simple candidate finder would be changed to match the new algorithm yeah?
10:16 < sipa> abubakarsadiq: there is no SearchCandidateFinder anymore post-SFL; SFL is a replacement for Linearize directly, which doesn't involve candidate finding anymore
10:16 < marcofleon> So building layers of trust essentially, makes sense
10:16 < sipa> SimpleCandidateFinder and ExhaustiveCandidateFinder stay, but they're just used in/for SimpleLinearize, which the SFL-based Linearize is then compared against
10:16 < sipa> kind of vestigial
10:17 < abubakarsadiq> So we will use exhaustive search to validate correctness of SFL?
10:17 < sipa> that would be a possibility!
10:17 < marcofleon> monlovesmango if you ran the fuzz tests a bit, question 4: Were you able to run the clusterlin_linearize target? How many iterations (the first number libFuzzer shows at each line) did it take to produce a crash after making the s/chunking/simple_chunking/ change?
10:17 < monlovesmango> sipa: ok std::next_permutation was what I was missing
10:17 < sipa> abubakarsadiq: but i don't think it gains us very much, as it's pretty non-trivial anyway, so the "added confidence" isn't as much as compared with the much simpler reimplementations gives us
10:17 < abubakarsadiq> Or the permutation of the graph linearizations I think will be more valid candidate 
10:17 < monlovesmango> marcofleon: I actually had a question about that. I did get the failure, but I was using the python test runner and it doesn't show any output with the counts, just the error
10:18 < sliv3r__> marcofleon: it took for me 566593 iteartions
10:18 < monlovesmango> is there another way I should be running individual tests?
10:18 < sipa> i always run the tests individually
10:18 < sliv3r__> I did it running: FUZZ=clusterlin_linearize build_fuzz_nosan/bin/fuzz
10:18 < sipa> that ^
10:19 < marcofleon> exactly, yeah
10:19 < monlovesmango> sliv3r__: ok that helps thank you :)
10:19 < sipa> i usually add -use_value_profile=1 -workers=30 -jobs=30, to get 30 concurrent processes, with more tendency to explore more paths
10:19 < marcofleon> and yeah ~500k iterations was where i was at too. It crashes pretty quickly
10:19 < sliv3r__> monlovesmango: in the fuzzing docs you have an example at the very begining https://github.com/bitcoin/bitcoin/blob/master/doc/fuzzing.md
10:20 < marcofleon> And then running it like how sliv3r__ said you can add a directory at the end to save the inputs if you'd like. Keep a corpus for later
10:20 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
10:20 < sliv3r__> marcofleon: Then it says something like: Test unit written to ./crash-1cea6b51b877d277ba4d1ba7f522b7d3ac182349
10:20 < sliv3r__> what's that? bc it's impossible to human-read it :)
10:20 < sipa> marcofleon: maybe it makes sense to move the std::next_permutation based logic to an ExhaustiveLinearize function
10:21 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
10:21 < marcofleon> sipa: it could make it clearer, agreed
10:21 < marcofleon> sliv3r__: that's the input that caused the crash
10:21 < sipa> sliv3r__: it is the input to the fuzz harness, which interprets bytes from it (each of the provider.ConsumeIntegral... functions decodes some bytes from it)
10:22 < marcofleon> if you run the fuzz command and that input after, it should reproduce, hopefully
10:22 < sipa> you can re-run it, using FUZZ=clusterlin_linearize build_fuzz_nosan/bin/fuzz ./crash-1cea6b51b877d277ba4d1ba7f522b7d3ac182349
10:22 < sipa> which will not do any fuzzing, just run that one fuzz input through the harness
10:22 < monlovesmango> sipa: I think ExhaustiveLinearize would be good and consistent
10:22 < sliv3r__> yep runs one iteration and crashes instantly
10:23 < sipa> but now you can also modify the code, attempt to fix the bug, and retry with just that case
10:23 < marcofleon> that's when the debugging starts
10:23 < marcofleon> question 5: In commit 2763b75, why was --iterations_left moved?
10:23 < monlovesmango> sliv3r__: thank you I see that example now... I think I didn't really know what that param did bc I didn't realize 'process_message' was a test
10:24 < marcofleon> monlovesmango: sorry if I moved on too quickly! Yeah, the thing after FUZZ= is the fuzz target
10:24 < monlovesmango> marcofleon: no you're good!
10:24 < sliv3r__> sipa: right setting it back to chunking works :P
10:24 < sliv3r__> are we at q 5?
10:25 < marcofleon> we have a bunch of them. all looking something like "FUZZ_TARGET(clusterlin_depgraph_sim)" for example and then the test itself
10:25 < marcofleon> yeah, i'll paste again
10:25 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 265 seconds]
10:25 < marcofleon> In commit 2763b75, why was --iterations_left moved?
10:25 < monlovesmango> it was moved bc otherwise it decrements for splits that don't actually need to be considered (which I imagine might also mess with the result being optimal assumption)
10:26 < sipa> i think the answer here is kind of nuanced
10:27 < marcofleon> I'm actually not sure if it was a bug fix per se... I think just an optimization?
10:27 < sipa> but it also doesn't matter much
10:27 < sliv3r__> If I didn't understand wrong we want to only reduce the counter when we add a new "valid" subset. So the number of iterations is proportional to the number of different connected subsets that cna be created instead to be realted to the total num of elements in the queue
10:27 < sipa> so the idea is that we want some kind of "cost metric" to control how much time is spent inside SimpleCandidateFinder, just so that it does not run forever, but can stop it after "too much" work has been performed
10:28 < sipa> it doesn't really matter what that metric is, as long as it's roughly proportional to runtime
10:28 < sipa> the metric that was being used so far was "queue elements processed"
10:28 < sipa> moving the --iterations_left is really changing the metric to something else: the number of candidate sets considered
10:29 < monlovesmango> interesting
10:29 < sipa> they're very similar, but each candidate set being considered can give rise to two queue elements
10:29 < sipa> and there is an initial queue element on the stack that's not a candidate set
10:29 < sipa> so the old metric is at most 2*N+1, where N is the new metric
10:30 < marcofleon> In clusterlin_simple_finder, when finding a topologically valid subset to remove from the graph, why is it important to set non_empty to true? What could happen if we allowed empty sets?
10:30 < sliv3r__> infinite loop
10:30 < sipa> so why change is: the new one is easier to reason about, because it's easy to count how many candidate sets a cluster can have (2^(N-1))
10:31 < sipa> so that's something that can be concretely tested for: if the limit is set to at least 2^(N-1), the optimal must be found
10:31 -!- kevkevin [~kevkevin@142.147.59.145] has joined #bitcoin-core-pr-reviews
10:31 < sipa> makes sense?
10:32 < monlovesmango> seems like a better metric. yes.
10:32 < sipa> it's not a big change, just making things slightly easier to reason about
10:32 < sliv3r__> it makes more sense
10:32 < sipa> but the most important thing is that there is some metric, and it's being hit
10:33 < marcofleon> sure, I do thiink it makes sense to have it be only when a valid transaction is found
10:33 < marcofleon> a better metric, then just next in the queue
10:34 < marcofleon> *than
10:34 < sipa> *candidate set, not transaction
10:34 < marcofleon> valid set, sorry yeah
10:35 < abubakarsadiq> We have to find something to remove in the prior commit we evict the found transactions when the it's empty 
10:35 < abubakarsadiq> infinite loop if we don't remove anything 
10:35 < marcofleon> for q6, nice yeah
10:36 < sliv3r__> yeah so basically we have an empty one the next iteration is equal to the current one so loop loop loop :)
10:36 < marcofleon> it would just be the same set if nothing is removed
10:36 < sliv3r__> if we have*
10:36 < sipa> abubakarsadiq: (bonus) how likely would it be that we *keep* removing nothing, because just occasionally not removing anything wouldn't be an infinite loop?
10:38 < abubakarsadiq> Yeah highly unlikely 
10:38 < sipa> actually no, extremely likely :p
10:38 < sliv3r__> I'm lost haha
10:38 < sipa> it would happen anytime you hit the end of the fuzz input
10:38 < sipa> because once you hit the end, ConsumeIntegral and friends will keep forever returning 0
10:38 < sipa> which would be interpreted as the empty set
10:39 < sipa> fuzz input is **not** random
10:39 < marcofleon> oh yes of course, there'd be no more data from the provider at some point
10:39 < sipa> it's hopefully better than random, but it can also be a lot worse
10:40 < sipa> abubakarsadiq: sorry, that was a trick question :)
10:40 < marcofleon> In clusterlin_simple_linearize, why does the code only verify against all possible permutations when depgraph.TxCount() <= 8? What would happen if we tried to do this for larger transaction counts?
10:40 < monlovesmango> very thought provoking trick question
10:41 < monlovesmango> the exhaustive search would start taking too long
10:41 < sliv3r__> I think I can answer for TxCount <= 7 bc I don't understand the optimization included in cce29ef63ecf114003b529093fdfd2574b830afc
10:41 < abubakarsadiq> was wondering the reason you choose to evict randomly. For testing weird and all kind of behaviors yeah. Because the found txs can also be the read transaction 
10:41 < abubakarsadiq> sipa: it's okay I learn something :P
10:42 < marcofleon> We can throw in the next question, it's related. In commit 1e4f345, when a non-topological permutation is found, the code now fast forwards by reversing part of the permutation. Why does this optimization work, and how many permutations can it skip in the best case?
10:42 < sliv3r__> So basically the cost would be huge as the possible permutations is N!. For 7 would be 5050 and higher numbers increase the number heavily
10:42 < marcofleon> i tried with 9 and the execs/sec were about 4x slower
10:43 < sliv3r__> But with 1e4f345 the worst case still being 8! which is huge right? Why is this acceptable if it wasn't before? (bc we had 7)
10:43 < sipa> yeah, that's the answer... the number of iterations can grow factorially
10:44 < sipa> sliv3r__: just 8! = 40320, that's not enormous
10:44 < sipa> fuzz tests work best when they stay above 100-1000 attempts per second
10:44 < sliv3r__> why was it 7 before if 8 is ok?
10:44 < sipa> hmm?
10:45 < sipa> oh, with the optimization there are just fewer permutations searched through
10:45 < marcofleon> The optimization of skipping all invalid permutations makes it possible to bump up 
10:45 < marcofleon> sorry, i should be more specific
10:45 < sipa> it's not actually possible for all 8! permutations to be topological, so many/most of them will be skipped by the optimization
10:46 < sipa> and the numbers 7 and 8 are just set based on benchmarks... which ones make the test too slow 
10:46 < marcofleon> all the permutations, after having found an invalid prefix yes?
10:46 < sipa> yes, it'll skip all the permutations with the *same* invalid prefix
10:46 < sliv3r__> oh ok so there's no "human logic" to that :) I was getting too picky with the numbers
10:47 < abubakarsadiq> It's human logic :p
10:47 < sipa> so the number of permutations tried is equal to the number of topologically-valid ones, plus the number of topologically-invalid minimal prefixes
10:47 < sipa> i don't have numbers for what those are, it just works in practice (TM)
10:47 < marcofleon> and how many permutations can it skip in the best case then, just to complete the question
10:48 < marcofleon> also sipa: did you ever figure out how many permutations can be tried in total knowing that there are K valid ones?
10:48 < sipa> marcofleon: i have not
10:48 < abubakarsadiq> Depends on the cluster 
10:48 < marcofleon> ^ that's what i was thinking too
10:48 < sipa> i thought it'd be easy to find a formula, but it does not seem simple at all
10:48 < sipa> after some experimentation
10:49 < sipa> but it skips a lot in practice, which is enough :p
10:49 < monlovesmango> 7! ?
10:49 < sliv3r__> sipa: why is not possible for all 8! permutations be topological?
10:49 < sipa> sliv3r__: that would imply there are no dependencies in the cluster, so it isn't a cluster
10:49 < marcofleon> monlovesmango: basically yeah, although I think you would subtract one from that
10:49 < sliv3r__> oh ok that was a stupid question :P
10:50 < sipa> sliv3r__: every dependency is a "parent must come before child in topological orderings" constraint, so easy additional dependency reduces the number of valid ones
10:50 < monlovesmango> whats the minus 1 for?
10:50 < sipa> by how much depends on the topology
10:50 < marcofleon> (n-1)! - 1 for n txs
10:51 < sipa> you skip from the first topologically-invalid order with a given prefix to the last one with the same prefix
10:51 < marcofleon> the -1 is the one tx that you did just try
10:51 < sipa> you don't immediately skip to the next prefix
10:51 < monlovesmango> marcofleon: makes sense thanks!
10:52 < sipa> i think we never answered question 3?
10:52 < marcofleon> What are the benefits of separating out the fuzzing of the internal test helpers?
10:52 < marcofleon> I thought we touched on it, but that's true, never explicitly answered
10:53 < monlovesmango> oh also I was able to test the fuzz crash and got 340233
10:53 < marcofleon> nice. I love fuzz crashes
10:53 < sliv3r__> 😂
10:53 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
10:53 < sipa> marcofleon: fwiw, i suspect the vast majority of the fuzz crashes in these PRs happen before the PR is opened
10:53 < monlovesmango> I think it help instill confidence on what is actually being tested
10:53 < sipa> as in, i use them to help development
10:54 < sipa> monlovesmango: maybe, but nothing really changes there... take Search/Simple/ExhaustiveCandidateFinder... before we had one fuzz test that compared all three (subject to cluster-not-too-large constraints etc)
10:54 < sipa> now we have two tests, one comparing Search with Simple, one comparing Simple with Exhaustive
10:55 < sipa> what's the benefit of the split?
10:55 < sliv3r__> Avoid redundancy
10:55 < sipa> yes!
10:55 < monlovesmango> yes for me thats much easier to reason about and so for me I can be more confident in comparing Search with Simple
10:55 < marcofleon> sipa: makes sense, it's a fairly easy and quick way to help initial bugs surface
10:55 < sliv3r__> and also easier to review the code
10:55 < sipa> if you're already confident in SimpleCandidateFinder, you have no "need" to waste computation effort on running the Simple/Exhaustive comparison too
10:56 < sipa> if you're not, you should be focusing on just establishing that confidence first without putting effort into comparing with the production code
10:56 < sipa> (whether that means more review, running fuzz tests, attending a review club, ...)
10:57 < sipa> so i feel the goals of what you obtain from these tests is different, and it makes sense to separate them for that reason
10:57 < marcofleon> Yeah, I think it's good to have the separate targets here
10:57 < sipa> but yes, clearer code too :0
10:58 < sipa> i will need to drop off now, but thanks for hosting marcofleon, and thanks all for spending time looking at my PR!
10:58 < sliv3r__> thanks for the explanations :)
10:58 < monlovesmango> thanks sipa!
10:58 < marcofleon> thanks for all your help sipa
10:58 < abubakarsadiq>  thanks for hosting, thanks for your work sipa
10:58 < marcofleon> okay let's jump into SFL then?
10:59 < marcofleon> :P
10:59 < abubakarsadiq> We have txgraph reorg waiting though 
10:59 < marcofleon> another day. Thanks for attending everybody
10:59 < abubakarsadiq> It's also juicy
10:59 < marcofleon> oh yeah I kinda forgot about that one, good call
10:59 < sliv3r__> Could you guys share the answer for the last-1 question? Didn't get a clear answer of that
11:00 < monlovesmango> I think for last question inc and und are not complementary
11:01 < sliv3r__> My idea checking the algorithm was that for inclusion if you don't have inc you may try to add a tx without an ancestor being in the anc set
11:01 < marcofleon> sure, maybe Abubakar has a clearer way to look at it, but I sort of initially thought that it was possible to get the inc with only having und
11:02 < marcofleon> but then I realized that in order to keep track of feerate, you would need inc I believe
11:03 < sipa> it's really a tristate: undecided, included (definitely in the candidate set), excluded (definitely not in the candidate set)
11:03 < monlovesmango> one of the sets that you add back to the queue has und - descendants(split), so I don't know how you would figure out inc from that queue set
11:03 < sipa> excluded is just implicitly everything not included and not undecided
11:04 < monlovesmango> tristate is a good way of phrasing it
11:05 < marcofleon> could you implicitly have something like included = m_todo - undecided - excluded?
11:07 < monlovesmango> would that be better? I'm not sure
11:08 < marcofleon> No probably not, that's just what prompted the question for me. Better to keep track of included explicitly
11:09 < sliv3r__> I think keeping inc explicitly is needed bc tx have dependencies between them, not explicitly knowing what is inc may cause you try to add a tx without some ancestor in the inc
11:11 < marcofleon> Right that makes sense
11:11 < marcofleon> still learning a lot about the clusterlin stuff, it's not easy
11:11 < sliv3r__> no it's not, this was first time I read about it and also about fuzz, too many new things in one pr :)
11:12 < marcofleon> sliv3r__ i saw your question on the PR and I believe smallest set breaks the tie
11:12 < marcofleon> And that's good to know actually, I'll keep that mind. I did realize this review club was trying to do two things at once, which didn't help
11:13 < sliv3r__> marcofleon: if that's the case would it make sense to assert the size?
11:13 < monlovesmango> this is my second fuzz pr review and still learning... haha
11:13 < sliv3r__> marcofleon: nono it was great :) double knowledge
11:14 < monlovesmango> sliv3r__: yes agree
11:15 < marcofleon> fuzzing is awesome, it's a great tool
11:16 < sliv3r__> Last question answer was: just release the code and let users complain and say that Core introduces bugs right (as it's the new tred saying that)? :P
11:16 < marcofleon> sliv3r__ I at least know in cluster_linearize.h FindCandidateSet says smallest set is the tiebreaker
11:17 < marcofleon> oh yeah haha q10 What is, no doubt, the coolest way to test code?
11:18 < sliv3r__> marcofleon: Yeah I saw the comment in the code. Just added a line in my prev comment so sipa can see it and say
11:19 < marcofleon> glad you two were able to fuzz it a bit. But yeah monlovesmango I recommend doing the indivdual targets like how we said earlier. The test runner is fine for running through a corpus of inputs once
11:19 < monlovesmango> yeah I agree its much better. I learned a lot more about fuzz best practices
11:20 < monlovesmango> thank you all for walking me through that :)
11:20 < sliv3r__> me too this was actually really usefull
11:20 < marcofleon> Glad to hear it. Okay that's it for me. Thanks again for coming, see you both soon!
11:20 < sliv3r__> Thanks for hosting!
11:21 < monlovesmango> thanks for hosting marcofleon !! was a good one
11:22 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
11:26 < sliv3r__> marcofleon: I think you forgot to end the meeting ;)
11:27 < marcofleon> #endmeeting
11:27 < corebot`> marcofleon: Meeting ended at 2025-06-11T18:27+0000
11:27 < corebot`> marcofleon: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-pr-reviews.2025-06-11_17_00.log.json
11:27 < corebot`> marcofleon: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-pr-reviews.2025-06-11_17_00.log.html
11:27 < marcofleon> hahaha thanks!
11:27 < corebot`> marcofleon: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-pr-reviews.2025-06-11_17_00.html
11:28 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has quit [Read error: Connection reset by peer]
11:29 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has joined #bitcoin-core-pr-reviews
11:30 -!- Guest2269 [~a@89.147.108.12] has joined #bitcoin-core-pr-reviews
11:30 -!- Guest2269 [~a@89.147.108.12] has quit [Client Quit]
11:35 -!- monlovesmango [~monlovesm@146.70.174.216] has quit [Quit: leaving]
11:35 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
11:45 -!- rmatte_ [rmatte@2600:3c00::f03c:93ff:fe7b:d29c] has left #bitcoin-core-pr-reviews [Bye]
12:24 -!- kevkevin [~kevkevin@142.147.59.145] has quit [Remote host closed the connection]
12:27 -!- Talkless [~Talkless@138.199.6.197] has quit [Quit: Konversation terminated!]
12:28 -!- ___nick___ [~quassel@82-132-212-221.dab.02.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
12:39 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
12:52 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-pr-reviews
13:22 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: Textual IRC Client: www.textualapp.com]
13:48 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-pr-reviews
14:16 -!- hello485 [~hello485@user/hello485] has quit [Ping timeout: 260 seconds]
14:51 -!- l0rinc [~l0rinc@user/l0rinc] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
16:27 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
16:33 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 244 seconds]
19:03 -!- TheRec [~toto@user/therec] has quit []
20:57 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
21:23 -!- robszarka [~szarka@2603:3003:4eac:100:3c4d:a401:db8b:2324] has joined #bitcoin-core-pr-reviews
21:26 -!- szarka [~szarka@2603:3003:4eac:100:29ca:6320:d90c:7c65] has quit [Ping timeout: 260 seconds]
21:28 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
21:50 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
22:21 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
22:31 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 272 seconds]
23:02 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
23:15 -!- sr_gi[m]1 [~srgimatri@2620:6e:a000:ce11::2a] has quit [Ping timeout: 268 seconds]
23:15 -!- BlueMattMtrxBot [~bluemattm@2620:6e:a000:ce11::44] has quit [Ping timeout: 260 seconds]
23:16 -!- laanwj [~laanwj@user/laanwj] has quit [Ping timeout: 276 seconds]
23:20 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
23:25 -!- Netsplit *.net <-> *.split quits: schmidty, jkczyz
23:30 -!- laanwj [~laanwj@user/laanwj] has joined #bitcoin-core-pr-reviews
23:30 -!- sr_gi[m]1 [~srgimatri@2620:6e:a000:ce11::2a] has joined #bitcoin-core-pr-reviews
23:30 -!- Netsplit over, joins: jkczyz, schmidty
23:36 -!- BlueMattMtrxBot [~bluemattm@2620:6e:a000:ce11::44] has joined #bitcoin-core-pr-reviews
23:46 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Jun 12 00:00:10 2025