--- Log opened Wed Apr 16 00:00:21 2025
02:40 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Quit: PaperSword]
02:46 -!- S3RK [~S3RK@user/s3rk] has joined #bitcoin-core-pr-reviews
02:49 -!- S3RK_ [~S3RK@user/s3rk] has quit [Ping timeout: 245 seconds]
03:04 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
03:43 -!- edouardparis [~m-f4c6gr@user/edouardparis] has joined #bitcoin-core-pr-reviews
03:57 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
05:45 -!- pablomartin [~pablomart@91.196.223.71] has joined #bitcoin-core-pr-reviews
05:45 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
05:49 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 260 seconds]
06:31 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
06:59 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
07:45 -!- pablomartin [~pablomart@91.196.223.71] has quit [Ping timeout: 244 seconds]
07:54 -!- kevkevin_ [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
07:54 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Read error: Connection reset by peer]
08:12 -!- pablomartin [~pablomart@91.196.223.65] has joined #bitcoin-core-pr-reviews
08:37 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Quit: PaperSword]
09:52 < glozow> hi
09:54 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:56 -!- pablomartin [~pablomart@91.196.223.65] has quit [Ping timeout: 244 seconds]
09:58 -!- Murch[m] [~murch@user/murch] has changed host
09:58 < Murch[m]> Hey
09:59 -!- monlovesmango [~monlovesm@146.70.174.222] has joined #bitcoin-core-pr-reviews
10:00 < Murch[m]> #startmeeting
10:00 < Murch[m]> Hello everyone, welcome to the bitcoin core PR review club.
10:00 < sipa> hi
10:00 < Murch[m]> Thanks for joining us
10:00 < glozow> hi
10:00 < monlovesmango> hi
10:00 -!- pyth [~pyth@user/pyth] has quit [Quit: Leaving]
10:00 < kevkevin_> hi
10:00 < Murch[m]> Today we are looking at #29532, which is one of my PRs
10:01 -!- stringintech [~stringint@2602:fa59:3:451::1] has joined #bitcoin-core-pr-reviews
10:01 < Murch[m]> Is there anyone here for the first time? Feel free to jump in regardless!
10:01 < Murch[m]> Who got the chance to review the PR or read the notes? (y/n)
10:01 < monlovesmango> y
10:02 < Murch[m]> If you reviewed the PR, what was your conclusion?
10:02 < stringintech> y
10:02 < monlovesmango> looks good to me
10:02 -!- Santos [~Santos@32.141.102.6] has joined #bitcoin-core-pr-reviews
10:02 < kevkevin_> n
10:02 < Murch[m]> How did you approach the review?
10:03 < Murch[m]> Alright, let’s get to the meat of it
10:03 < Murch[m]> What are the four coin selection algorithms used by Bitcoin Core? In a sentence, how do they differ?
10:03 < monlovesmango> read some of the background, then reviewed commit by commit as suggested. was pretty easy to follow that way. I also rebased onto master
10:04 -!- Santos [~Santos@32.141.102.6] has quit [Client Quit]
10:04 < Murch[m]> monlovesmango: Cool, glad to hear that
10:04 -!- Santos [~Santos@32.141.102.6] has joined #bitcoin-core-pr-reviews
10:04 < glozow> monlovesmango: what is your approach to reviewing refactoring commits?
10:06 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-pr-reviews
10:06 < Santos> ACK. Reviewed commit by commit and reviewed the coin control logic/BNB algorithm
10:06 < monlovesmango> well since this was well structured I was first reading through the tests that were removed, and then looked for the same functionality on the tests that were added
10:07 < Murch[m]> So regarding the algorithms, BnB is the only algorithm that will only return changeless input sets (except Knapsack which does it only when the excess is exactly 0).
10:08 < Murch[m]> This means that a few of the scenarios that BnB should be tested against are unique to BnB.
10:09 < monlovesmango> knapsack does 1000 random walks while remembering its best selection (overshoots target the least), selection must be between the target and target+minChange
10:09 < Murch[m]> monlovesmango: Yeah, that’s right
10:09 < monlovesmango> single random draw will randomly pick coins until target+minChange is exceede
10:10 < monlovesmango> d
10:10 < Murch[m]> correct
10:10 -!- dzxzg38 [~dzxzg@user/dzxzg] has joined #bitcoin-core-pr-reviews
10:11 < monlovesmango> coingrinder seems to be similar to BnB, except it finds the input set with the lowest weight that exceeds target+minChange (also disabled below 30s/vB)
10:12 < monlovesmango> and BnB looks to find the least wasteful input set that doesn't have a change output
10:12 < Murch[m]> monlovesmango: Exactly, they are both branch and bound algorithms that deterministically iterate through all possible relevant combinations
10:12 -!- stringintech [~stringint@2602:fa59:3:451::1] has quit [Quit: Ping timeout (120 seconds)]
10:13 < monlovesmango> I did have a question, what is SFFO?
10:13 < Murch[m]> 4 of 4, monlovesmango 
10:13 -!- dzxzg [~dzxzg@user/dzxzg] has quit [Ping timeout: 240 seconds]
10:13 < Murch[m]> SFFO stands for subtract_fee_from_output
10:13 < Murch[m]> It’s a way to pawn the transaction fee off on the recipient
10:13 -!- stringintech [~stringint@5.120.213.57] has joined #bitcoin-core-pr-reviews
10:13 < monlovesmango> ok thank you!
10:13 < Murch[m]> It’s the source of most bugs in coin selection :p
10:14 < Murch[m]> Let’s move to the next question: One important concept in the context is the "effective_value" of a UTXO. What is that? How is it calculated?
10:14 < monlovesmango> haha i can believe that
10:14 < Murch[m]> monlovesmango: The problem is that it turns a few general ideas on its head and it is often forgotten in testing when new functionality is added
10:14 < dzxzg38> https://github.com/bitcoin/bitcoin/blob/cdc32994feadf3f15df3cfac5baae36b4b011462/src/wallet/coinselection.h#L30-L31
10:14 < dzxzg38>  "The output's value minus fees required to spend it and bump its unconfirmed ancestors to the target feerate. "
10:15 < Murch[m]> dzxzg38: Yeah, that’s right
10:15 < Santos> effective_value = txout.nValue - fee
10:15 < stringintech> it is the actual spendable amount (after excluding required fee to spend it)
10:15 < monlovesmango> I believe it is the value of the input prev out minuse fees required to spend
10:15 < Santos> Effective Value = UTXO's Nominal Value − Fee to Spend the UTXO
10:15 < Murch[m]> Santos, stringintech, monlovesmango : also right
10:16 < Murch[m]> So, the effective_value is useful, because it gives us the amount that an input contributes toward the selection target after paying for itself
10:17 < Murch[m]> Before we introduced the concept, the selection target would shift with every input that got added, because the cost of the input needed to be added to the target
10:17 < Murch[m]> It made the problem multivariable and much harder to solve
10:17 < Murch[m]> Now the bonus question: if all the algorithms provide separate candidate input sets, how does the transaction building process pick among the candidates the one to use to build the transaction?
10:18 < Santos> It picks the one with the lowest "waste".
10:18 < Murch[m]> Aye, we use the waste score to pick the "best" one.
10:19 < Murch[m]> For a rather primitive fitness function, it works kinda okay
10:19 < Murch[m]> One day, we shoudl have a function that considers more things, like privacy, the wallet’s utxo composition and the wallet’s usage pattern, but that  are dreams for the future
10:19 < Murch[m]> Why might have so many of the original tests used a feerate of 0 ṩ/vB? How does the AddCoins(…) function in the new test suite address the same concern?
10:21 < monlovesmango> I think it was probably bc of the problem you just mentioned, if there was a fee the selection target would shift with every input that gets added
10:21 < Murch[m]> monlovesmango: You are thinking in the right direction
10:21 < Murch[m]> https://github.com/bitcoin-core-review-club/bitcoin/commit/9773192b833fe0d0e071b0a75f72aab82cb124ef#diff-36088c93368e137d955348aba223985bd4f198f2aaecd626c830f4612ca884c8R56-R62
10:22 < monlovesmango> AddCoins function seems to account for this by assigning the value to be the amount+fees
10:22 < Murch[m]> What is the "coins" parameter in the AddCoins function?
10:22 < Murch[m]> bingo
10:23 < Murch[m]> In the old tests, the AddCoins function generated a UTXO with the amount that was provided. In the new tests, the AddCoins function adds the input’s fees, so that the provided value becomes the UTXO’s effective_value
10:23 < stringintech> zero feerate was to make things easier by considering "effective value = actual value" I guess
10:23 < stringintech> and AddCoins is supposed to do the effective value calculation for us base on configured feerates
10:23 < Murch[m]> stringintech: Right on the money
10:24 < Murch[m]> Unprepared question: why is it a problem to use a feerate of 0?
10:24 < Santos> It seems to me that the zero feerate was used to avoid change complexity in those tests
10:25 < Murch[m]> Santos: What do you mean with "change complexity"?
10:26 < Santos> "why is it a problem to use a feerate of 0?" The tests should cover all cases (preferably close to real scenarios) - not only the zero feerate case
10:27 < Murch[m]> Santos:  yeah, absolutely
10:27 < Murch[m]> Additionally, there are a few quirks that come out at feerates of 0, because it means that inputs and outputs cost 0
10:27 < stringintech> not sure if this is the answer but in some scenarios we need to test the algorithm sensitivity (like bnb) to different feerates. and we have to change the feerate
10:27 < Santos> What do you mean with "change complexity"? Without fees, change calculations are less complicated, allowing tests to verify coin selection predictably
10:28 < monlovesmango> 0 fee rate is unrealistic. also the behavior of BnB search is partially dependent on fee values so its probably better to have fees as part of the tests..?
10:28 < Murch[m]> Santos:  Ah, I see what you mean. Yeah, by avoiding fees, you can easily calculate the change from the input amounts and recipient amounts
10:28 < Murch[m]> stringintech: that’s part of it! Although the old tests did have some where a feerate was set
10:29 < Murch[m]> But generally, transactions with feerates below 1 sat/vB are non-standard (with the new exception of parent TRUC transaction now)
10:29 < monlovesmango> Murch: do you plan to allow any tests to have 0 fee rate?
10:29 < Murch[m]> monlovesmango: yeah, that’s right
10:29 < Murch[m]> monlovesmango: Yes, we should have a couple that test this edge case
10:30 < Murch[m]> Because transactions at 0-fee are permitted, just non-standard
10:30 < monlovesmango> got it
10:30 < monlovesmango> thanks!
10:30 < Murch[m]> now that you say that, this may be a regression in the test, because I’m not sure I have any for BnB right now
10:30 < Murch[m]> So this edge case was tested before, but might not be at the moment
10:31 < Murch[m]> monlovesmango: You could leave a comment on the PR to that effect
10:31 < Murch[m]> Whhat are the advantages and disadvantages of using a helper function like TestBnBSuccess(…)?
10:31 < monlovesmango> yeah will do!
10:31 < Murch[m]> https://github.com/bitcoin-core-review-club/bitcoin/commit/66200b3ffa21605fc3234ccbda7b424381f3319a#diff-36088c93368e137d955348aba223985bd4f198f2aaecd626c830f4612ca884c8R94-R108
10:32 < Murch[m]> Thanks :)
10:32 < monlovesmango> It is a lot cleaner with less boilerplate, but every scenario needs to be completely/explicitly spec'ed out
10:32 < Santos> Code reuse (common test code is centralized) and consistency (all tests for BnB share the same validation logic)
10:32 < dzxzg38> The advantage is reuse, and one disadvantage is that your test failure happens far away from the interesting and invidual details of the test case that fails
10:33 < dzxzg38> (mitigated in this case by logging)
10:33 < monlovesmango> yeah consistency is also much improved
10:33 < Murch[m]> monlovesmango: Could you elaborate on "every scenario needs to be completely/explicitly spec'ed out"?
10:34 < Murch[m]> dzxzg38: Yeah, that was a big one on my list too: When you have a function that runs the checks, any failure will show up with the line number in the helper function! So you need additional information to figure out which test actually failed
10:35 < dzxzg38> I understood monlovesmango to mean generally that every test case needs to have at least as many "parameters" as the most complicated test case, even if you don't really care about some of the parameters in some of the cases
10:36 < Murch[m]> dzxzg38: Aha, the helper function might get pretty loaded with parameters
10:36 < monlovesmango> some of the simplier tests didn't necesarily need some of the additional parameters in TestBnBSuccess, but now they also need to account for these parameters
10:36 < Murch[m]> Although if we pick the order  carefully, we can use the defaults often and don’t have to state most explicitly
10:36 < monlovesmango> dzxzg38: yes you explained it better than me :)
10:36 < Murch[m]> monlovesmango:  Right, gotcha
10:37 < Murch[m]> monlovesmango: My thinking in that regard was that the boiler plate always writes out the entire test, so it’s often hard to see between two tests what the unique changes are.
10:37 < Murch[m]> By making each test a single line and having defaults for most things, you can very easily see which values diverge from the defaults and it helps you get a sense what the test is about
10:37 < monlovesmango> yes I totally agree with your approach
10:38 < monlovesmango> its much easier to comprehend
10:38 < Santos> Yes, I agree too
10:38 < monlovesmango> its just the only disadvantage I could think of
10:38 < Murch[m]> I do agree that we might need to explicitly define more parameters for some tests, though, e.g., when the custom_spending_vsize is changed, we of course have to give all the prior as well
10:38 < Murch[m]> Cool, let’s move on
10:39 < Murch[m]> How does test: Move BnB feerate sensitivity tests extend the coverage over the original tests?
10:39 < Murch[m]> https://github.com/bitcoin-core-review-club/bitcoin/commit/afd4b807ff1300e4f74ceab6a683f3ff1376369d
10:39 < monlovesmango> it add test to cover heavy txs, in low fee environment heavy txs should be preferred, and in high fee env lighter txs should be preferred
10:40 < Murch[m]> monlovesmango: Right!
10:40 < Murch[m]> In the old tests, more weight was only a function of the count of inputs, but in the new tests, we additionally vary the weight via the "output type"
10:41 -!- Santos [~Santos@32.141.102.6] has quit [Quit: Client closed]
10:41 < Murch[m]> What does the “clone skipping test” test?
10:41 < Murch[m]> https://github.com/bitcoin-core-review-club/bitcoin/commit/9d7db26b7b556784c16e41572ba2d2edc6dd6c24#diff-36088c93368e137d955348aba223985bd4f198f2aaecd626c830f4612ca884c8R132-R136
10:41 < monlovesmango> Murch: can you explain the "Originally these tests relied on SFFO to work" comment in the git message? since BnB is disabled with SFFO?
10:42 < Murch[m]> Ah yeah. We had a couple bugs with SFFO and BnB
10:42 < Murch[m]> When you make the recipient pay the fee, what happens when you drop the excess to fees?
10:42 -!- Talkless [~Talkless@138.199.6.197] has joined #bitcoin-core-pr-reviews
10:42 < dzxzg38> It tests a performance optimization in CoinGrinder (https://github.com/bitcoin/bitcoin/commit/451be19dc10381122f705bbb2127b083f1d598c6) where equivalent input sets are skipped
10:43 < Murch[m]> It reduces the fees that get deducted from the recipient’s output (i.e., the recipient gets more)
10:43 < dzxzg38> It does by creating an input set with 50,000 5 cent outputs, a 2 cent output, and two 7 cent output
10:44 < Murch[m]> monlovesmango: It could happen that we tried to drop more to fees than the recipient was supposed to pay, and then they’d get more money than we tried to send in th efirst place
10:44 < Murch[m]> it was weird
10:44 < dzxzg38> Clone skipping lets us quickly get to the answer of using a 2 cent and two 7 cents to get to 16, but without lcone skipping we would search through the solutions including every "5 cent coin"
10:44 < monlovesmango> interesting... will need to reread and ponder
10:44 < Murch[m]> so we removed the SFFO option from BnB and that caused issues with the tests that used SFFO
10:45 < glozow> ah that's neat
10:45 < Murch[m]> I actually don’t remember exactly how the test was constructed to need SFFO to work, but yeah
10:45 < Murch[m]> dzxzg38: We are looking at the BnB tests here, though!
10:45 < monlovesmango> ok that order of events helps
10:45 < Murch[m]> dzxzg38: Right otherwise, though
10:46 < Murch[m]> How does the expected_result in the original test line up with what you would pick manually at low and at high feerates?
10:47 < monlovesmango> at high fee rates I think it would match what I would manually pick, but at low fee rates I think it would be preferable to use more  utxos
10:48 -!- Santos [~Santos@32.141.102.6] has joined #bitcoin-core-pr-reviews
10:48 < Murch[m]> In the old test we had 4 × 7 CENT + 1 × 2 CENT + 50'000 × 5 CENT. We were looking for 4×7+2 = 30.
10:48 < Murch[m]> monlovesmango: Right, what would that be?
10:49 < monlovesmango> also, i know this is probably irrelavent to the way the coin selection actually execute in BnB, but was thinking maybe 1 cent and two 7 cents should be used to get 15 instead? so that the 5 cent coins still factor to 15?
10:50 < monlovesmango> so in the old test I would prefer 6x5 = 30 for coin selection in low fee environment
10:50 < Murch[m]> In the new test, we have 2 × 7 CENT + 1 × 2 CENT + 50'000 × 5 CENT
10:50 < Murch[m]> and we are looking for 16 CENT
10:51 < Murch[m]> monlovesmango: Yeah, exactly!
10:51 < Murch[m]> So, I reimplemented BnB in the style of CoinGrinder in #32150
10:51 < monlovesmango> in the new test (for low fee env) i would prob prefer 3x5 + 1x2
10:52 < Murch[m]> And after I added the CloneSkipping it found the 6 × 5 CENT solution for low feerates
10:52 < Murch[m]> That’s why I changed it to 16 δρ
10:52 < Murch[m]> :)
10:52 < Murch[m]> monlovesmango: 17 CENT is too much, though, that’s not a changeless solution
10:53 < Murch[m]> It’s a fine selection if you want to create change, though
10:53 < monlovesmango> ahh true
10:53 < Murch[m]> Almost done, so let’s keep moving: What is the motivation for the “Overshoot upper bound” to use different values than the original?
10:53 < Murch[m]> https://github.com/bitcoin-core-review-club/bitcoin/commit/65521465da036616172f4fbeef2855b8ddefd75f#diff-36088c93368e137d955348aba223985bd4f198f2aaecd626c830f4612ca884c8R141-R142
10:53 < monlovesmango> "And after I added the CloneSkipping it found the 6 × 5 CENT solution for low feerates" - what was the solution for high feerates?
10:54 < monlovesmango> I think the original was using 0 fee
10:54 < Murch[m]> monlovesmango: It should still be the 4×7+2, since that needs to pay for five inputs, whereas 6×5 pays for six inputs
10:54 < Murch[m]> monlovesmango: Yeah, I adapted the test to use effective values and ran it at high and low
10:55 < monlovesmango> ok maybe i'll try adding some tests to test it out myself :)
10:55 < Murch[m]> Ah, I remember now
10:55 < Murch[m]> I first just reimplemented BnB and then it could iterate through more combinations within the 100'000 cutoff
10:56 < Murch[m]> and with the clone skipping optimization it found the 6×5 at feerate 0, because it prefers more inputs at low feerates
10:56 < Murch[m]> I later rebased the BnB rewrite on this Test refactor, though
10:56 < Murch[m]> And I picked the 16 because it was not ambiguous
10:57 < Murch[m]> i.e. it only has the 2 × 2×7 solution, whereas the 30 had the two solutions
10:57 < monlovesmango> also, the way that it tested now, it is very explicit that it cannot overshoot by more than cost of change
10:58 < Murch[m]> Any thoughts on the Overshoot upper bound test?
10:58 < Murch[m]> Since the question is orthogonal, let me also put out the last question: What characteristic makes a set of UTXOs “expensive to search” for BnB?
10:58 < Murch[m]> monlovesmango: Right: previously it just tested a single value that overshot the target window.
10:58 < monlovesmango> I actually had assumed the ambiguity of the old test was intentional, which was the only reason I brought it up for the new test
10:58 < Murch[m]> The new test tests the last value that is permitted and tests the first value that overshoots: it tests exactly the boundaries
10:59 < monlovesmango> Murch: yep it is much more concrete now
10:59 < Murch[m]> monlovesmango: I had first changed the test and then only noticed it when I rewrote BnB ^^
11:00 < monlovesmango> haha.. its a process
11:00 < stringintech> I had a question regarding the coverage reports
11:00 < Murch[m]> Okay, I’ll take the last question myself:
11:00 < Murch[m]> BnB has a hard time iterating through UTXO pools that have a lot of similar values. I.e., just like the "doppelganger pool" where there are a bunch of UTXOs that only differ by one sat.
11:00 < Murch[m]> stringintech: Go ahead!
11:00 < Santos> A set of UTXOs is “expensive to search” for BnB when it has: many coins with nearly identical values, a tight target value relative to the sum of available coins or weight characteristics that force frequent backtracking due to transaction size limits.
11:01 < stringintech> https://limewire.com/d/6TqGD#2VHPC3MSXx
11:01 < stringintech> you can see it here; I should be comparing the coinselection.cpp coverage in the two reports right? (above for the PR branch and below the master)
11:01 < Murch[m]> Santos: Very good, that’s better than my answre :)
11:02 < Murch[m]> #endmeeting
11:02 < Murch[m]> That’s the end of the hour, thank you all for joining us
11:02 < Murch[m]> stringintech: yeah, looking at it now
11:02 < monlovesmango> Thanks for hosting Murch!!
11:02 < stringintech> Thank you!!
11:02 < dzxzg38> Thanks for hosting! Thanks everyone!!
11:02 < Santos> Thank you !
11:03 < Murch[m]> stringintech: Yeah, that’s exactly what you would want to look at
11:04 < stringintech> It seems the coverage has not changed then; which is expected?
11:04 < monlovesmango> if others are still around, was anyone able to run "cmake -P build/Coverage.cmake"? I kept getting errors... but maybe i need to do a clean build
11:04 < Murch[m]> stringintech: Yeah, we would hope the coverage to be at least as good as before
11:04 < stringintech> Ahaa Thanks!
11:04 < glozow> thank you Murch!
11:05 < Murch[m]> If the coverage regressed, we would hopefully see some of these numbers go down
11:05 < Murch[m]> Although we did discover with monlovesmango earlier that I should defitnitely add at least one test at feerate 0 ;)
11:05 < Murch[m]> Thanks again everyone!
11:07 < Murch[m]> stringintech: Although it looks like there are now also more lines to cover. I guess the test suite itself counts into it somehow?
11:08 -!- dzxzg38 [~dzxzg@user/dzxzg] has quit [Quit: Client closed]
11:09 < stringintech> monlovesmango: I followed the "Using LLVM/Clang toolchain" section in developer notes and it was okay (I guess you are referring to another section: "Using LCOV")
11:10 < monlovesmango> stringintech: I will check that out thank you!!
11:11 < stringintech> :Murch[m] I thought so! cause the coinselection.cpp row was the same for both...
11:12 -!- Santos [~Santos@32.141.102.6] has quit [Ping timeout: 240 seconds]
11:19 -!- stringintech97 [~stringint@5.120.213.57] has joined #bitcoin-core-pr-reviews
11:19 -!- stringintech [~stringint@5.120.213.57] has quit [Quit: Client closed]
11:20 -!- stringintech97 [~stringint@5.120.213.57] has quit [Client Quit]
11:20 -!- monlovesmango [~monlovesm@146.70.174.222] has quit [Quit: leaving]
11:21 -!- monlovesmango [~monlovesm@146.70.174.222] has joined #bitcoin-core-pr-reviews
11:21 -!- monlovesmango [~monlovesm@146.70.174.222] has quit [Client Quit]
11:42 < Murch[m]> Yeah, the "LCOV" one currently doesn’t work, I think
11:43 < Murch[m]> stringintech: If you look at the numbers in the parentheses behind the percentages, you see that the count of functions and lines went down for coinselector_tests which is the old test suite
11:44 < Murch[m]> And actually the branch coverage went down minusculy
11:44 < Murch[m]> So thanks for running that
11:45 < Murch[m]> Oh, now I get what you mean. Yes the line for coinselection.cpp stayed exactly the same which is good!
11:45 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
11:54 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
11:56 -!- jonatack [~jonatack@user/jonatack] has quit [Excess Flood]
11:58 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
12:21 -!- pablomartin [~pablomart@91.196.223.69] has joined #bitcoin-core-pr-reviews
12:27 -!- Talkless [~Talkless@138.199.6.197] has quit [Quit: Konversation terminated!]
12:33 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 244 seconds]
12:33 -!- ___nick___ [~quassel@82-132-215-108.dab.02.net] has joined #bitcoin-core-pr-reviews
12:36 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
12:37 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
12:37 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has joined #bitcoin-core-pr-reviews
12:54 -!- pablomartin [~pablomart@91.196.223.69] has quit [Ping timeout: 260 seconds]
12:57 -!- pablomartin [~pablomart@91.196.223.70] has joined #bitcoin-core-pr-reviews
13:04 -!- ___nick___ [~quassel@82-132-215-108.dab.02.net] has quit [Ping timeout: 252 seconds]
13:20 -!- pablomartin [~pablomart@91.196.223.70] has quit [Ping timeout: 252 seconds]
13:49 -!- corebot [~limnoria@user/core-meetbot] has joined #bitcoin-core-pr-reviews
13:53 < achow101> corebot: ping
13:53 < corebot> pong
13:53 < achow101> the bot is active here now, it will do the pr number linking and automatic meeting notes
14:10 < glozow> achow101: nice, thanks! where do the meeting notes go?
14:11 < achow101> it should say when you do #endmeeting
14:11 < glozow> #startmeeting
14:11 < corebot> glozow: Meeting started at 2025-04-16T21:11+0000
14:11 < corebot> glozow: Current chairs: glozow
14:11 < corebot> glozow: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
14:11 < glozow> hello this is a test
14:11 < corebot> glozow: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
14:11 < corebot> glozow: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
14:11 < glozow> #endmeeting
14:11 < corebot> glozow: Meeting ended at 2025-04-16T21:11+0000
14:11 < corebot> glozow: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-pr-reviews.2025-04-16_21_11.log.json
14:11 < corebot> glozow: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-pr-reviews.2025-04-16_21_11.log.html
14:11 < corebot> glozow: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-pr-reviews.2025-04-16_21_11.html
14:11 < kevkevin_> #here kevkevin :)
14:12 < glozow> sweet!
14:16 -!- pablomartin [~pablomart@91.196.223.63] has joined #bitcoin-core-pr-reviews
14:30 < sipa> #31444
14:30 < corebot> https://github.com/bitcoin/bitcoin/issues/31444 | cluster mempool: add txgraph diagrams/mining/eviction by sipa · Pull Request #31444 · bitcoin/bitcoin · GitHub
14:45 -!- pablomartin [~pablomart@91.196.223.63] has quit [Quit: Leaving]
14:55 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 265 seconds]
15:34 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:40 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
18:07 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
18:08 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Remote host closed the connection]
19:00 -!- kevkevin_ [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
19:04 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
19:30 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
19:36 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 276 seconds]
22:03 -!- yakshaver[m] [~yakshaver@2620:6e:a000:ce11::2b] has quit [Ping timeout: 248 seconds]
22:03 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has quit [Ping timeout: 248 seconds]
22:03 -!- BlueMattMtrxBot [~bluemattm@2620:6e:a000:ce11::42] has quit [Ping timeout: 272 seconds]
22:03 -!- sr_gi[m] [~srgimatri@2620:6e:a000:ce11::2a] has quit [Ping timeout: 248 seconds]
22:20 -!- yakshaver[m] [~yakshaver@2620:6e:a000:ce11::2b] has joined #bitcoin-core-pr-reviews
22:20 -!- BlueMatt[m] [~bluematt@2620:6e:a000:ce11::d] has joined #bitcoin-core-pr-reviews
22:21 -!- BlueMattMtrxBot [~bluemattm@2620:6e:a000:ce11::42] has joined #bitcoin-core-pr-reviews
22:23 -!- sr_gi[m] [~srgimatri@2620:6e:a000:ce11::2a] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Apr 17 00:00:18 2025