19:00:08 <laanwj> #startmeeting 
19:00:08 <core-meetingbot> Meeting started Thu Sep 22 19:00:08 2022 UTC.  The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:08 <core-meetingbot> Available commands: action commands idea info link nick
19:00:24 <Murch> Hi
19:00:24 <hebasto> hi
19:00:25 <fanquake> hi
19:00:35 <luke-jr> hi
19:00:45 <laanwj> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard b10c BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo
19:00:46 <furszy> hi
19:00:47 <laanwj> moneyball morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:00:49 <laanwj> hi
19:00:52 <achow101> hi
19:01:04 <lightlike> hi
19:01:35 <glozow> hi
19:01:38 <amovfx_> hi
19:01:43 <laanwj> welcome to the weekly general bitcoin-core-dev meeting
19:02:02 <laanwj> on topic has been proposed: acceptable runtimes of new benchmarks (achow101)
19:02:06 <sipa> hi
19:02:10 <sipsorcery> hi
19:02:10 <laanwj> any lastminute ones?
19:03:04 <fanquake> rc1 bins!
19:03:08 <warren> hi
19:03:12 <laanwj> 24.0 was split off a few days ago, and v24.0rc1, so if you haven't yet please start your guix builder
19:03:27 <jonatack> hi
19:03:49 <amovfx_> is guix builder, just building with gui?
19:03:50 <fanquake> ~10 builders submitted sigs so far, and detached sigs are up for codesigning
19:03:50 <emzy> hi
19:04:23 <sipa> amovfx: guix is the build environment we use for deterministic/reproducible release binaries
19:04:32 <sipa> it is entirely unrelated to the gui
19:04:38 <laanwj> i think we'll want to go back to discussing high priority for review now that the branch was split off
19:04:43 <amovfx_> ty
19:04:43 <luke-jr> well, it does build the gui, but what sipa said otherwise ;p
19:05:03 <sipa> it also builds the non-gui!
19:05:06 <luke-jr> right
19:05:40 <sipa> https://github.com/bitcoin/bitcoin/blob/master/contrib/guix/README.md for more information
19:05:55 <jonatack> amovfx_: see contrib/guix/README.md
19:05:58 <laanwj> #topic High priority for review
19:05:58 <core-meetingbot> topic: High priority for review
19:06:08 <amovfx_> looking at that now, ty
19:06:10 <laanwj> https://github.com/orgs/bitcoin/projects/1 has 5 blockers, 3 chasing concept ACK
19:06:19 <laanwj> probably needs update
19:07:26 <laanwj> anything to add/remove?
19:07:36 <jonatack> #23433 may be getting close
19:07:36 <gribble> https://github.com/bitcoin/bitcoin/issues/23433 | Addrman unit test failures · Issue #23433 · bitcoin/bitcoin · GitHub
19:08:06 <jonatack> #23443 sorry
19:08:09 <gribble> https://github.com/bitcoin/bitcoin/issues/23443 | p2p: Erlay support signaling by naumenkogs · Pull Request #23443 · bitcoin/bitcoin · GitHub
19:08:19 <laanwj> great!!!
19:09:31 <fanquake> I'll probably throw #25391 back in now that we're branched off
19:09:33 <gribble> https://github.com/bitcoin/bitcoin/issues/25391 | guix: Use LTO to build releases by fanquake · Pull Request #25391 · bitcoin/bitcoin · GitHub
19:09:35 <fanquake> Most toolchain stuff is sorted now. The windows build is still a bit hairy, but otherwise this works, and is ready for more thoughts (in regards to release use) / benchmarking / review.
19:10:00 <laanwj> makes sense
19:10:14 <glozow> #25038 for me please!
19:10:17 <gribble> https://github.com/bitcoin/bitcoin/issues/25038 | policy: nVersion=3 and Package RBF by glozow · Pull Request #25038 · bitcoin/bitcoin · GitHub
19:10:26 <achow101> #23417 for me
19:10:28 <gribble> https://github.com/bitcoin/bitcoin/issues/23417 | wallet, spkm: Move key management from DescriptorScriptPubKeyMan to wallet level KeyManager by achow101 · Pull Request #23417 · bitcoin/bitcoin · GitHub
19:11:28 <laanwj> glozow: added-should it be for blockers or chasing concept ACK?
19:11:53 <glozow> laanwj: chasing concept ACK i think
19:12:05 <glozow> thanks :)
19:12:39 <laanwj> achow101: looks like it was already on the list?
19:13:15 <fanquake> laanwj: i may have just added it
19:13:38 <laanwj> okay!
19:14:51 <laanwj> anything else for high prio?
19:14:59 <laanwj> if not we'll go to next topic
19:15:26 <warren> (do I ask questions at the end?)
19:15:43 <laanwj> #topic acceptable runtimes of new benchmarks (achow101)
19:15:44 <core-meetingbot> topic: acceptable runtimes of new benchmarks (achow101)
19:16:25 <laanwj> warren: depends on the kind of question?
19:16:42 <laanwj> i mean if it's a big one then it'd make sense to make it a separate topic
19:16:51 <achow101> We've been adding some benchmarks for the wallet which run some pretty slow behavior. Since we run all of the benchmarks in make check, there's been some questions on how slow an entire benchmark can be, including setup and teardown
19:17:28 <sipa> we could run the make-check benchmarks with a lower -min-time ?
19:17:44 <sipa> Because we don't really care about the benchmarking aspect, just that the code gets exercised.
19:17:57 <lightlike> we only run one iteration already within "make check", right?
19:17:59 <laanwj> sipa: we already run them for one iteration
19:17:59 <sipa> I vaguely recall a PR that added an option for this actually.
19:18:09 <laanwj> sipa: the problem is that some tests take significant time per iteration
19:18:14 <sipa> oh
19:18:24 <sipa> i see
19:18:25 <achow101> there's the time per iteration, and also time for setting up the wallet
19:18:44 <achow101> e.g. a benchmark for a wallet with many txs also requires spending time before the benchmark making those txs
19:18:53 <laanwj> the original idea of the benchmarks was that iterations would take neglible time by themselves
19:19:24 <laanwj> but yes, that's different for the wallet ones
19:19:28 <sipa> right, the one-time setup cost per benchmark
19:19:40 <furszy> I think that achow101 refers to benchmarks that require time consuming setups, and not the process that gets timed.
19:20:19 <furszy> message got out late :p..
19:20:59 <fanquake> If benches are going to be considerably more expensive than the others, and not necessarily valuable for everyone to run every make check, we should gate them behind some flag / option
19:21:02 <lightlike> maybe have a set of "extended" benchmarks that are not part of "make check", similar to  the existing solution for long-running functional tests?
19:21:10 <fanquake> I don't think we want to add more weight to make check itself
19:21:28 <fanquake> There are already expensive things run there that ideally could be split out. i.e running libsecp test suite every time on never-changing code
19:21:30 <achow101> what's the purpose of running benchmarks in make check?
19:21:51 <sipa> making sure the benchmarks actually run
19:22:31 <sipa> i guess the policy (intentional or not) we have is that "make check" runs all compiled code we have?
19:22:45 <sipa> it doesn't run functional tests, but does run unit tests
19:22:49 <laanwj> right, there have been crashes in the benchmarks in the past, running them for one iteration makes sure thre are no obvious crashes at least
19:22:51 <_aj_> doesn't run the fuzz tests?
19:22:53 <sipa> and bitcoin-tx tests
19:23:15 <sipa> hmm, it doesn't run the fuzz tests, good point
19:23:20 <achow101> that could also be achieved with another ci job
19:23:48 <laanwj> the fuzz tests would reqiire external data (e.g. corpuses) so it's not very practical
19:23:50 <_aj_> would be nice to have 'make check' run the cheap benchmarks, at any rate?
19:23:54 <sipa> yeah the most important thing is that CI at least occasionally runs all benchmark code
19:24:48 <furszy> isn't the CI running in debug mode? (which makes benchmarks run much slower)
19:26:19 <achow101> yes, but slow CI is nothing new
19:28:15 <achow101> anyways, seems like the consensus is to have make check just not run all of the benchmarks
19:28:49 <laanwj> i think that's the only proposed solution, too
19:29:06 <sipa> i think that's reasonable
19:29:16 <warren> sounds like there should be different levels of "check"?
19:29:38 <jonatack> yes, as long as a CI task does run them
19:30:09 <warren> Somewhat related, when Fedora packaged bitcoin core they insisted on running "make check" during every package build. I tried to argue even Bitcoin Core's own binary distribution process doesn't do that because it's way too slow?
19:30:21 <furszy> if we have to run some of the benchmarks, couldn't we just run them in a different CI job without debug mode?
19:30:51 <warren> I didn't check for a year but at some point I had "make check" succeed on only faster machines but fail on slow machines due to a timeout of some sort, which would cause the Fedora package build to fail.
19:31:03 <achow101> furszy: I think we would still want debug enabled as debug will also execute code that we may care about
19:31:20 <achow101> (since the purpose is to look for crashes/programming errors rather than actually benchmarking)
19:31:34 <warren> I suppose "make check" failing on a slow machine with a timeout should be considered a bug?
19:31:38 <jonatack> at least benchmarks ran last, so on my slow laptop, i would halt the make check run at the benchmark step
19:31:51 <furszy> achow101: hmm k
19:32:06 <laanwj> warren: yes, imo
19:32:16 <laanwj> warren: but it would be fixed by the same solution proposed now
19:32:21 <warren> nice
19:32:41 <achow101> I don't think guix runs any of the tests or benchmarks?
19:32:59 <achow101> other than symbol and security checks
19:33:01 <laanwj> no, guix doesn't
19:33:03 <sipa> really?
19:33:09 <laanwj> it woudn't make much sense with cross compiling
19:33:14 <warren> yeah, can we have an official recommendation for distros "we don't recommend using make check since we don't use it in our own binary distro procedure"?
19:33:15 <sipa> we don't run the tests in guix builds?
19:33:28 <sipa> ah, yeah, cross compilation is an issue
19:34:01 <sipa> @warren as far as i'm concerned, that's up to them
19:34:02 <laanwj> wait, we absolutely recommend runing make check
19:34:04 <laanwj> if you can
19:34:09 <warren> i argue it isn't worth adding hours (?) of build time for distributors. it could be separately tested in their case.
19:34:17 <laanwj> we do ship test_bitcoin fwiw
19:34:24 <sipa> if they don't mind the time it takes on their builders to run all the tests (even ones beyond make check), so much the better
19:34:26 <laanwj> so people can run it *on their own machine* before running bitcoind
19:34:27 <laanwj> if they want
19:34:38 <fanquake> guix build targets: https://github.com/bitcoin/bitcoin/blob/master/contrib/guix/libexec/build.sh#L261-L285
19:34:57 <laanwj> that's the unit tests and most important part; they could also run the benchmarks, ofc
19:35:15 <warren> with this proposed benchmarks change "make check" would become a lot faster?
19:35:20 <sipa> wouldn't it make sense to run unit tests in guix on platforms where host=target ?
19:35:40 <laanwj> sipa: i'm not sure
19:35:40 <achow101> warren: yes
19:35:49 <warren> excellent
19:36:14 <_aj_> warren: (are you sure that was make check / unit tests, and not the functional tests? make check should be minutes, not hours)
19:36:15 <laanwj> you could always run the generated test_bitcoin if you want to check the result
19:36:47 <laanwj> i'm not sure running the code it generates is within the scope of deterministic building
19:36:48 <warren> that's what I argued
19:37:12 <warren> _aj_: I haven't looked in over a year
19:37:33 <sipa> @laanwj True
19:38:01 <warren> at the moment I'm part of a rebel group trying to encourage the entire distro to take build reproducibility seriously. we need to demonstrate such a bootstrap outside their infra. will take a while.
19:38:35 <laanwj> sipa: i mean i'm not strongly against it either, but making behavior depend on the host platform, for example, is a potential source of non-determinism
19:39:16 <sipa> fair enough
19:40:37 <laanwj> we've drifted from the topic a bit :) any other topics?
19:41:08 <warren> I was curious if anyone knows what's going on with BIP324?
19:41:23 <sipa> yes
19:41:44 <sipa> we've been working on updating the draft in private (dhruv, real-or-random, me)
19:41:53 <sipa> should have something to show very soon
19:42:25 <warren> Will it end up using the same p2p port as current day clearnet connections?
19:42:37 <warren> Will it have a different connection limit bucket?
19:42:55 <warren> anyhow excited to see the next draft!
19:43:04 <sipa> well, port 8333 is no longer preferred for outbound connections, though it's still the default for listening
19:43:14 <laanwj> dhruv was asking about testing #24545 a few days ago
19:43:15 <gribble> https://github.com/bitcoin/bitcoin/issues/24545 | BIP324: Enable v2 P2P encrypted transport by dhruv · Pull Request #24545 · bitcoin/bitcoin · GitHub
19:43:39 <sipa> the interaction with bip324 i'd say is an implementation detail; the spec doesn't care about what port it runs on, and bip324 capable listeners can accept both on the same port
19:44:28 <sipa> dhruv's implementation seems to work, i'm running it on bitcoin.sipa.be and there are a few other nodes running it
19:44:45 <sipa> i've personally focused more on the spec than the implementation though
19:44:46 <sipa> so far
19:46:03 <warren> thank you
19:46:08 <laanwj> yes i think that's the important point, they can share the same port
19:47:35 <laanwj> the connection limit bucket is not affected at all by the kind of connection, whether it should is something for discussion but probably not for the initial implementation
19:47:43 <sipa> yeah
19:47:53 <warren> right
19:48:22 <laanwj> any other topics for today?
19:49:20 <fanquake> Just making the rc1 bins available shortly, given we've had a good number of builds. Will be good to get some people testing rc1
19:49:46 <sipa> are the only rc2 backported fixes test things so far?
19:49:51 <laanwj> i'll get building
19:50:26 <fanquake> a couple bug fixes, 1 in the wallet, 1 config option related
19:50:35 <sipa> ok
19:51:09 <laanwj> #endmeeting