--- Log opened Wed May 07 00:00:36 2025
02:05 -!- pablomartin [~pablomart@53.red-79-150-160.dynamicip.rima-tde.net] has quit [Ping timeout: 268 seconds]
02:05 -!- pablomartin [~pablomart@1.red-79-151-104.dynamicip.rima-tde.net] has joined #bitcoin-core-pr-reviews
02:18 -!- pablomartin [~pablomart@1.red-79-151-104.dynamicip.rima-tde.net] has quit [Ping timeout: 276 seconds]
02:25 -!- pablomartin [~pablomart@66.red-79-151-104.dynamicip.rima-tde.net] has joined #bitcoin-core-pr-reviews
05:52 -!- brunoerg [~brunoerg@2804:14d:5285:84b2::1000] has quit [Read error: Connection reset by peer]
05:52 -!- brunoerg_ [~brunoerg@2804:14d:5285:84b2::1000] has joined #bitcoin-core-pr-reviews
06:09 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
06:11 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
06:26 -!- pablomartin4btc [~pablomart@217.130.254.81] has joined #bitcoin-core-pr-reviews
07:05 -!- brunoerg_ [~brunoerg@2804:14d:5285:84b2::1000] has quit [Ping timeout: 268 seconds]
07:08 -!- brunoerg [~brunoerg@2804:14d:5285:84b2::1001] has joined #bitcoin-core-pr-reviews
07:29 -!- Guest98 [~Guest98@185.98.171.87] has joined #bitcoin-core-pr-reviews
07:32 -!- Guest98 [~Guest98@185.98.171.87] has quit [Client Quit]
07:34 -!- Guest98 [~Guest98@185.98.171.87] has joined #bitcoin-core-pr-reviews
07:35 -!- Guest98 [~Guest98@185.98.171.87] has quit [Client Quit]
07:43 -!- maflcko_ [~none@107.172.8.183] has quit [Quit: ZNC 1.8.2+deb2ubuntu0.1 - https://znc.in]
07:45 -!- maflcko [~none@107.172.8.183] has joined #bitcoin-core-pr-reviews
07:50 -!- pablomartin4btc [~pablomart@217.130.254.81] has quit [Ping timeout: 276 seconds]
07:59 -!- donal [~donal@user/donal] has joined #bitcoin-core-pr-reviews
08:38 -!- Guest61 [~Guest29@2600:1700:6973:5400:2459:4396:d8f2:898a] has joined #bitcoin-core-pr-reviews
09:02 -!- pyth [~pyth@user/pyth] has joined #bitcoin-core-pr-reviews
09:07 < ryanofsky> Review club should start in about an hour (if I'm not messing up time zones) for https://bitcoincore.reviews/31375
09:08 < Guest61> it should be now right?
09:08 < stickies-v> nope, it's at 5pm UTC which is in ~52 minutes
09:09 < Guest61> ah okay got it
09:09 -!- joetor5 [~joetor5@syn-070-119-066-121.res.spectrum.com] has joined #bitcoin-core-pr-reviews
09:09 < emzy> I hate timezones.
09:10 -!- joetor5 [~joetor5@user/joetor5] has changed host
09:11 -!- donal [~donal@user/donal] has quit [Quit: Client closed]
09:12 -!- brunoerg_ [~brunoerg@2804:14d:5285:84b2::1000] has joined #bitcoin-core-pr-reviews
09:13 -!- brunoer__ [~brunoerg@187.183.60.153] has joined #bitcoin-core-pr-reviews
09:14 < stickies-v> let's all switch to MTP
09:14 < stickies-v> timewarp attacks would become so much more fun
09:14 -!- brunoerg_ [~brunoerg@2804:14d:5285:84b2::1000] has quit [Read error: Connection reset by peer]
09:15 -!- brunoerg [~brunoerg@2804:14d:5285:84b2::1001] has quit [Ping timeout: 276 seconds]
09:33 -!- joetor5 [~joetor5@user/joetor5] has quit [Ping timeout: 245 seconds]
09:33 -!- joetor5 [~joetor5@syn-070-119-066-121.res.spectrum.com] has joined #bitcoin-core-pr-reviews
09:35 -!- joetor5 [~joetor5@user/joetor5] has changed host
09:37 -!- joetor5 [~joetor5@user/joetor5] has quit [Remote host closed the connection]
09:55 -!- hodlinator [~user@user/hodlinator] has joined #bitcoin-core-pr-reviews
09:57 -!- Guest86 [~Guest86@197.210.8.173] has joined #bitcoin-core-pr-reviews
09:57 -!- pablomartin4btc [~pablomart@217.130.254.81] has joined #bitcoin-core-pr-reviews
09:58 -!- joetor5 [~joetor5@syn-070-119-066-121.res.spectrum.com] has joined #bitcoin-core-pr-reviews
09:58 -!- joetor5 [~joetor5@user/joetor5] has changed host
09:59 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has joined #bitcoin-core-pr-reviews
10:00 < ryanofsky> #startmeeting
10:00 < corebot> ryanofsky: Meeting started at 2025-05-07T17:00+0000
10:00 < corebot> ryanofsky: Current chairs: ryanofsky
10:00 < corebot> ryanofsky: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
10:00 < corebot> ryanofsky: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
10:00 < corebot> ryanofsky: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
10:00 < abubakarsadiq> hi
10:00 < ryanofsky> hi
10:00 < hodlinator> hi
10:00 < stickies-v> hi
10:00 < kevkevin> hi
10:00 < emzy> hi
10:00 < ryanofsky> Welcome to the bitcoin review consortium! Today up for discussion is https://bitcoincore.reviews/31375 #31375
10:00 < corebot> https://github.com/bitcoin/bitcoin/issues/31375 | multiprocess: Add bitcoin wrapper executable by ryanofsky · Pull Request #31375 · bitcoin/bitcoin · GitHub
10:00 -!- monlovesmango [~monlovesm@146.70.174.222] has joined #bitcoin-core-pr-reviews
10:01 < ryanofsky> I'll squash the first two questions and ask if anybody looked at the code or tested the new command? What was your approach? Any feedback or questions you have before we begin?
10:01 < pseudoramdom> hi
10:01 < monlovesmango> hey
10:02 < hodlinator> feels like it's a good change even without multiprocess
10:02 < abubakarsadiq> I read the notes, reviewed the notes, tested the functionality it run smoothly, and performed a light code review recently.
10:02 < monlovesmango> concept ack, looked through some of the code and did very light testing
10:02 -!- pablomartin4btc [~pablomart@217.130.254.81] has quit [Ping timeout: 272 seconds]
10:02 < hodlinator> just in general to increase discoverability
10:02 < stickies-v> looked at most of the code and spun up a signet node in both mono and multi mode, all felt very ergonomic!
10:02 -!- pyth [~pyth@user/pyth] has quit [Remote host closed the connection]
10:02 -!- pablomartin4btc [~pablomart@217.130.254.81] has joined #bitcoin-core-pr-reviews
10:03 -!- Santos [~Santos@32.141.102.6] has joined #bitcoin-core-pr-reviews
10:03 < stickies-v> we must add tons of parsing logic to allow for `bitcoin -mh` though, forcing me to type `bitcoin -m -h` is unacceptable
10:03 < kevkevin> very briefly looked through the PR
10:03 < brunoer__> hi
10:03 < abubakarsadiq> Q: how will this wrapper approach fixes the ambiguity of the wallet command after https://github.com/bitcoin/bitcoin/pull/10102 what will happen to current bitcoin-wallet executable
10:04 < ryanofsky> stickies-v, that seems like a good thing to note for a future improvement
10:04 < pseudoramdom> liking the new subcommand ergonomics. Is this only when multiprocess is enabled? 
10:05 < emzy> I found out the "bitcoin util" also works. But is not listet at "bitcoin --help"
10:05 < ryanofsky> abubakarsadiq, current code in #10102 just adds new IPC functionality to current executable. Different directions could be taken though. I don't think it shoudl matter too much to users if they are using the wrapper
10:05 < corebot> https://github.com/bitcoin/bitcoin/issues/10102 | Multiprocess bitcoin by ryanofsky · Pull Request #10102 · bitcoin/bitcoin · GitHub
10:05 < hodlinator> emzy: needs "bitcoin -h -a" to show I think.
10:06 < ryanofsky> pseudoramdom, in current PR new binary is not tied to IPC / multiprocess options, it's available regardless
10:06 < monlovesmango> oh when I built it with -DENABLE_IPC=ON the counter was going to 101%
10:06 < hodlinator> ah, no it doesn't show util even then.
10:06 < emzy> hodlinator: that shows more but also no util
10:06 < ryanofsky> emzy, good find, I didn't know that. intention was to punt on bitcoin-util and not support it for now
10:07 < ryanofsky> i think it might be better to support `bitcoin grind` directly instead of requiring `bitcoin util grind` but that requires argsmanager changes
10:08 < ryanofsky> monlovesmango, i've definitely seen that cmake 101% progress thing, not sure what causes it
10:08 < ryanofsky> next question from the list is: 3. From issue #30983, four packaging strategies were listed. Which specific drawbacks of the “side‑binaries” approach does this PR address?
10:08 < corebot> https://github.com/bitcoin/bitcoin/issues/30983 | RFC: Multiprocess binaries and packaging options · Issue #30983 · bitcoin/bitcoin · GitHub
10:10 < stickies-v> there's only one con listed for the side-binaries approach so i'm gonna go with #1 of 1: confusing
10:10 < corebot> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
10:10 < monlovesmango> remove the need for adding more binaries for the user to choose from?
10:10 < abubakarsadiq> I think having multiple binaries in a single release. Instead of requiring users to call individual binaries,  the binaries will be placed in the `libexec` directory and wrapped under the bitcoin command. users dont have to deal with the new binaries they should just know the commands
10:11 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
10:11 < stickies-v> it's easier for the user to find what they need when they can go through a single binary that helps them find others
10:11 < ryanofsky> yeah exactly, there's only one thing listed there and the main goal is to avoid confusion if multiprocess support is added
10:11 < ryanofsky> Another thing it provides is forward compatability. Wrapper lets us rename binaries, consolidate them, replace them without changing external interface.
10:12 < ryanofsky> 4. In util::ExecVp() (Windows branch) why is a second std::vector escaped_args needed instead of modifying argv in‑place?
10:12 < stickies-v> and maybe in the future we can add some fuzzy search too for when you're not quite sure exactly what it was clled?
10:13 < abubakarsadiq> @ryanofsky is it okay to update an array while iterating through it?
10:14 < ryanofsky> It can be ok to update an array but in this case the array members are const `char *const argv[]`
10:14 < ryanofsky> relevant code is https://github.com/bitcoin/bitcoin/commit/9ac787c7a85c3d2ff407bf149b982fc347537b12
10:15 < ryanofsky> 5.  Walk through the escaping algorithm in util::ExecVp for the argument C:\Program Files\Bitcoin\bitcoin-qt. What exact string is passed to _execvp()?
10:17 < abubakarsadiq> 1. The algorithm first checks if the argument contains spaces, tabs, or quotes. 
10:17 < abubakarsadiq> 2. Quotes are added at the beginning and end of the argument.
10:17 < abubakarsadiq> 3. Backslashes (\) followed by quotes are doubled to ensure proper parsing.
10:17 < abubakarsadiq> 4. Any standalone quotes are escaped with a backslash.
The resulting string passed to _execvp() is:
"C:\\Program Files\\Bitcoin\\bitcoin-qt"
10:17 < ryanofsky> stickies-v, added your CLI improvement suggestions to the list in the description
10:18 < ryanofsky> Yes that's close but backslashes only need to be escaped if followed by quotes. So in the example the only change made is to add quotes around the argument. Backslashes don't need to be escaped there
10:18 < monlovesmango> is there any possibility single quotes are used? or is there validation upstream?
10:19 < abubakarsadiq> I see thanks
10:19 < ryanofsky> monlovesmango, in general this depends on your shell. Single quotes are allowed there
10:20 < ryanofsky> The only escaping this PR is doing is on windows where you have escape the argv[] array in a quirky way that the microsoft C runtime expects
10:21 < ryanofsky> otherwise the argv passed to execvp will not match the argv received by the program which is executed
10:21 < monlovesmango> I guess my question is do single quotes need to be handled?
10:21 < ryanofsky> monlovesmango, nope just because the windows internal argv parsing doesn't care about them
10:21 < monlovesmango> ryanofsky: makes sense
10:22 < monlovesmango> thanks
10:22 < ryanofsky> No problem!
10:22 < ryanofsky> 6. GetExePath() does not use readlink("/proc/self/exe") on Linux even though it would be more direct. What advantages does the current implementation have? What corner cases might it miss?
10:22 -!- Talkless [~Talkless@138.199.6.197] has joined #bitcoin-core-pr-reviews
10:24 < hodlinator> We may be running on another non-windows system that doesn't have proc-fs?
10:25 < ryanofsky> Yeah I think that's the only possible advantage, otherwise /proc/self/exe would probably be more reliable and direct
10:26 < ryanofsky> I'm not sure what situation is on macos or bsds
10:26 < ryanofsky> In ExecCommand, explain the purpose of the fallback_os_search Boolean. Under what circumstances is it better to avoid letting the OS search for the binary on the PATH?
10:26 < ryanofsky> ^^^ That was question 7
10:27 < ryanofsky> Link to relevant commit: https://github.com/bitcoin/bitcoin/commit/f2c003c927557f97dafa263e6cbb90a4e3421842
10:28 < hodlinator> It might be that one hasn't built all target executables in one's local build?
10:28 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
10:29 -!- Santos81 [~Santos@32.141.102.6] has joined #bitcoin-core-pr-reviews
10:29 < ryanofsky> hodlinator, yeah this behavior was just added to avoid confusing developers
10:29 < abubakarsadiq> When the wrapper executable is invoked using a specific path to prevent unintentionally use of a binary in PATH instead of the intended local binary. 
10:29 < monlovesmango> if executiable is invoked from path we don't want to fall back to operating system
10:29 < stickies-v> i think generally the wrapper and the individual binaries are all going to be shipped and compiled together, so searching locally is more robust?
10:29 -!- Guest61 [~Guest29@2600:1700:6973:5400:2459:4396:d8f2:898a] has quit [Ping timeout: 240 seconds]
10:30 < ryanofsky> stickies-v, that seems like a good point. maybe it would make sense to avoid searching PATH altogether
10:31 < ryanofsky> I think when I first implemented it, I didn't want to rely on GetExePath working perfectly, and wanted to take advantage of OS native ability find binaries
10:32 < ryanofsky> but then Sjors pointed out searching PATH could be confusing for developers if they didnt' build everythign, so narrowed the use of PATH. but could make sense to drop it altogether
10:32 -!- Santos [~Santos@32.141.102.6] has quit [Ping timeout: 240 seconds]
10:32 < stickies-v> not the same thing, but i stopped searching the system path with py-bitcoinkernel because it was leading to too much confusion and errors, so i allowed providing an explicit path env var instead which is hard to abuse
10:34 < emzy> I think using "bitcoin rpc --version" is helpful to figure out what you actualy running. Would help to also show the path of the binary.
10:34 < ryanofsky> Yeah I think main reason for using system path is I'd like wrapper to "just work" and avoid being unreliable
10:35 < hodlinator> Agree it may be a bit too magical.
10:36 < ryanofsky> "bitcoin rpc --version doesn't seem to show paths when I try, but could make sense to add a verbose / debug option maybe to show paths?
10:37 < ryanofsky> 8.  The wrapper searches ${prefix}/libexec only when it detects that it is running from an installed bin/ directory. Why not always search libexec?
10:37 < ryanofsky> This is the same commit https://github.com/bitcoin/bitcoin/commit/f2c003c927557f97dafa263e6cbb90a4e3421842 line 189
10:40 < ryanofsky> My answer to this was that wrapper should be conservative about what paths it tries to execute, and encourage standard PREFIX/{bin,libexec} layouts, not encourage packagers to create nonstandard layouts or work when binaries arranged in unexpected ways.
10:41 < ryanofsky> 9. The functional test layer now conditionally prepends bitcoin -m to every command. How does this interact with backwards‑compatibility testing where older releases are run in the same test suite?
10:41 < stickies-v> oh, is this because bitcoin core can also be shipped through package managers? because with our own build system we know it'll always be stored in the bin,libexec dirs?
10:42 < hodlinator> Re 9: https://github.com/bitcoin/bitcoin/pull/31375/commits/ccacae70ed050f37f5d00362152ba31036818691
10:44 < ryanofsky> stickies-v, yeah the code isn't just trying to be conservative abotu what it executes. It will execute binaries in paths explicitly listed on PATH and in places that seem to match expected layout, but avoid executing things in novel situations
10:44 -!- pseudoramdom [~pseudoram@user/pseudoramdom] has quit [Remote host closed the connection]
10:46 < stickies-v> that sounds like a good approach to me, and not something i realized we had to think of
10:46 < ryanofsky> Re 9: The Binaries._argv method in commit hodlinator linked to https://github.com/bitcoin/bitcoin/commit/ccacae70ed050f37f5d00362152ba31036818691 will ignore the wrapper executable entirely when testing previous releases because bin_dir will be set in that case
10:46 < ryanofsky> In future if bitcoin wrapper executable becomes part of previous releases and we want to test it, this code will need to be updated.
10:47 < stickies-v> so on the one hand we need to be conservative in what we execute, but on the other hand there may be package managers that (for some reason, idk) are unable to store binaries in the {bin,libexec} dirs?
10:48 < ryanofsky> stickies-v, I don't think we need to be conservative, I just thought it would be a good starting point. I don't think package manager will need to choose divergent layouts probably, but we can find out and adapt
10:49 < stickies-v> 👍
10:49 < hodlinator> So a test must explicitly call add_nodes() and pass in old versions, which will result in the old binaries being resolved.. and this resolution-logic will need to be updated to support the wrapper in the future.
10:49 < ryanofsky> Note: we won't have time to get to all questions listed so if any in particular someone wants to talk about (or some specific topic) feel free to suggest
10:50 < emzy> I'm in general concerned about searching for binaries to execute. There are many possible security problems. Better have it hardcoded to one path as libexec.
10:51 < ryanofsky> hodlinator, yes that sounds right. Test framework code right now just assumes all previous releases don't have a wrapper binary to call. So if we want to write new tests calling wrapper binaries in old releases something like that needs to change
10:51 < ryanofsky> emzy, I think that is what current PR does. It hardcodes to libexec and uses the operating systems normal mechanism to search the PATH
10:52 < hodlinator> Being flexible with PATH might enable attackers to put malicious binaries there to be resolved?
10:52 < emzy> The user/attacker can change the PATH.
10:53 < stickies-v> I was wondering why on windows we search the "daemon" dir - that's unrelated to our "bitcoin daemon" bin, right? Is this just a windows convention?
10:53 < emzy> At first glance that's not a problem. But whow knows. 
10:54 < abubakarsadiq> emzy: if the attacker can change the PATH; he can do worse than just putting malicious binaries no?
10:54 < ryanofsky> stickies-v, yeah not sure why that directory exists on windows, it just seems to be a quick of the installer
10:55 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-pr-reviews
10:55 < ryanofsky> abubakarsadiq, yeah I think that's the general think that makes me not worried about executing binaries on the PATH. but maybe we could be conservative and never do that, it's reasonable thing to consider
10:56 < hodlinator> yeah, better to add it later if needed.
10:56 < ryanofsky> 10. The PR adds an exemption in security-check.py because the wrapper contains no fortified glibc calls. Why does it not contain them, and would adding a trivial printf to bitcoin.cpp break reproducible builds under the current rules?
10:57 < emzy> abubakarsadiq: That's right. It needs some combination. Like some software allows to change (only) PATH. Looks like no problem at first.
10:58 < ryanofsky> I think that'll be the last question
10:58 < abubakarsadiq> yep unanswered yet :)
10:59 < ryanofsky> I think the answer adding is adding new calls should not break the build. If we add new calls they should be fortified based on build options.
10:59 < emzy> I worked in IT security. So I'm always (too) concerned. ;)
11:00 < abubakarsadiq> emzy: most of the times it's a good thing to.
11:00 < ryanofsky> Adding new calls should just allow the security-check.py exception to be removed. The exception is needed because it is checking for fortified symbols but the wrapper binary is so simple it doesn't contain any
11:01 < ryanofsky> Yeah it's good to be looking at security very closely in this realm
11:01 < ryanofsky> Thanks everybody for participating!
11:01 < ryanofsky> #endmeeting
11:01 < corebot> ryanofsky: Meeting ended at 2025-05-07T18:01+0000
11:01 < hodlinator> So it kind of expects fortified symbols and otherwise thinks it's gone insane?
11:01 < corebot> ryanofsky: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-pr-reviews.2025-05-07_17_00.log.json
11:01 < abubakarsadiq> thanks for hosting
11:01 < corebot> ryanofsky: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-pr-reviews.2025-05-07_17_00.log.html
11:01 < corebot> ryanofsky: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-pr-reviews.2025-05-07_17_00.html
11:01 < ryanofsky> hodlinator, yes exactly
11:01 < stickies-v> Thank you for hosting @ryanofsky and for guiding us through this new wrapper!
11:02 < Guest86> ryanofsky thanks
11:02 < hodlinator> makes sense.
11:02 < monlovesmango> thanks for hosting ryanofsky! really like the wrapper concept... even if a lot of this pr went over my head ahha
11:03 < ryanofsky> monlovesmango, next time ask questions! Or feel free anytime :)
11:03 < emzy> Thanks ryanofsky and everyone!
11:04 < hodlinator> Thanks ryanofsky! Made me consider more aspects of the PR (and look at it in the first place).
11:04 < monlovesmango> ryanofsky: just listening to all the other's questions was very enlightening :)
11:05 -!- caesrcd [~caesrcd@user/caesrcd] has quit [Quit: WeeChat 4.6.2]
11:05 -!- Guest86 [~Guest86@197.210.8.173] has quit [Quit: Client closed]
11:06 < ryanofsky> 👍
11:09 -!- joetor5 [~joetor5@user/joetor5] has quit [Remote host closed the connection]
11:15 -!- monlovesmango [~monlovesm@146.70.174.222] has quit [Quit: leaving]
11:37 -!- pablomartin4btc [~pablomart@217.130.254.81] has quit [Ping timeout: 252 seconds]
11:42 -!- pablomartin4btc [~pablomart@176.red-88-26-183.staticip.rima-tde.net] has joined #bitcoin-core-pr-reviews
11:46 < glozow> thanks ryanofksy!
12:11 -!- Guest80 [~Guest29@2600:1700:6973:5400:2459:4396:d8f2:898a] has joined #bitcoin-core-pr-reviews
12:24 -!- Talkless [~Talkless@138.199.6.197] has quit [Quit: Konversation terminated!]
12:37 -!- Santos81 [~Santos@32.141.102.6] has quit [Ping timeout: 240 seconds]
12:40 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:48 -!- pablomartin4btc [~pablomart@176.red-88-26-183.staticip.rima-tde.net] has quit [Remote host closed the connection]
12:48 -!- pablomartin4btc [~pablomart@176.red-88-26-183.staticip.rima-tde.net] has joined #bitcoin-core-pr-reviews
13:14 -!- pablomartin4btc [~pablomart@176.red-88-26-183.staticip.rima-tde.net] has quit [Ping timeout: 276 seconds]
13:30 -!- Guest80 [~Guest29@2600:1700:6973:5400:2459:4396:d8f2:898a] has quit [Ping timeout: 240 seconds]
13:33 -!- pablomartin4btc [~pablomart@66.red-79-151-104.dynamicip.rima-tde.net] has joined #bitcoin-core-pr-reviews
13:42 -!- pablomartin4btc [~pablomart@66.red-79-151-104.dynamicip.rima-tde.net] has quit [Quit: Leaving]
14:19 -!- dzxzg2 [~dzxzg@user/dzxzg] has joined #bitcoin-core-pr-reviews
14:20 -!- dzxzg [~dzxzg@user/dzxzg] has quit [Ping timeout: 268 seconds]
14:24 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
14:47 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-pr-reviews
14:48 -!- dzxzg2 [~dzxzg@user/dzxzg] has quit [Ping timeout: 252 seconds]
14:52 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
14:54 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Client Quit]
15:03 -!- dzxzg [~dzxzg@user/dzxzg] has quit [Ping timeout: 272 seconds]
15:17 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
15:18 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Client Quit]
15:29 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has joined #bitcoin-core-pr-reviews
15:57 -!- pyth [~pyth@user/pyth] has joined #bitcoin-core-pr-reviews
17:02 -!- danoprey [~danoprey@173.56.38.77] has joined #bitcoin-core-pr-reviews
17:18 -!- pyth [~pyth@user/pyth] has quit [Remote host closed the connection]
17:39 -!- pyth [~pyth@user/pyth] has joined #bitcoin-core-pr-reviews
17:41 -!- S3RK [~S3RK@user/s3rk] has joined #bitcoin-core-pr-reviews
17:43 -!- grettke [~grettke@syn-184-055-133-000.res.spectrum.com] has quit [Quit: grettke]
17:44 -!- S3RK_ [~S3RK@user/s3rk] has quit [Ping timeout: 244 seconds]
17:59 -!- pyth [~pyth@user/pyth] has quit [Read error: Connection reset by peer]
18:00 -!- pyth [~pyth@user/pyth] has joined #bitcoin-core-pr-reviews
18:24 -!- brunoerg [~brunoerg@2804:14d:5285:84b2::1000] has joined #bitcoin-core-pr-reviews
18:28 -!- brunoer__ [~brunoerg@187.183.60.153] has quit [Ping timeout: 252 seconds]
18:28 -!- pyth [~pyth@user/pyth] has quit [Ping timeout: 244 seconds]
20:50 -!- BUSY [~BUSY@user/busy] has quit [Quit: Leaving]
23:53 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
23:56 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
--- Log closed Thu May 08 00:00:37 2025