--- Log opened Wed Dec 15 00:00:01 2021
00:51 -!- meshcollider [meshcollid@jujube.ircnow.org] has quit [Changing host]
00:51 -!- meshcollider [meshcollid@user/meshcollider] has joined #bitcoin-core-pr-reviews
01:03 -!- zonemix [~zonemix@216.16.35.204] has quit [Ping timeout: 252 seconds]
01:20 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
01:29 -!- b10c [uid500648@id-500648.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
02:09 -!- zonemix_ [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
02:11 -!- zonemix [~zonemix@216.16.35.204] has quit [Ping timeout: 260 seconds]
02:21 -!- zonemix_ [~zonemix@216.16.35.204] has quit [Ping timeout: 252 seconds]
02:50 < michaelfolkson> Can you only use USDT in Core GUIX builds? Any technical reason for this? Only GUIX builds for Linux platforms contain USDT tracepoints?
02:53 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
02:56 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
03:00 -!- zonemix [~zonemix@216.16.35.204] has quit [Ping timeout: 260 seconds]
03:07 < michaelfolkson> I think the answer is no it doesn't need to be a GUIX build
03:09 < michaelfolkson> USDT aren't (yet) supported on MacOS (if that saves anyone some time)
03:13 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
04:05 < stickies-v> Huh. Did today's PR change? I thought it was https://github.com/bitcoin/bitcoin/pull/23624 but the website is showing otherwise: https://bitcoincore.reviews/23724
04:07 < stickies-v> nvm, found it: https://github.com/bitcoin-core-review-club/website/commit/b1a75b0e44c82f8324b4dd1a0df5c68052b24aa9
04:18 -!- zonemix [~zonemix@216.16.35.204] has quit [Ping timeout: 250 seconds]
04:19 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
05:29 -!- zonemix [~zonemix@216.16.35.204] has quit [Ping timeout: 252 seconds]
06:21 -!- zonemix [~zonemix@138.247.240.137] has joined #bitcoin-core-pr-reviews
06:58 -!- harding [quassel@newmail.dtrt.org] has quit [Ping timeout: 252 seconds]
06:58 -!- harding [~quassel@newmail.dtrt.org] has joined #bitcoin-core-pr-reviews
07:17 -!- gleb74 [~gleb@178.150.137.228] has quit [Ping timeout: 240 seconds]
07:50 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 256 seconds]
08:00 < michaelfolkson> stickies-v: Very ambitious Christmas schedule. Core PR review club never takes a week off
08:21 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
08:33 < b10c> michaelfolkson: correct! you can have the tracepoints in all builds, this just makes them available for GUIX builds. And only Linux is supported currently
08:34 < b10c> stickies-v: sorry for the confusion, yes we changed from 23624 -> 23724
08:41 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
08:45 < michaelfolkson> b10c: Cool, thanks. "Systemtap's sys/sdt.h header is required to build Bitcoin Core with USDT support." in PR description should make it clear the build is a GUIX build then (I think)
08:45 -!- gleb74 [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews
08:46 < michaelfolkson> You don't need Systemtap's sys/sdt.h header for a non-GUIX build with USDT support
08:47 < b10c> You need the sys/sdt.h header file for a non-GUIX build too
08:48 -!- merkle_noob [~merkle_no@129.0.212.207] has joined #bitcoin-core-pr-reviews
08:51 -!- merkle_noob [~merkle_no@129.0.212.207] has quit [Client Quit]
08:52 < b10c> e.g. on Debian/Ubuntu the header file is included in the systemtap-sdt-dev package. When installed, your non-GUIX build includes the tracepoints. If not installed, your builds don't include the tracepoints
08:53 < michaelfolkson> Ohhh ok, also says that here https://github.com/bitcoin/bitcoin/pull/19866#issuecomment-687199010
08:54 < michaelfolkson> It is just you installed it manually to get #19866 to work
08:55 < b10c> correct! (although #19866 didn't include any tracepoints yet; merged in #22006)
08:56 -!- ragu3 [~ragu@pool-173-68-65-85.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
08:57 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
08:59 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:00 < b10c> #startmeeting
09:00 < svav> Hi
09:00 < michaelfolkson> hi
09:00 < effexzi> Hi
09:00 < b10c> feel free to say hi so we know you'r here! (lurking is also fine)
09:00 < zonemix> hi
09:01 -!- azor [~azor@201.211.42.197] has joined #bitcoin-core-pr-reviews
09:01 < b10c> anyone joining the PR review club for the first time?
09:01 -!- observer55 [~observer@cpe-23-242-148-67.socal.res.rr.com] has joined #bitcoin-core-pr-reviews
09:01 < zonemix> yep this is my first time
09:01 < b10c> welcome zonemix! feel free to ask questions anytime :)
09:01 < glozow> hi!
09:01 < ragu3> first timer here. hi:)
09:02 < glozow> zonemix: ragu3: welcome!
09:02 < b10c> welcome ragu3!
09:02 < b10c> today we are looking at https://github.com/bitcoin/bitcoin/pull/23724
09:02 < b10c> notes are here: https://bitcoincore.reviews/2372
09:03 < b10c> Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?
09:03 < svav> n but I read the notes
09:03 < michaelfolkson> Definite Concept ACK. "light conceptual agreement" undersells it :)
09:03 < azor> Hi everyone
09:04 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
09:04 < b10c> hi azor!
09:05 < michaelfolkson> Not sure whether this should be fixed first "The tracepoints are currently not automatically/CI tested" before this is merged (but I think that is a later question on Approach ACK/NACK)
09:05 < glozow> stickes-v: yes sorry, i should have posted an announcement about the PR change
09:05 < glozow> (re: convo from earlier)
09:05 < b10c> Did you manage to build a bitcoind binary including the tracepoints? Quick no/build/build-guix
09:06 < svav> no did not have time
09:06 < michaelfolkson> No, away from my Linux machine
09:06 < ccdle12> build-guix
09:06 < merkle_noob[m]> Hi everyone
09:07 < b10c> svav michaelfolkson: that's fine
09:07 < b10c> ccdle12: did you check if the binaries include the tracepoints?
09:08 < ccdle12> b10c: I used gdb to check the the list of probes?
09:08 < b10c> ccdle12: awesome!
09:08 < ccdle12> I ran log_p2p_traffic on signet and that worked, but the other didnt work for me, I assumed it was my machine :(
09:09 < b10c> ohh, which one didn't work?
09:09 < ccdle12> log_utxos was getting segfault
09:09 < ccdle12> and the python scripts that relied on bcc
09:10 < ccdle12> but I think thats because I probably didn't install some of the bcc dependencies correctly
09:11 < b10c> maybe, happy to debug that further later if you want. Saw some reports of people having issues with old bpftrace versions (e.g. the segfault)
09:11 -!- yo_soy [~yo_soy@172.92.166.62] has joined #bitcoin-core-pr-reviews
09:11 < ccdle12> ahh ok sounds great, I havne't dug too deeply into it yet so didn't want to start giving false reports :)
09:12 < b10c> michaelfolkson: yes, that's a valid point. I've added "not tested by CI" on purpose to maybe only merge this PR once that's setup..
09:12 < b10c> next question: For GUIX builds, why do we need to add the Systemtap sys/std.h header as a dependency instead of using the header file avaliable on the GUIX build host system?
09:14 < michaelfolkson> Because it needs to be present during compilation?!
09:14 < michaelfolkson> Don't know
09:15 < svav> Because the header needs to be a special one that contains something that makes something get built
09:15 -!- observer55 [~observer@cpe-23-242-148-67.socal.res.rr.com] has quit [Ping timeout: 250 seconds]
09:16 < b10c> We can't really assume that a user has the systemtap header or even the right version on the GUIX build host
09:16 < b10c> we want the builds to be deterministic for all GUIX builders, so can't rely on host system software
09:16 < glozow> gotta be d e t e r m i n i s t i c
09:16 < b10c> glozow: 💯
09:17 < b10c> GUIX builds are done in a GUIX container. this, for example, makes sure no host dependencies leak into the build
09:18 < b10c> now an autotools question: In which build step is ENABLE_TRACING set? Under which condition is it set? What happens when it’s set to 1?
09:19 < michaelfolkson> For the first timers Optech page on reproducible builds: https://bitcoinops.org/en/topics/reproducible-builds/
09:19 -!- bob_the_builder [~bob_the_b@fttx-pool-185.53.43.125.bambit.de] has joined #bitcoin-core-pr-reviews
09:20 < svav> Re sys/std.h dependency, as you saying in a GUIX build, when you set it as a dependency, it will look for sys/std.h within the specific GUIX container?
09:21 < svav> *are you saying*
09:21 < glozow> ehhhh when making configure from configure.ac?
09:22 < b10c> svav: yes! we first build the depends and then copy them as _inputs_ for our Bitcoin Core build
09:22 < michaelfolkson> https://github.com/bitcoin/bitcoin/blob/42796742a45e3f12e82588afa77054c103fca05c/configure.ac#L1354
09:22 < b10c> sys/sdt.h is one of those depends
09:23 < b10c> (being added as one of those depends in this PR)
09:23 -!- jb55 [~jb55@S0106606c634dbdd3.vc.shawcable.net] has joined #bitcoin-core-pr-reviews
09:23 < b10c> michaelfolkson glozow: correct! what does this "AC_COMPILE_IFELSE" do?
09:24 < glozow> uhhhh i guess it tells autoconf something
09:24 < b10c> it includes the sys/sdt.h header and uses something that's named "DTRACE_PROBE", what could that be?
09:25 < glozow> https://github.com/bitcoin/bitcoin/blob/42796742a45e3f12e82588afa77054c103fca05c/configure.ac#L1349-L1357
09:25 < glozow> "hi autoconf, if sys/sdt.h is included and something, set ENABLE_TRACING=1 in configure script"
09:25 < ccdle12> compile the input below to check if we have the depdency for sdt
09:25 < merkle_noob[m]> From the PR, ENABLE_TRACING is set when sys/sdt.h is found and/or when use_usdt is set to yes.
09:25 < b10c> correct!
09:26 < b10c> we try to compile a small (2 loc) program during configure. that program includes sys/sdt.h and a simple tracepoint (the DTRACE_PROBE(context, event))
09:27 < michaelfolkson> Why include a simple tracepoint? To check if it is working?
09:28 < b10c> if this succeeds, we set ENABLE_TRACING to 1. We can we have the sys/sdt.h header and that it makes sense to it
09:28 < svav> DTrace provides a facility for user application developers to define customized probes in application code
09:29 -!- observer51 [~observer@cpe-23-242-148-67.socal.res.rr.com] has joined #bitcoin-core-pr-reviews
09:30 < b10c> michaelfolkson: good question! there was a problem with a more primitive detection method of just checking for the header. see https://github.com/bitcoin/bitcoin/pull/22238
09:31 < b10c> svav: the DTrace naming here is confusing.. DTRACE_PROBE is in-fact an alias for a Systemtap probe for compability reasons (see sys/sdt.h)
09:32 < b10c> so when ENABLE_TRACING is set to 1, we define the TRACEx macros in https://github.com/bitcoin/bitcoin/blob/master/src/util/trace.h
09:32 < svav> b10c: You are saying DTrace and Systemtap are two different things?
09:33 < b10c> otherwise they are undefined and no tracepoints are included in the binary
09:34 < b10c> svav: yes. AFAIK DTrace is older and from Sun, Systemtap was developed specifically for Linux. There exists some interoperability between the too, but I haven't tested anything in this direction
09:35 < b10c> feel free to ask about the configure step. I'll continue with the next question in the meantime
09:35 < b10c> What do we need to have consensus on before this PR is merged?
09:35 < b10c> What should we test before this PR is merged?
09:37 < michaelfolkson> Well to state the obvious that the Systemtap header is sufficient to get tracepoints working
09:37 < svav> I don't run a Bitcoin node yet, but I'm thinking about it ... Presumably for all this Pull Request testing, people set up separate test environments that don't affect your main node, so what sort of technology is necessary for test environments? Thanks.
09:37 -!- observer51 [~observer@cpe-23-242-148-67.socal.res.rr.com] has quit [Quit: Connection closed]
09:37 < michaelfolkson> Including the header shouldn't have any adverse impacts on non-users of tracepoints
09:38 < michaelfolkson> "Merging this now could leave us with broken tracepoints in a release build." <- You wouldn't want broken tracepoints
09:38 < b10c> michaelfolkson: right, probably also that we don't break and platforms (for whatever reasons, I don't expect that we break anything)
09:39 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 256 seconds]
09:40 < b10c> also right. I think we should be able to get some consensus on including the tracepoints in release builds here
09:41 < michaelfolkson> svav: I think it varies widely. I have a Linux laptop and Mac laptop for dev stuff. But others will use VMs, VPS, Docker etc
09:41 < b10c> svav: yes I run a few nodes in test setting but also for development
09:41 < b10c> in a*
09:42 < svav> So, can you run multiple bitcoind on the same computer if you set some as test environments, or do you need to use virtual environments for each bitcoind?
09:43 < b10c> I also think we should have a bit more confidence that the tracepoints aren't broken by automatically testing them in the CI (or similar). michaelfolkson mentioned this earlier
09:43 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: Client closed]
09:44 < b10c> svav: yes, you can run multiple, even multiple on mainnet. You'll need to set different ports and data directories though 
09:44 < b10c> The next question is a hard one:
09:44 < svav> b10c: ok thanks
09:44 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews
09:44 < b10c> Why can we skip configure and make for the Systemtap dependecy? What are the problems and how are they solved?
09:45 < michaelfolkson> b10c: How do you test them in the CI? Add a tracepoint test?
09:47 < b10c> michaelfolkson: yes, e.g. in the Python test suite. It's a bit tricky as you need special permissions to hook into the tracepoints, but I think it's doable. See https://github.com/bitcoin/bitcoin/issues/23296
09:49 < b10c> We can (and want to) skip configure and make for systemtap as we only need the header file, we don't need the systemtap tool for our build
09:49 < michaelfolkson> Ok cool, so the plan is to add them in this PR or a separate PR? I guess that gets the Approach ACK for me
09:50 < b10c> We don't want to build stuff we don't end up using in our build. That just wastes resources
09:50 < b10c> michaelfolkson: in a separate PR, that's not in-scope for GUIX builds
09:51 < merkle_noob[m]> Exactly the answer I wanted to give :)
09:51 < b10c> the problem with the sys/sdt.h header file is it includes a sdt-config.h which is only created in the configure step..
09:52 < b10c> sdt-config.h defines if an assembly feature can be used.
09:52 < b10c> This feature check was added in 2010 and we assume the feature can be used
09:52 < b10c> We apply a patch to the sys/sdt.h file that allows us to use it without the configure step.
09:53 < b10c> any questions regarding this?
09:54 < merkle_noob[m]> b10c: Please, could that assumption be broken?
09:54 < svav> Is an assembly feature referring to a specific assembly or the concept of an assembly?
09:55 < merkle_noob[m]> Or under what circumstances could the assumption not hold?
09:55 < b10c> yes, it can. I sadly haven't found any documentation on that feature being added to gcc (all documentation I saw just lists it as 'this is supported')
09:56 < b10c> maybe on some very old GCC version or uncommon platform/architecture?
09:56 < merkle_noob[m]> b10c: OK I see. Thanks.
09:57 < b10c> svav: a feature of the byte code assembly, does this answer your question?
09:57 < b10c> last question: Can you verify that the tracepoints are NOPs in the binaries? If yes, how?
09:58 < svav> b10c: yes thanks
09:59 < b10c> We can use `readelf -n bitcoind` or `info probe` in gdb to list the locations of the tracepoints in the binary.
09:59 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
09:59 < b10c> and then, for example, gdb to show us the assembly (byte code) at the tracepoint location
09:59 < svav> Does NOP stand for Non Op Code? Why is it important that a tracepoint is a NOP?
10:00 < b10c> or `objdump -d` works too
10:00 < b10c> I have notes for this here: https://gist.github.com/0xB10C/0edbbbe462fc70a0c298f64aa73ff37c
10:00 < b10c> svav: yes, a NOP does _nothing_
10:01 < michaelfolkson> no-op (no operation)
10:01 < b10c> the tracing uses it to hook into that exact instruction
10:01 < b10c> #endmeeting
10:02 < svav> Thanks b10c and all
10:02 < b10c> Thanks everyone! I'm around for further questions, otherwise feel free to comment on the PR!
10:02 < michaelfolkson> In Bitcoin script we also use it to describe an opcode that does nothing
10:02 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:02 < glozow> thank you b10c!
10:02 < ccdle12> thanks b10c!
10:03 < b10c> ccdle12: let me know if you still want to debug something :)
10:03 < svav> So, you are saying tracepoints need to be a NOP so that they do not cause bugs or security holes in the bitcoind program?
10:03 < merkle_noob[m]> Thanks b10c ,and everyone. The meeting was very instructive. 
10:03 < ccdle12> b10c: sounds good! I think you mentioned others were having trouble with older versions of bpftrace? (my version is 0.13.0)
10:04 < michaelfolkson> svav: Users not using tracepoints should not be affected by their presence. Right b10c? That's the NOP point
10:05 < merkle_noob[m]> svav: It seems that is to avoid a lot of additional expensive computations...
10:06 < svav> ok thanks guys
10:06 < b10c> svav: no, not really security holes or bugs. Using a NOP means there is just nothing done if we don't hook into this NOP instruction. If we hook into the NOP, we execute an eBPF code in the kernel that processes the tracepoint arguments. We did an earlier review club on this if you'r interested:
10:06 < b10c> https://bitcoincore.reviews/22006
10:06 < svav> ok thanks
10:07 < b10c> ccdle12: oh, I'm running v0.12.1
10:07 < michaelfolkson> Thanks b10c!
10:07 < b10c> let me see what the other reports were running
10:07 < merkle_noob[m]> b10c please correct me if I'm wrong😅
10:08 -!- ragu3 [~ragu@pool-173-68-65-85.nycmny.fios.verizon.net] has quit [Quit: Connection closed]
10:09 < b10c> merkle_noob[m]: you'r right, we try to avoid that. that code is executed regardless of us hooking into the tracepoint
10:09 -!- azor [~azor@201.211.42.197] has quit [Quit: Connection closed]
10:10 < b10c> so non-tracing users (the majority) would have worse performance if we'd do expensive computations for the tracepoints 
10:10 < merkle_noob[m]> b10c: Thanks(and thanks for the additional explanation).
10:16 < b10c> ccdle12: found it. theStack reported issues with bpftrace here: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-11-16#738199
10:17 < b10c> but I think he was using v0.11.3 
10:17 < b10c> I'll see if v0.13 also segfaults for me
10:18 < ccdle12> b10c: awesome thank you
10:18 < ccdle12> that would be great
10:18 < ccdle12> I'll see if I can downgrade to v12
10:19 < b10c> (bpftrace has been causing a few problems, we might want to drop support for it if this continues 😬)
10:19 < ccdle12> oh, do you have another program in mind that could replace it?
10:20 < b10c> ccdle12: thanks! you mentioned that one of the tracepoints did work (that at least shows the tracepoints aren't broken)?
10:20 < b10c> scripts did work* I mean
10:21 < ccdle12> yup the trace points are there and the only script working for me was log_p2p_traffic.bt
10:21 < ccdle12> (tested on synced signet)
10:21 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Read error: Connection reset by peer]
10:21 < b10c> ccdle12: nope, but just relying on bcc only... (but using bpftrace for smaller tracing scripts is very handy)
10:22 < b10c> did you get an error for the bcc python examples? 
10:23 < ccdle12> b10c: aah ok that makes sense, its nice that .bt scripts are pretty succint
10:24 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
10:25 < ccdle12> b10c: yeh the bcc lib was missing, hence why I initially thought it was something wrong with the way I installed the deps
10:26 < b10c> ok! do you mind sharing on what system/platform/os you'r testing?
10:26 -!- virtu [~virtu@p5b15bb6c.dip0.t-ipconnect.de] has quit [Quit: leaving]
10:27 < ccdle12> sure np, the machine I'm testing on is ubuntu 18.04.5
10:34 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
10:38 < b10c> thanks!
10:39 < ccdle12> no worries, thanks for the help! I'm currently building bpftrace from src for v12 and have incompatible bcc version sooo... I think this is prob the issue '=D
10:58 < ccdle12> b10c: not sure if you are still around but after downgrading to v12 for bpftrace, the other .bt scripts works (log_utxos and connectblock_benchmark)
10:59 < ccdle12> so maybe for atleast ubuntu 18 its only v12 that can work atm
10:59 < ccdle12> appreciate the help debugging!
11:00 < b10c> ccdle12: good to hear, thank you for testing. Bummer that something is broken with v13 as the 'new' version
11:02 -!- yo_soy [~yo_soy@172.92.166.62] has quit [Quit: Connection closed]
11:03 < ccdle12> yeh its not ideal, also building v12 on ubuntu18 required bcc v.0.8 .0 specifically as well
11:22 -!- jb55 [~jb55@S0106606c634dbdd3.vc.shawcable.net] has quit [Ping timeout: 256 seconds]
11:29 -!- esats [~esats@2601:47:4383:560:9c91:d395:c278:8723] has joined #bitcoin-core-pr-reviews
11:40 -!- zonemix [~zonemix@138.247.240.137] has quit [Remote host closed the connection]
11:41 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
11:48 -!- esats [~esats@2601:47:4383:560:9c91:d395:c278:8723] has quit [Quit: Client closed]
11:49 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
11:51 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
11:51 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Client Quit]
11:52 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
11:53 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
11:56 -!- zonemix [~zonemix@216.16.35.204] has quit [Ping timeout: 250 seconds]
12:05 -!- shiza is now known as pink_sarco
12:07 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
12:08 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
12:10 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
12:20 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 265 seconds]
12:36 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-pr-reviews
12:43 -!- emzy [~quassel@user/emzy] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
12:44 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: Client closed]
12:58 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
12:59 -!- emzy [~quassel@user/emzy] has joined #bitcoin-core-pr-reviews
12:59 -!- kcalvinalvin [~kcalvinal@ec2-52-79-199-97.ap-northeast-2.compute.amazonaws.com] has quit [Quit: ZNC 1.7.4 - https://znc.in]
13:00 -!- kcalvinalvin [~kcalvinal@ec2-52-79-199-97.ap-northeast-2.compute.amazonaws.com] has joined #bitcoin-core-pr-reviews
13:02 -!- zonemix [~zonemix@216.16.35.204] has quit [Ping timeout: 252 seconds]
13:03 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
13:31 -!- emzy [~quassel@user/emzy] has quit [Ping timeout: 250 seconds]
13:32 -!- emzy [~quassel@user/emzy] has joined #bitcoin-core-pr-reviews
13:39 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
14:02 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
14:47 -!- ozawa [~ozawa@cpe-98-14-66-91.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews
15:16 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
15:19 -!- zonemix [~zonemix@216.16.35.204] has quit [Remote host closed the connection]
15:19 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
15:20 -!- bob_the_builder [~bob_the_b@fttx-pool-185.53.43.125.bambit.de] has quit [Ping timeout: 256 seconds]
15:26 -!- zonemix [~zonemix@216.16.35.204] has quit [Ping timeout: 250 seconds]
15:39 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
15:44 -!- zonemix [~zonemix@216.16.35.204] has quit [Ping timeout: 256 seconds]
15:56 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
16:05 -!- gnusha [~gnusha@user/gnusha] has joined #bitcoin-core-pr-reviews
16:05 -!- Topic for #bitcoin-core-pr-reviews: Meeting every Wednesday at 17:00 | See https://bitcoincore.reviews/ for details | This channel is logged
16:05 -!- Topic set by jnewbery [] [Mon May 24 09:24:20 2021]
16:05 [Users #bitcoin-core-pr-reviews]
16:05 [ _0x0ff      ] [ fjahr         ] [ jrawsthorne     ] [ nickler       ] [ sipa      ] 
16:05 [ _aj_        ] [ gleb74        ] [ kanzure         ] [ notmandatory_ ] [ siv2r[m]  ] 
16:05 [ achow101    ] [ glozow        ] [ kcalvinalvin    ] [ ozawa         ] [ stick     ] 
16:05 [ ajonas      ] [ gnusha        ] [ laanwj          ] [ pg156         ] [ stick[m]  ] 
16:05 [ amiti       ] [ greypw254     ] [ larryruane      ] [ pinheadmz     ] [ stickies-v] 
16:05 [ andrewtoth_ ] [ harding       ] [ lightlike       ] [ pink_sarco    ] [ takinbo   ] 
16:05 [ avril       ] [ hebasto       ] [ livestradamus   ] [ provoostenator] [ TheRec    ] 
16:05 [ awesome_doge] [ Henry151      ] [ lsilva_         ] [ qubenix       ] [ theStack  ] 
16:05 [ b10c        ] [ hugohn        ] [ luke-jr         ] [ r-ush         ] [ uasf      ] 
16:05 [ belcher     ] [ jarolrod      ] [ MarcoFalke      ] [ raj           ] [ waxwing   ] 
16:05 [ blkncd      ] [ jb55          ] [ MatrixBot1234510] [ robertspigler ] [ willcl_ark] 
16:05 [ Common      ] [ jeremyrubin   ] [ merkle_noob[m]  ] [ robot-dreams  ] [ windsok   ] 
16:05 [ dergoegge   ] [ jkczyz        ] [ meshcollider    ] [ RubenSomsen   ] [ yakshaver ] 
16:05 [ djinni`     ] [ jnewbery      ] [ michaelfolkson  ] [ ryanofsky     ] [ yonson    ] 
16:05 [ emzy        ] [ johnzweng     ] [ Murch[m]        ] [ sandipndev123 ] [ Zenton    ] 
16:05 [ fanquake    ] [ jomat         ] [ mutatrum[m]     ] [ sanket1729_   ] 
16:05 [ fdov        ] [ jonasschnelli_] [ nathanael       ] [ sanket_cell_  ] 
16:05 [ FelixWeis   ] [ josibake      ] [ neha            ] [ schmidty      ] 
16:05 -!- Irssi: #bitcoin-core-pr-reviews: Total of 87 nicks [0 ops, 0 halfops, 0 voices, 87 normal]
16:05 -!- S3RK [~S3RK@user/s3rk] has joined #bitcoin-core-pr-reviews
16:05 -!- koolazer [~koo@user/koolazer] has joined #bitcoin-core-pr-reviews
16:06 -!- Channel #bitcoin-core-pr-reviews created Wed May 19 12:43:59 2021
16:08 -!- Irssi: Join to #bitcoin-core-pr-reviews was synced in 180 secs
16:10 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
16:33 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Ping timeout: 256 seconds]
17:21 -!- ozawa [~ozawa@cpe-98-14-66-91.nyc.res.rr.com] has quit [Quit: Connection closed]
17:22 -!- b10c [uid500648@ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
18:03 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Read error: Connection reset by peer]
18:05 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
18:09 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
18:09 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
18:13 -!- ozawa [~ozawa@cpe-98-14-66-91.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews
18:21 -!- zonemix [~zonemix@216.16.35.204] has quit [Read error: Connection reset by peer]
18:21 -!- zonemix_ [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
19:24 -!- zonemix_ [~zonemix@216.16.35.204] has quit [Remote host closed the connection]
19:25 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
19:49 -!- zonemix [~zonemix@216.16.35.204] has quit [Remote host closed the connection]
19:49 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
20:15 -!- zonemix [~zonemix@216.16.35.204] has quit [Remote host closed the connection]
20:16 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
20:22 -!- zonemix [~zonemix@216.16.35.204] has quit [Ping timeout: 240 seconds]
20:44 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
20:51 -!- ozawa [~ozawa@cpe-98-14-66-91.nyc.res.rr.com] has quit [Quit: Connection closed]
21:47 -!- zonemix [~zonemix@216.16.35.204] has quit [Ping timeout: 268 seconds]
22:16 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
22:22 -!- zonemix [~zonemix@216.16.35.204] has quit [Ping timeout: 240 seconds]
22:47 -!- zonemix [~zonemix@216.16.35.204] has joined #bitcoin-core-pr-reviews
23:51 -!- gleb74 [~gleb@178.150.137.228] has quit [Quit: Ping timeout (120 seconds)]
23:52 -!- gleb74 [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Dec 16 00:00:02 2021