--- Log opened Wed Apr 09 00:00:12 2025
01:01 -!- dunxen [~dunxen@user/dunxen] has joined #bitcoin-core-pr-reviews
02:05 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
02:08 -!- dunxen [~dunxen@user/dunxen] has quit [Remote host closed the connection]
02:09 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
03:05 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
03:16 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
03:19 -!- pyth [~pyth@user/pyth] has joined #bitcoin-core-pr-reviews
03:21 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 260 seconds]
04:32 -!- pyth [~pyth@user/pyth] has quit [Remote host closed the connection]
04:51 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
04:53 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 265 seconds]
04:58 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
05:03 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 248 seconds]
05:27 -!- sirecmg [~sirecmg@user/valiant] has joined #bitcoin-core-pr-reviews
05:36 -!- sirecmg [~sirecmg@user/valiant] has quit [Quit: The Lounge - https://thelounge.chat]
05:36 -!- sirecmg [~sirecmg@user/valiant] has joined #bitcoin-core-pr-reviews
05:50 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
05:59 -!- sliv3r_ [~sliv3r__@user/sliv3r-:76883] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
06:00 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 276 seconds]
06:01 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has joined #bitcoin-core-pr-reviews
06:17 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
06:19 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
06:21 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
06:32 -!- sirecmg [~sirecmg@user/valiant] has quit [Ping timeout: 260 seconds]
06:53 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Read error: Connection reset by peer]
06:53 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
07:06 < glozow> Reminder: review club in ~3 hours!
08:39 -!- pablomartin [~pablomart@194.35.235.77] has joined #bitcoin-core-pr-reviews
08:53 -!- SirECMG [~SirECMG@2001:4898:e008:1:82d2:69e1:e2ce:6a4c] has joined #bitcoin-core-pr-reviews
09:05 -!- SirECMG [~SirECMG@2001:4898:e008:1:82d2:69e1:e2ce:6a4c] has quit [Ping timeout: 240 seconds]
09:36 -!- pablomartin [~pablomart@194.35.235.77] has quit [Quit: Leaving]
09:52 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:52 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-pr-reviews
09:57 < abubakarsadiq> #startmeeting
09:57 -!- Naiyoma [~Naiyoma@197.237.255.169] has joined #bitcoin-core-pr-reviews
09:57 -!- Naiyoma [~Naiyoma@197.237.255.169] has quit [Client Quit]
09:58 < abubakarsadiq> oops too early :)
09:58 < abubakarsadiq> hi
09:58 < sliv3r__> early hi! :)
09:59 -!- Musa [~Musa@2a00:7c80:0:3c4::14] has joined #bitcoin-core-pr-reviews
10:00 < Novo__> hi
10:00 < abubakarsadiq> #startmeeting
10:00 < glozow> hi
10:00 < dzxzg> hi
10:00 < Musa> hi
10:00 < sipa> hi
10:01 < abubakarsadiq> hi everyone, welcome to this edition of the bitcoin core PR review club.
10:01 < abubakarsadiq> thanks for joining
10:01 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
10:01 < abubakarsadiq> We are looking at Bitcoin core PR #31664 which I authored, lets dive in
10:01 < adys> hi
10:02 < monlovesmango> heyy
10:02 -!- Naiyoma [~Naiyoma@197.237.255.169] has joined #bitcoin-core-pr-reviews
10:02 < effexzi> hello every1
10:02 < abubakarsadiq> who got the chance to review the PR or read the notes? (y/n) 
10:02 < Musa> Yes, I was able to read the notes
10:03 -!- oxfrank [~oxfrank@41.90.172.213] has joined #bitcoin-core-pr-reviews
10:03 < sliv3r__> y, not deep dive into the code but could check the notes and and took a fast look into the pr
10:03 < dzxzg> y (light)
10:03 < abubakarsadiq> Nice also feel free to ask question anytime, dont ask to ask :)
10:03 < oxfrank> y
10:04 < monlovesmango> y a bit
10:04 < abubakarsadiq> 1. Why is the new system called a “Forecaster” and “ForecasterManager” rather than an “Estimator” and “Fee Estimation Manager”?
10:04 < sliv3r__> I guess bc estimators rely on past information (blockchain info), forecaster uses data from the future
10:04 < monlovesmango> bc its trying to predict future fees?
10:05 < Musa> I think because it manages both historical data and current mempool data
10:05 < oxfrank> forecaster implies predicting future fee rates
10:06 < abubakarsadiq> yes  IMO think estimator is a misnomer,  The system predicts future outcomes based on current and past data. Unlike an estimator, which approximates present conditions with some randomization, a forecaster projects future events, which aligns with this system’s predictive nature and its output of uncertainty/risk levels.
10:06 < Musa> Which enables to predict future rates more accurate you both
10:07 -!- Leo82 [~Leo@32.141.102.6] has joined #bitcoin-core-pr-reviews
10:08 < abubakarsadiq> 2. Why is CBlockPolicyEstimator not modified to hold the mempool reference, similar to the approach in PR #12966 #12966 What is the current approach and why is it better than holding a reference to mempool? (Hint: see #28368)
10:08 -!- dzxzg [~dzxzg@user/dzxzg] has quit [Quit: Client closed]
10:09 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-pr-reviews
10:09 < abubakarsadiq> @sliv3r ForecasterManager also rely on past information.
10:11 < glozow> conceptually, `CBlockPolicyEstimator` doesn't really need to interact with mempool. it can get all the data it needs from the validation interface events
10:11 -!- Musa [~Musa@2a00:7c80:0:3c4::14] has quit [Quit: Client closed]
10:11 < abubakarsadiq> yes :100
10:11 < sliv3r__> @glozow bc it doesn't need to do any change on it you mean?
10:11 < abubakarsadiq> We had already refactored CBlockPolicyEstimator to not hold a mempool reference, instead updating through the validation interface.
10:12 < glozow> it doesn't need to make any changes to mempool certainly. but it doesn't even really need to know the mempool's contents
10:12 < monlovesmango> from some of the hints it seems that fee estimator was blocking mempool updates when txs were removed, which isnt ideal, especially if you are trying to improve fee estimation functionality
10:13 < glozow> that was the other direction - mempool used to also own the cblockpolicyestimator
10:13 < abubakarsadiq> Also I think it's cleaner to have a separate class (MempoolForecaster) to hold the mempool reference and generate mempool forecast.
10:13 < monlovesmango> glozow: ah ok!
10:14 < sliv3r__> @glozow oh right, only some data you extract from it (feerates in this case)
10:14 < glozow> but MempoolForecaster and CBlockPolicyEstimator don't talk to each other, do they?
10:14 < abubakarsadiq> They don't
10:15 < willcl-ark> hi
10:15 < abubakarsadiq> this is the reason for the design of the forecaster manager to separate concern
10:15 -!- SirECMG [~SirECMG@172.182.148.195] has joined #bitcoin-core-pr-reviews
10:16 < abubakarsadiq> This brings us to the next question
10:16 < abubakarsadiq> 3. What are the trade-offs between the new architecture and a direct modification of CBlockPolicyEstimator?
10:17 < monlovesmango> direct modification would probably be easier short term, as you wouldn't need to alter the code where CBlockPolicyEstimator is called. but long term the new architecture allows for a lot more flexibility and upgradability.
10:18 < abubakarsadiq> yes the pro's of this is clean separation of logic, easy to plug in new forecasting strategies, modular & testable
10:18 < abubakarsadiq> what are the cons?
10:19 < abubakarsadiq> I think more code to maintain, slightly more complexity
10:19 < oxfrank> imo slightly more difficult to implement and minor possible performance overhead from additional abstraction
10:19 < monlovesmango> maintaining more methods of fee estimation? i'm actually not too sure why you wouldn't want to do this
10:20 < glozow> could be confusing for users who probably have no idea how the estimations work or which one is more suitable for them
10:20 -!- Musa [~Musa@2a00:7c80:0:3c4::14] has joined #bitcoin-core-pr-reviews
10:21 < Leo82> Maintenance burden
10:21 < abubakarsadiq> yeah @willclark I think we discussed this, most users just want a value to use.
10:22 < abubakarsadiq>  If we just add a new method to block policy estimator for getting mempool fee rate forecast it will be simple, fast to implement, reuses existing structure, minimal changes
10:22 < sliv3r__> @glozow I don't think that's a con. I guess a default value will be set and then users with more expertise will be able to choose depending on their needs
10:22 < glozow> a even having params is confusing - a lot of people were noticing overestimates, only 1 person realized that they could use "economical" instead of  "conservative"
10:23 < glozow> (only 1 person that i know of, i mean)
10:23 < abubakarsadiq> Yes we should probably provide a value response and when you want verbose response you can get the information on which forecasting strategy was used and other details
10:24 < abubakarsadiq> Let's dive into the Code review section.
10:24 < abubakarsadiq> 1. Why does Commit 1e6ce06 compare against only the high-priority estimate?
10:25 < abubakarsadiq> @glozow I think AJ suggested it first, then a user also opened an issue about it.
10:25 < sliv3r__> This one I didn't get it. High priority will always be the higher number so the estimation with the biggest high-priority estimation will be the bigger one but we could also answer on the other way
10:25 < abubakarsadiq> yes @sliv3r it more than low priority
10:26 < abubakarsadiq> why is so for mempool forecaster? also why for block policy?
10:27 < monlovesmango> is it bc the high priority fee will usually have more difference in fee?
10:28 -!- Talkless [~Talkless@138.199.6.197] has joined #bitcoin-core-pr-reviews
10:28 < monlovesmango> or said differently, that the high priority fee will usually be more differentiated?
10:28 < glozow> well what's the use case for having a comparison operator for `ForecastResult`s?
10:28 < abubakarsadiq> In Mempool forecaster, high priority and low priority are  the 50th and 75th percentile fee rate of the generated block template
10:29 < abubakarsadiq> the use case is to compare fee rate forecast from block policy and mempool forecaster
10:30 < abubakarsadiq> In Block Policy the high and low priority are the conservative and economical fee rate estimate for a confirmation target.
10:30 < glozow> and do you want to compare them based on how much money it might cost the user?
10:31 < sliv3r__> what's the use case of that comparison between forecasters? 
10:31 < monlovesmango> yes but why choose to compare the high priority fee as opposed to the low priority fee?
10:31 < glozow> presumably because you want to choose 1 to return to the user
10:31 < monlovesmango> what happens when user is wanting a low priority fee, how will this comparision be helpful?
10:31 < abubakarsadiq> @sliv3r see https://github.com/bitcoin/bitcoin/pull/31664#discussion_r2033340253
10:32 < abubakarsadiq> @monlovesmango because it is higher, you dont want to confirm with the lower value
10:33 < abubakarsadiq> compare*
10:33 < abubakarsadiq> 2. What other methods might be useful in the Forecaster interface (Commit a2e3326)?
10:34 -!- Guest40 [~Guest47@130-142-20-31.ftth.glasoperator.nl] has joined #bitcoin-core-pr-reviews
10:34 < monlovesmango> i don't think i'm understanding. if a user wants a low priority fee, wouldn't we want to compare the low priority fee estimates from the two methods instead of the high priority fee estimates from the two methods?
10:35 < abubakarsadiq> @glozow yes you do. (you just want to know that what your mempool is suggesting for you to pay for high priority transactions is not higher than conservative fee rate estimate from block plicy)
10:35 < monlovesmango> might be useful to be able to specify using only one method to estimate
10:35 < sliv3r__> @abubakarsadiq fast checked, makes more sense with this :) so it's a protect mechanism against mempool manipulation
10:36 < abubakarsadiq> @monlovesmango good point.
10:37 < sliv3r__> but this can be a problem for example on LN. If you understimate during a spike when you have, let's say, 1 block time before the attacker can spend their coins (thus steal from you), you may not be able to get the penalty transaction mined on time
10:37 < sliv3r__> (The attack here would be to broadcast an old state)
10:39 < sliv3r__> I guess a solution to this is just give the option to specify that you want the higher fee-rate estimation and overpaid it a bit.
10:40 < abubakarsadiq> Yes I think LN has a better solution and than getting the state of the mempool when the deadline is that close, there is a great solution I like called deadline aware budget sweeper
10:40 < abubakarsadiq> https://delvingbitcoin.org/t/lnds-deadline-aware-budget-sweeper/1512
10:41 < sliv3r__> will take a look, thx
10:42 < abubakarsadiq> The aim is for solution like the one in the delving post below to call this fee rate forecaster with 1,2 confirmation target, if the mempool is sparse; this solotion will prevent them from paying more than necessary. if a block elapsed and it did not confirm they can compare the new 1,2 confirmation target with the fee function output and use the highest
10:42 < abubakarsadiq> https://delvingbitcoin.org/t/lnds-deadline-aware-budget-sweeper/1512/5?u=ismaelsadeeq
10:44 < abubakarsadiq> The mempool forecaster will be used to correct block policy feerate forecaster and prevent you from paying more than necessary after having rough certainty that your mempool is in sync with miners
10:44 < abubakarsadiq> This has been suggested a long time ago by Kalle Alm https://delvingbitcoin.org/t/mempool-based-fee-estimation-on-bitcoin-core/703/2?u=ismaelsadeeq
10:45 < abubakarsadiq> 3. Why does Commit 143a301 return the current height, and where is `nBestSeenHeight` set in the code?
10:46 -!- oxfrank [~oxfrank@41.90.172.213] has quit [Quit: Client closed]
10:47 < monlovesmango> I think bc it is part of the ForcastResult?
10:47 < sliv3r__> sorry I'm 1 question late :) - regarding 2. A reset function could be usefull if we have for differents things like benchmarking if we have some stateful model that takes into account history (e.g the cache)
10:47 -!- oxfrank [~oxfrank@41.90.172.213] has joined #bitcoin-core-pr-reviews
10:48 < abubakarsadiq> 2. I also think `GetMaxTarget`: A method that returns the maximum confirmation target a forecaster can predict.
10:49 < abubakarsadiq> @sliv3r__ I don't follow
10:50 < abubakarsadiq> monlovesmango: Returning the current height can be helpful debugging and validation of forecast accuracy, helping us track at which height the forecast was made and assess effectiveness before the target elapsed.
10:50 < monlovesmango> it is set in https://github.com/bitcoin/bitcoin/blob/bb92bb36f211b88e4c1aa031a4364795cbd24767/src/policy/fees.cpp#L684..?
10:51 < abubakarsadiq> monlovesmango: YES
10:51 < monlovesmango> abubakaras: that makes sense
10:52 < abubakarsadiq> After connecting new block we update the current height, because new block was connected
10:52 < sliv3r__> @abubakarsadiq: we may have forecasters with "historic" data on memory. (E.g the cache). A reset function that returns it to the initial state can be usefull for testing and benchmarking. The initial idea on this was for chain reorgs but I think that in that case is not that important and just estimating again the fee would be good
10:52 < abubakarsadiq> monlovesmango: what if a reorg happen, how will you correct that?
10:52 < abubakarsadiq> 4. Why is it important to maintain monotonicity when iterating through the package fee rates in (Commit 61e2842)?
10:53 < sliv3r__> 4. For each percentile we should have a feerate equal or higher than the next one. So `90 >= 75 >= 50...`. If we choose based on priority we cannot let high priority pay less fees than low priority.
10:53 -!- oxfrank [~oxfrank@41.90.172.213] has quit [Quit: Client closed]
10:54 < monlovesmango> 4. bc the accumulated weight is somewhat disconnected from each percentage's weight, so ordering is very important
10:55 < abubakarsadiq> @liv3r__ how will the interface consumer; the forecaster manager benefit from getting the previous state?
10:56 < abubakarsadiq> sliv3r__: first part of your answer is correct; the reason is because the packages fee rate are not monotonically increasing, why?
10:58 < sliv3r__> @abubakarsadiq: not getting but reseting to default (0 or empty) value. For testing for example you may want to be able to call it multiple times fast without taking into account the cache.
10:59 < monlovesmango> abubakarsa: about the reorg, no idea. I would assume we would want to queue a reevaluation of any cached esitmates at the time of a reorg?
11:00 < abubakarsadiq> A transaction chunk fee rate may increase because it's parent was included previously in a sibling package. Hence the package  fee rates of a block template are not monotonic; thanks to @sipa and @murch for pointing that out to me.
11:01 < monlovesmango> they may not be monotonically increasing bc " Outliers can occur when the mining score of a transaction increases due to the inclusion of its ancestors in different transaction packages."
11:01 < abubakarsadiq> monlovesmango: yes 💯
11:01 < sliv3r__> @abubakarsadiq do you have a visual example of that?
11:02 < monlovesmango> ok thanks for explaning that further! I saw the comment (which I quoted) but wanted to ask what that meant further
11:02 -!- Naiyoma [~Naiyoma@197.237.255.169] has quit [Quit: Client closed]
11:02 -!- Naiyoma [~Naiyoma@197.237.255.169] has joined #bitcoin-core-pr-reviews
11:04 < abubakarsadiq> sliv3r__: Good point; I think it's important for us not to return the cached data in the case of reorg
11:04 < abubakarsadiq> #endmeeting
11:05 < monlovesmango> thanks for hosting abubakarsa!!
11:05 -!- Leo82 [~Leo@32.141.102.6] has quit [Ping timeout: 240 seconds]
11:05 < monlovesmango> that went by so fast haha
11:05 < sliv3r__> thanks for hosting!
11:05 < abubakarsadiq> yeah :) glad you liked it
11:05 < abubakarsadiq> will be here for next 30 minutes we can answer the remaining questions.
11:05 < dzxzg> Thank you!!
11:06 < SirECMG> Thank you for hosting! Love the engaging discussions, learning a ton!
11:06 < sliv3r__> just one last question, we didn't get to that question. The reason for 50th and 75th percentile is just to avoid extrem cases? Some tx paying too low on the 25th percentile and some paying far extra on the 90th?
11:07 < effexzi> thanks every1
11:07 -!- Naiyoma [~Naiyoma@197.237.255.169] has quit [Client Quit]
11:07 -!- Musa [~Musa@2a00:7c80:0:3c4::14] has quit [Ping timeout: 240 seconds]
11:07 < glozow> thank you abubakarsadiq!
11:07 < abubakarsadiq> The 50th percentile is the mean fee rate (around 2,000,000 WU). Empirical analysis shows that paying this fee rate likely prevents getting bumped from the block due to transaction inflow while avoiding overpayment.
11:07 < abubakarsadiq> The 75th percentile is economical (around 2,800,000 WU), placing your transaction in a range where higher-fee transactions are unlikely to exclude it from the next block.
11:08 < abubakarsadiq> *incoming higher-fee transactions;
11:08 < sliv3r__> make sense
11:09 < abubakarsadiq> if you use the low priority as time goes on and the block is not mined, depending on the inflow you may get bumped out
11:09 < abubakarsadiq> thanks everyone for joining!!!
11:10 < sliv3r__> got it! thanks again abubakarsadiq! Really interesting one!
11:26 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Quit: leaving]
11:48 -!- Guest40 [~Guest47@130-142-20-31.ftth.glasoperator.nl] has quit [Quit: Client closed]
11:52 -!- SirECMG [~SirECMG@172.182.148.195] has quit [Quit: Client closed]
11:59 -!- dzxzg [~dzxzg@user/dzxzg] has quit [Ping timeout: 240 seconds]
12:25 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 248 seconds]
12:27 -!- Talkless [~Talkless@138.199.6.197] has quit [Quit: Konversation terminated!]
12:46 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
12:55 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
13:19 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 268 seconds]
13:37 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
13:43 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
14:02 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
14:10 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 244 seconds]
14:12 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
14:49 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 244 seconds]
15:21 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
15:41 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 244 seconds]
15:52 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
17:44 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
18:05 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
18:06 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has joined #bitcoin-core-pr-reviews
18:37 -!- sliv3r__- [~sliv3r__@user/sliv3r-:76883] has joined #bitcoin-core-pr-reviews
18:38 -!- sliv3r__ [~sliv3r__@user/sliv3r-:76883] has quit [Read error: Connection reset by peer]
18:54 -!- pyth [~pyth@user/pyth] has joined #bitcoin-core-pr-reviews
19:16 -!- andreadcorreia [~andreadco@host182.190-30-101.telecom.net.ar] has joined #bitcoin-core-pr-reviews
20:05 -!- pyth [~pyth@user/pyth] has quit [Remote host closed the connection]
20:44 -!- andreadcorreia [~andreadco@host182.190-30-101.telecom.net.ar] has quit [Quit: Client closed]
21:40 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Remote host closed the connection]
22:28 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-pr-reviews
22:32 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 265 seconds]
22:53 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
23:17 -!- yakshaver[m] [~yakshaver@2620:6e:a000:ce11::2b] has quit [Ping timeout: 248 seconds]
23:17 -!- sr_gi[m] [~srgimatri@2620:6e:a000:ce11::2a] has quit [Ping timeout: 248 seconds]
23:17 -!- Murch[m] [~murch@user/murch] has quit [Ping timeout: 248 seconds]
23:17 -!- BlueMattMtrxBot [~bluemattm@2620:6e:a000:ce11::3e] has quit [Ping timeout: 248 seconds]
23:17 -!- yakshaver[m] [~yakshaver@2620:6e:a000:ce11::2b] has joined #bitcoin-core-pr-reviews
23:18 -!- laanwj [~laanwj@user/laanwj] has quit [Ping timeout: 268 seconds]
23:19 -!- Murch[m] [~murch@2620:6e:a000:ce11::1b] has joined #bitcoin-core-pr-reviews
23:19 -!- sr_gi[m] [~srgimatri@2620:6e:a000:ce11::2a] has joined #bitcoin-core-pr-reviews
23:30 -!- BlueMattMtrxBot [~bluemattm@2620:6e:a000:ce11::3e] has joined #bitcoin-core-pr-reviews
23:31 -!- laanwj [~laanwj@user/laanwj] has joined #bitcoin-core-pr-reviews
23:43 -!- instagibbs2 [~instagibb@pool-100-15-116-202.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
23:44 -!- instagibbs [~instagibb@pool-100-15-116-202.washdc.fios.verizon.net] has quit [Ping timeout: 260 seconds]
23:44 -!- instagibbs2 is now known as instagibbs
--- Log closed Thu Apr 10 00:00:12 2025