19:00:38 <wumpus> #startmeeting 
19:00:39 <core-meetingbot> Meeting started Thu Jan 21 19:00:38 2021 UTC.  The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:39 <core-meetingbot> Available commands: action commands idea info link nick
19:00:41 <jonasschnelli> hi
19:00:51 <hebasto> hi
19:00:54 <meshcollider> hi
19:00:56 <fjahr> hi
19:00:57 <wumpus> #bitcoin -core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
19:00:57 <sipa> hi
19:00:58 <jonatack> hi
19:00:59 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
19:00:59 <achow101> hi
19:01:01 <jb55> hi
19:01:16 <MarcoFalke> ai
19:01:24 <glozow> hai
19:01:34 <aj> yohoho
19:01:46 <b10c> hi
19:01:53 <jnewbery> hi
19:02:29 <wumpus> two proposed topics for this week: Thoughts on a future IRC meeting discussing taproot activation? (benthecarman), USDTs (User Statically Defined Traces) tracepoints in Core (b10c)
19:03:56 <wumpus> but let's start with high priority for review
19:04:02 <wumpus> #topic High priority for review
19:04:02 <core-meetingbot> topic: High priority for review
19:04:30 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  11 blockers, 1 bugfix, 2 chasing concept ACK
19:04:49 <wumpus> anything to add/remove or that is (in your opinion) ready for merge?
19:05:09 <promag> hi
19:06:06 <wumpus> looks like not :)
19:06:36 <wumpus> #topic USDTs (User Statically Defined Traces) tracepoints in Core (b10c)
19:06:36 <core-meetingbot> topic: USDTs (User Statically Defined Traces) tracepoints in Core (b10c)
19:06:58 <b10c> While #19866 is merged, I agree with jnewbery's comment in #20960 that there should be an approach discussion before adding USDTs all over the code.
19:07:01 <wumpus> this would continue  #19866
19:07:02 <gribble> https://github.com/bitcoin/bitcoin/issues/19866 | eBPF Linux tracepoints by jb55 · Pull Request #19866 · bitcoin/bitcoin · GitHub
19:07:03 <gribble> https://github.com/bitcoin/bitcoin/issues/20960 | doc: Add tracing.md, documenting eBPF tracing by laanwj · Pull Request #20960 · bitcoin/bitcoin · GitHub
19:07:04 <gribble> https://github.com/bitcoin/bitcoin/issues/19866 | eBPF Linux tracepoints by jb55 · Pull Request #19866 · bitcoin/bitcoin · GitHub
19:07:30 <wumpus> I tried to document a bit in #20960
19:07:31 <gribble> https://github.com/bitcoin/bitcoin/issues/20960 | doc: Add tracing.md, documenting eBPF tracing by laanwj · Pull Request #20960 · bitcoin/bitcoin · GitHub
19:07:42 <bitcoin-git> [bitcoin] dongcarl opened pull request #20980: guix: Test security-check sanity before performing them (master...2020-12-guix-mingw-extra-flags) https://github.com/bitcoin/bitcoin/pull/20980
19:08:26 <b10c> I personally do think it makes sense to add USDTs when there is a real longer-term use-case and user. Some example script using the USDT are always good too
19:08:36 <jonasschnelli> are traces also supported on macOS?
19:08:37 <wumpus> yes, agree with that
19:08:43 <wumpus> jonasschnelli: no, this is a linux thing
19:08:54 <b10c> for ad-hoc tracing/debugging either uprobes or temporary USDT probes can be used
19:09:08 <wumpus> that was my point in https://github.com/bitcoin/bitcoin/pull/19866#issuecomment-717128433 as well
19:09:13 <jb55> the motivating example was to not have invasive logging code for everything that needs tracing, like logging raw net msgs. we can utilize tracepoints for that.
19:09:25 <jb55> and they are nice since they are scriptable
19:09:42 <wumpus> to have some dedicated static probe point handy for common tasks like logging packets, and collecting statistics (e.g. like the statoshi fork)
19:09:54 <wumpus> yes
19:10:02 <jb55> but yeah linux only (and in theory macos but I haven't tested that)
19:10:24 <wumpus> in any case in other platforms they're simply not compiled in
19:11:09 <wumpus> I'm not sure what there's actually to discuss here, it seems we agree
19:12:03 <jb55> I think the general pattern should be pass in any raw struct args that might be useful for bcc scripts/etc. then maybe helper arguments for simpler bpftrace scripts
19:12:06 <jonasschnelli> I think this would simplify things like getting a mempool fee histogram (15836). Concept ack.
19:12:22 <b10c> jnewbery's point was to not have to many so the code becomes undreable
19:12:50 <wumpus> i agree, that should not be the idea
19:13:15 <wumpus> also they need to be documented, so that they can be used without consulting the source code (that was my point with tracing.md)
19:13:21 <b10c> I'd be happy to open an issue to collect possible traces
19:13:31 <b10c> wumpus yeah, agree
19:13:35 <wumpus> sounds good to me
19:13:53 <jb55> the network code one will be useful, and connectblock was useful for IBD benchmarks
19:14:02 <b10c> collect and discuss ofc
19:14:03 <jnewbery> jb55: I don't think BPF should be seen as an alternative to message dumping. I think they serve different purposes in different situations
19:14:04 <wumpus> and yes, the idea will be to have their interface, more or less, stable
19:14:19 <jb55> wumpus: :+1:
19:14:54 <wumpus> this means something like statoshi can be built withou having to rebase every version, otherwise one might as well use gdb breakpoints on specific functions/code lines
19:14:56 <jb55> jnewbery: yes its complimentary
19:15:15 <wumpus> BPF can be used for packet dumping and much more (even packet manipulation IIRC)
19:16:20 <jnewbery> the nice thing about message dumping as regular functionality is that it can be turned on/off by regular users on any platform
19:16:36 <jnewbery> BPF can do much more powerful things, but requires a bit of specialized knowledge
19:17:14 <jnewbery> Do we know what other projects do? Do they have USDT tracepoints in their master branch?
19:17:20 <wumpus> yes, that's fine, I don't think it has to be one or the other, though I would prefer not to add and maintain a complete tracing infrastructure inside bitcoin core when there are existing solutions, but if it has a clear scope, sure
19:17:39 <wumpus> yes, many daemon software does
19:17:43 <jonasschnelli> DTrace is available on macOS,.. does this mean it would be conceptually possible to extend this to macOS as well?
19:17:50 <jb55> yes
19:17:58 <wumpus> jonasschnelli: it's conceptually possible to extend it to solaris and macos
19:18:06 <jonasschnelli> ok
19:18:09 <wumpus> and freebsd probably
19:18:14 <jb55> it uses the same macros that should place dtrace probes, but I haven't tested
19:18:31 <b10c> NodeJS and V8 are two examples where USDTs are in 'master'
19:19:27 <jnewbery> Great. This is all pretty new to me, but it's very exciting. Thanks jb55, b10c and wumpus for working on it!
19:19:43 <jonasschnelli> sys/sdt.h is available on mac (includes mach/machine/sdt.h)
19:19:47 <jonasschnelli> DTRACE_PROBE is defined
19:19:48 <luke-jr> b10c: not exactly a project I'd want to imitate :P
19:20:02 <jnewbery> Lots of great resources here: http://brendangregg.com/ for people who want to learn more about BPF
19:20:04 <b10c> luke-jr: agree :)
19:20:14 <luke-jr> (it's also only one example: NodeJS is an extension to V8)
19:20:21 <wumpus> luke-jr: would agree, except in one sense: v8 is extremely performance focused
19:20:29 <luke-jr> wumpus: true
19:20:34 <luke-jr> mind you I'm not objecting
19:21:19 <wumpus> USDT's are very lightweight which makes them useful for counting/measuring things which might otherwise give too much overhead
19:22:51 <jb55> they are basically nops until the kernel hooks into it afaik
19:22:53 <wumpus> okay, I'm not exactly sure about the taproot topic, benthecarman isn't here
19:23:45 <luke-jr> basically the idea is to schedule a day to finish the BIP/code reviews and make a formal proposal; not really a dev topic though
19:23:58 <luke-jr> well, code review is of course
19:24:16 <fjahr> IMHO the main conversation should be on the mailing list. Allows more people to participate due to it being async.
19:24:21 <luke-jr> but not sure there's anything for _this_ meeting
19:24:29 <wumpus> luke-jr: I agree
19:24:42 <jonasschnelli> --enable-ebpf works out of the box on macOS
19:24:52 <luke-jr> fjahr: the idea was simply to get us to the starting poitn for the ML
19:24:55 <wumpus> jonasschnelli: wow!
19:25:03 <michaelfolkson> A lot easier to hammer things out in a meeting and then communicate with the ML
19:25:10 <fjahr> luke-jr: ok, that's great
19:25:35 <luke-jr> BIP finalised + code reviewed + some idea what to do for activation, then propose that to the ML for further comment
19:26:47 <michaelfolkson> Just need to get date, time finalized. Could communicate that to mailing list and taproot activation channel
19:28:03 <wumpus> ok, that concludes the topic as far as this meeting goes, i guess
19:28:31 <wumpus> any other topics?
19:28:49 <jb55> jonasschnelli: good to know! very cool.
19:29:25 <nickler> luke-jr: what are the relevant PRs and issues? The two from aj to the BIP8 and your #19573?
19:29:27 <gribble> https://github.com/bitcoin/bitcoin/issues/19573 | Replace unused BIP 9 logic with draft BIP 8 by luke-jr · Pull Request #19573 · bitcoin/bitcoin · GitHub
19:29:32 <luke-jr> nickler: yes
19:31:45 <luke-jr> (obviously aj's BIP PRs may require changes to my code PR)
19:32:38 <nickler> the PRs are https://github.com/bitcoin/bips/pull/1020 and https://github.com/bitcoin/bips/pull/1021 for the record
19:32:43 <luke-jr> ty
19:32:52 <michaelfolkson> And needs to be US and Aus friendly time?
19:33:08 <aj> luke-jr: haven't checked in a while, but i think the code changes for the bip updates are in the reviews on 19573
19:33:43 <aj> luke-jr: (this time on a different day seemed to work ok for the taproot reviews fwiw; not great for .au/asia but *shrug*)
19:34:05 <luke-jr> weekday or weekend? :P
19:34:17 <michaelfolkson> Next week? Week after?
19:35:38 <michaelfolkson> Maybe Tuesday 26th Jan or Tuesday 2nd February?
19:36:15 <luke-jr> fine with me
19:37:01 <luke-jr> if peopel can't make it, we can always do a 2nd meeting *shrug*
19:37:19 <fjahr> Maybe give a channel for people to post their thoughts beforehand if they can't join
19:37:20 <michaelfolkson> Ok let's say Tuesday 2nd February. Give some time to get the word out. Same time as this meeting.
19:37:35 <michaelfolkson> There is the ##taproot-activation channel
19:37:53 <luke-jr> someone want to mail the ML?
19:38:08 <michaelfolkson> In the absence of other volunteers I'm happy to
19:38:44 <michaelfolkson> Just the links that nickler shared?
19:39:03 <nickler> perhaps also good to add link to bitcoin wiki page and aj's post
19:39:17 <luke-jr> good idea, then there's a wiki page to add more info to
19:39:18 <michaelfolkson> Right ok, I've got them
19:39:32 <luke-jr> nickler: there's also the code, after the BIP reviews
19:39:49 <luke-jr> err michaelfolkson: *
19:40:34 <michaelfolkson> Ok I'll share some of the links on the ##taproot-activation channel and if I miss any please add more before I send to the mailing list
19:40:59 <michaelfolkson> Can take it to that channel from here
19:41:29 <sipa> i think that makes sense
19:41:40 <sipa> this isn't just a bitcoin core thing
19:41:46 <wumpus> right
19:43:58 <wumpus> any other topics?
19:45:14 <michaelfolkson> Not from me
19:45:20 <wumpus> #endmeeting