<youranonnima>
We are asking all communities to spread the word and help us - Iranians, to be heard by the world! There is an all out war happening on the streets of Iran.
<youranonnima>
Stand with Iranians. We need you to help us get our Country back from Mullahs!
<youranonnima>
#OpIran
<youranonnima>
#MahsaAmini
AaronvanW has joined #bitcoin-core-dev
NorrinRadd has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
_apex2_ has joined #bitcoin-core-dev
_apex2_ has quit [Ping timeout: 264 seconds]
halosghost has joined #bitcoin-core-dev
ghost43_ has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
AaronvanW has quit [Remote host closed the connection]
Guyver2 has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
_apex2_ has joined #bitcoin-core-dev
_apex2_ has quit [Ping timeout: 252 seconds]
AaronvanW has quit [Remote host closed the connection]
Guyver2 has left #bitcoin-core-dev [Closing Window]
jonatack has quit [Ping timeout: 268 seconds]
AaronvanW has joined #bitcoin-core-dev
gleb10689249 has joined #bitcoin-core-dev
AaronvanW has quit [Quit: Leaving...]
ghost43_ has joined #bitcoin-core-dev
ghost43 has quit [Ping timeout: 258 seconds]
kexkey has quit [Ping timeout: 268 seconds]
kexkey has joined #bitcoin-core-dev
amovfx_ has quit [Remote host closed the connection]
amovfx has joined #bitcoin-core-dev
amovfx has left #bitcoin-core-dev [#bitcoin-core-dev]
amovfx has joined #bitcoin-core-dev
gleb has quit []
gleb10689249 has left #bitcoin-core-dev [#bitcoin-core-dev]
gleb10689249 has joined #bitcoin-core-dev
gleb10689249 has left #bitcoin-core-dev [#bitcoin-core-dev]
gleb has joined #bitcoin-core-dev
<gleb>
testing
<laanwj>
dongcarl: i don't think so; though i'm not 100% sure how the permissions for the new kind of project board are handled, for the old kind of project board the only way is write access to the entire repo
<achow101>
#proposedmeetingtopic: acceptable runtimes of new benchmarks
<laanwj>
contrats on the 24.0 splitoff/tag btw
<laanwj>
i've added the 24.x branch to the bot so it will show merges there too
<laanwj>
i'm happy to migrate them too if someone asks
<_aj_>
laanwj: oh :( github tricked me
_andrewtoth_ has quit [Remote host closed the connection]
_andrewtoth_ has joined #bitcoin-core-dev
<amovfx>
test
<instagibbs>
amovfx, you got it
<amovfx>
ah sweet! thanks _aj_ that worked
<_aj_>
amovfx: cool; it's an anti-spam thing on some bitcoin channels
<amovfx>
yea makes sense
<amovfx>
meeting is in an hour 20 right?
<amovfx>
just want to make sure I'm timezoning correctly
<instagibbs>
believe so
<amovfx>
osom,
<bitcoin-git>
[bitcoin] theStack opened pull request #26156: test: check that `listdescriptors` descriptor strings are sorted (master...202209-test-rpc-check_sorted_listdescriptors_strings) https://github.com/bitcoin/bitcoin/pull/26156
<laanwj>
yes
<amovfx>
I don't suppose I could grab some guidance on what to focus on to be a core dev. I'm noob, right now I'm doing the blockchain commons learn bitcoin by the commandline, reviewing prs, and doing the pr review club
<amovfx>
I guess I'm looking for a goal, or a pre defined task, of "the project needs this"
<bitcoin-git>
[bitcoin] benthecarman opened pull request #26157: rpc: Fix ordering of arguments in listtransactions help message (master...fix-list-txs-help) https://github.com/bitcoin/bitcoin/pull/26157
<bitcoin-git>
[bitcoin] benthecarman closed pull request #26157: rpc: Fix ordering of arguments in listtransactions help message (master...fix-list-txs-help) https://github.com/bitcoin/bitcoin/pull/26157
<amovfx>
Is there a conflict when configureing with sanitizers
<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.
<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
<laanwj>
glozow: added-should it be for blockers or chasing concept ACK?
<glozow>
laanwj: chasing concept ACK i think
Zenton has quit [Read error: Connection reset by peer]
<glozow>
thanks :)
Zenton has joined #bitcoin-core-dev
<laanwj>
achow101: looks like it was already on the list?
<fanquake>
laanwj: i may have just added it
<laanwj>
okay!
<laanwj>
anything else for high prio?
<laanwj>
if not we'll go to next topic
<warren>
(do I ask questions at the end?)
<laanwj>
#topic acceptable runtimes of new benchmarks (achow101)
<core-meetingbot>
topic: acceptable runtimes of new benchmarks (achow101)
<laanwj>
warren: depends on the kind of question?
<laanwj>
i mean if it's a big one then it'd make sense to make it a separate topic
<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
<sipa>
we could run the make-check benchmarks with a lower -min-time ?
<sipa>
Because we don't really care about the benchmarking aspect, just that the code gets exercised.
<lightlike>
we only run one iteration already within "make check", right?
<laanwj>
sipa: we already run them for one iteration
<sipa>
I vaguely recall a PR that added an option for this actually.
<laanwj>
sipa: the problem is that some tests take significant time per iteration
<sipa>
oh
<sipa>
i see
<achow101>
there's the time per iteration, and also time for setting up the wallet
<achow101>
e.g. a benchmark for a wallet with many txs also requires spending time before the benchmark making those txs
<laanwj>
the original idea of the benchmarks was that iterations would take neglible time by themselves
amovfx_ has quit [Read error: Connection reset by peer]
<laanwj>
but yes, that's different for the wallet ones
<sipa>
right, the one-time setup cost per benchmark
<furszy>
I think that achow101 refers to benchmarks that require time consuming setups, and not the process that gets timed.
amovfx has joined #bitcoin-core-dev
<furszy>
message got out late :p..
<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
<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?
<fanquake>
I don't think we want to add more weight to make check itself
<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
<achow101>
what's the purpose of running benchmarks in make check?
<sipa>
making sure the benchmarks actually run
<sipa>
i guess the policy (intentional or not) we have is that "make check" runs all compiled code we have?
<sipa>
it doesn't run functional tests, but does run unit tests
<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
<_aj_>
doesn't run the fuzz tests?
<sipa>
and bitcoin-tx tests
<sipa>
hmm, it doesn't run the fuzz tests, good point
<achow101>
that could also be achieved with another ci job
<laanwj>
the fuzz tests would reqiire external data (e.g. corpuses) so it's not very practical
<_aj_>
would be nice to have 'make check' run the cheap benchmarks, at any rate?
<sipa>
yeah the most important thing is that CI at least occasionally runs all benchmark code
<furszy>
isn't the CI running in debug mode? (which makes benchmarks run much slower)
<achow101>
yes, but slow CI is nothing new
<achow101>
anyways, seems like the consensus is to have make check just not run all of the benchmarks
<laanwj>
i think that's the only proposed solution, too
<sipa>
i think that's reasonable
<warren>
sounds like there should be different levels of "check"?
<jonatack>
yes, as long as a CI task does run them
<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?
<furszy>
if we have to run some of the benchmarks, couldn't we just run them in a different CI job without debug mode?
<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.
<achow101>
furszy: I think we would still want debug enabled as debug will also execute code that we may care about
<achow101>
(since the purpose is to look for crashes/programming errors rather than actually benchmarking)
<warren>
I suppose "make check" failing on a slow machine with a timeout should be considered a bug?
<jonatack>
at least benchmarks ran last, so on my slow laptop, i would halt the make check run at the benchmark step
Talkless has quit [Quit: Konversation terminated!]
<furszy>
achow101: hmm k
<laanwj>
warren: yes, imo
<laanwj>
warren: but it would be fixed by the same solution proposed now
<warren>
nice
<achow101>
I don't think guix runs any of the tests or benchmarks?
<achow101>
other than symbol and security checks
<laanwj>
no, guix doesn't
<sipa>
really?
<laanwj>
it woudn't make much sense with cross compiling
<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"?
<sipa>
we don't run the tests in guix builds?
<sipa>
ah, yeah, cross compilation is an issue
<sipa>
@warren as far as i'm concerned, that's up to them
<laanwj>
wait, we absolutely recommend runing make check
<laanwj>
if you can
<warren>
i argue it isn't worth adding hours (?) of build time for distributors. it could be separately tested in their case.
<laanwj>
we do ship test_bitcoin fwiw
<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
<laanwj>
so people can run it *on their own machine* before running bitcoind
<laanwj>
that's the unit tests and most important part; they could also run the benchmarks, ofc
<warren>
with this proposed benchmarks change "make check" would become a lot faster?
<sipa>
wouldn't it make sense to run unit tests in guix on platforms where host=target ?
<laanwj>
sipa: i'm not sure
<achow101>
warren: yes
<warren>
excellent
<_aj_>
warren: (are you sure that was make check / unit tests, and not the functional tests? make check should be minutes, not hours)
<laanwj>
you could always run the generated test_bitcoin if you want to check the result
<laanwj>
i'm not sure running the code it generates is within the scope of deterministic building
<warren>
that's what I argued
<warren>
_aj_: I haven't looked in over a year
<sipa>
@laanwj True
<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.
<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
<sipa>
fair enough
<laanwj>
we've drifted from the topic a bit :) any other topics?
<warren>
I was curious if anyone knows what's going on with BIP324?
<sipa>
yes
<sipa>
we've been working on updating the draft in private (dhruv, real-or-random, me)
gossie has quit [Ping timeout: 264 seconds]
<sipa>
should have something to show very soon
<warren>
Will it end up using the same p2p port as current day clearnet connections?
<warren>
Will it have a different connection limit bucket?
<warren>
anyhow excited to see the next draft!
<sipa>
well, port 8333 is no longer preferred for outbound connections, though it's still the default for listening
<laanwj>
dhruv was asking about testing #24545 a few days ago
<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
dougefish_ has quit [Remote host closed the connection]
<sipa>
dhruv's implementation seems to work, i'm running it on bitcoin.sipa.be and there are a few other nodes running it
<sipa>
i've personally focused more on the spec than the implementation though
<sipa>
so far
<warren>
thank you
<laanwj>
yes i think that's the important point, they can share the same port
<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
<sipa>
yeah
<warren>
right
<laanwj>
any other topics for today?
<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
<sipa>
are the only rc2 backported fixes test things so far?
<laanwj>
i'll get building
<fanquake>
a couple bug fixes, 1 in the wallet, 1 config option related
<fanquake>
the miniscript fix needs backporting, maybe the fuzz fix for the bitdeque
<fanquake>
we'll keep collecting for rc2
<achow101>
fyi I will be unavailable for the wallet meeting tomorrow, if someone else would like to run it, that'd be great.
<amovfx>
Thanks everyone, are there any other meetings I should be aware of, i do this, and pr review club
<glozow>
it would also be good to get #25858 if people are willing to review?
<gribble>
https://github.com/bitcoin/bitcoin/issues/25858 | psbt: Only include PSBT_OUT_TAP_TREE when the output has a script path by achow101 · Pull Request #25858 · bitcoin/bitcoin · GitHub
<amovfx>
and just learned of the wallet
<amovfx>
is that here?
<achow101>
amovfx: yes, we have a wallet meeting here every other friday
<amovfx>
cool
<amovfx>
Is there a good resource where I can learn about taproot? I'm reading over #25858 and I have some stuff to learn
<gribble>
https://github.com/bitcoin/bitcoin/issues/25858 | psbt: Only include PSBT_OUT_TAP_TREE when the output has a script path by achow101 · Pull Request #25858 · bitcoin/bitcoin · GitHub
<sipa>
amovfx: Have you read the BIPs (341 and 342 mostly)? There are more high-level explainers on various online media too. I've done one or two talks about it too.
<amovfx>
I've seen a few videos, Ill read over the BIPS today thanks
<jonatack>
amovfx: another suggestion would be to git clone the bitcoin optech and the bitcoin core pr reviews repositories locally and then search them for the terms you are interested in
PasiveIncomeGirl has left #bitcoin-core-dev [#bitcoin-core-dev]
_apex2_ has quit [Ping timeout: 252 seconds]
brunoerg has quit []
<Murch>
We also have the Optech Workshop for Taproot with the Jupiter notebooks which should help people get their hands a bit dirty trying to understand how Taproot fits together under the hood