cmirror has quit [Remote host closed the connection]
jonatack has joined #bitcoin-core-dev
agentcas- has joined #bitcoin-core-dev
eval-exec1 has joined #bitcoin-core-dev
agentcasey has quit [Ping timeout: 265 seconds]
<bitcoin-git>
[bitcoin] tnndbtc opened pull request #31719: miniscript: fixes #29098 by only use first k valid signatures (master...fix-multi-sig-performance) https://github.com/bitcoin/bitcoin/pull/31719
eval-exec1 has quit [Remote host closed the connection]
eval-exec has quit [Ping timeout: 248 seconds]
eval-exec has joined #bitcoin-core-dev
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
eval-exec1 has joined #bitcoin-core-dev
eval-exec has quit [Ping timeout: 264 seconds]
eval-exec1 is now known as eval-exec
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
eval-exec has quit [Remote host closed the connection]
eval-exec has joined #bitcoin-core-dev
mcey_ has quit [Remote host closed the connection]
mcey_ has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
emcy__ has joined #bitcoin-core-dev
mcey_ has quit [Ping timeout: 276 seconds]
arferreira3 has quit [Ping timeout: 265 seconds]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 244 seconds]
arferreira3 has joined #bitcoin-core-dev
arferreira3 has quit [Ping timeout: 248 seconds]
kevkevin has joined #bitcoin-core-dev
arferreira3 has joined #bitcoin-core-dev
arferreira3 has quit [Ping timeout: 260 seconds]
kevkevin has quit [Ping timeout: 248 seconds]
arferreira3 has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 245 seconds]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 264 seconds]
kevkevin has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake closed pull request #31619: ci: change the build to be verbose by default (master...ci_verbose_build) https://github.com/bitcoin/bitcoin/pull/31619
<bitcoin-git>
[bitcoin] hebasto opened pull request #31722: cmake: Copy `cov_tool_wrapper.sh.in` to the build tree (master...250123-cmake-cov) https://github.com/bitcoin/bitcoin/pull/31722
<bitcoin-git>
bitcoin/master 733fa0b Antoine Poinsot: miner: never create a template which exploits the timewarp bug
<bitcoin-git>
bitcoin/master 59876b3 merge-script: Merge bitcoin/bitcoin#31376: Miner: never create a template which exploits...
<bitcoin-git>
[bitcoin] fanquake merged pull request #31376: Miner: never create a template which exploits the timewarp bug (master...2411_miner_never_timewarp) https://github.com/bitcoin/bitcoin/pull/31376
<bitcoin-git>
bitcoin/master 5c3e4d8 Antoine Poinsot: doc: add a section about using MSan
<bitcoin-git>
bitcoin/master 9914e73 merge-script: Merge bitcoin/bitcoin#31704: doc: add a section in the fuzzing documentati...
<bitcoin-git>
[bitcoin] fanquake merged pull request #31704: doc: add a section in the fuzzing documentation about using MSan (master...2501_doc_fuzz_msan) https://github.com/bitcoin/bitcoin/pull/31704
kevkevin has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
catnip has joined #bitcoin-core-dev
bugs_ has quit [*.net *.split]
S3RK has quit [*.net *.split]
TheRec_ has quit [*.net *.split]
jamesob1566 has quit [*.net *.split]
maflcko has quit [*.net *.split]
instagibbs has quit [*.net *.split]
adiabat_ has quit [*.net *.split]
theStack has quit [*.net *.split]
bugs_ has joined #bitcoin-core-dev
S3RK has joined #bitcoin-core-dev
TheRec_ has joined #bitcoin-core-dev
jamesob1566 has joined #bitcoin-core-dev
maflcko has joined #bitcoin-core-dev
instagibbs has joined #bitcoin-core-dev
theStack has joined #bitcoin-core-dev
adiabat_ has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] Sjors opened pull request #31725: test: clarify timewarp grace period griefing attack (master...2025/01/timewarp-grief) https://github.com/bitcoin/bitcoin/pull/31725
<bitcoin-git>
[bitcoin] hebasto opened pull request #31726: ci: Replace `CMAKE_CXX_FLAGS` with `APPEND_CXXFLAGS` (master...250123-ci-flags) https://github.com/bitcoin/bitcoin/pull/31726
<jonatack>
lightlike: thanks for the update on looking into improving the stalling disconnection algo during IBD. didn't investigate more yet but offhand wondered if addnode peers could be exempted, or handled differently than disconnection, as they'll be connected to again immediately after
preimage has joined #bitcoin-core-dev
emcy__ has quit [Ping timeout: 272 seconds]
core-meetbot has quit [Remote host closed the connection]
core-meetbot has joined #bitcoin-core-dev
<achow101>
#startmeeting
<core-meetbot>
achow101: Meeting started at 2025-01-23T16:00+0000
<sr_gi[m]>
There first two tabs should the data volume per transaction in different configurations
<maxedw>
hi
purpleKarrot has joined #bitcoin-core-dev
<sr_gi[m]>
Chatting with some folks in the office yesterday yield some interesting things to look at in order to try to reduce the latency so we could pick on the configurations that maximizes bandwidth
<kanzure>
hi
<sr_gi[m]>
So I'll check on some of those next.
<sr_gi[m]>
I think Gleb also had a plan on his end but not sure if he's around
<sr_gi[m]>
He'll share next time. That's all on my end
<achow101>
#topic Cluster Mempool WG Update (sdaftuar, sipa)
brunoerg_ has quit []
brunoerg has joined #bitcoin-core-dev
<brunoerg>
hi
<sipa>
sdaftuar is continuing his rebase of #28676 on top of my txgraph code (up to and including #31553)
<glozow>
Can't guarantee more eyes, but can promise I will write some notes before then
<achow101>
#topic MuSig2 WG Update (achow101)
<achow101>
#31242 was merged. Spent a bunch of time working on #31622 and fixing the issues there. It should not be ready for review.
<core-meetbot>
achow101: Unknown command: #31242
<gribble>
https://github.com/bitcoin/bitcoin/issues/31242 | wallet, desc spkm: Return SigningProvider only if we have the privkey by achow101 · Pull Request #31242 · bitcoin/bitcoin · GitHub
<gribble>
https://github.com/bitcoin/bitcoin/issues/31622 | psbt: add non-default sighash types to PSBTs and unify sighash type match checking by achow101 · Pull Request #31622 · bitcoin/bitcoin · GitHub
<gribble>
https://github.com/bitcoin/bitcoin/issues/31242 | wallet, desc spkm: Return SigningProvider only if we have the privkey by achow101 · Pull Request #31242 · bitcoin/bitcoin · GitHub
<achow101>
s/not/now
<achow101>
I'll also be working on fixed test vectors for #31247 and to add to the bip
<bitcoin-git>
[bitcoin] darosior opened pull request #31727: miniscript: convert non-critical asserts to CHECK_NONFATAL (master...2501_miniscript_nonfatal) https://github.com/bitcoin/bitcoin/pull/31727
<glozow>
We spent some time this week thinking about what minimal orphanage buffs we want to incorporate in v29.0. So I will be heads down trying to get that PR up asap (as soon as I get rid of this bug 🤒).
<glozow>
TLDR, it will make TxOrphanage no longer global; we'll have limits per-peer
<sipa>
well, the TxOrphanage instance itself remains global, it's just the accounting that happens per peer?
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<sipa>
or do you think actually making the orphanage per-peer is simpler?
<glozow>
sipa: yes, still a global `TxOrphanage` object
<sipa>
alright
<glozow>
And if anybody has any extra machines, I would appreciate testing on mainnet for this. Some debug-only nodes with`TXPACKAGES` logging would be great.
<glozow>
vasild sent me some interesting logs a few weeks ago (thank you)
<instagibbs>
you mean in general on master or whic hpr
<sipa>
glozow: happy to run some, what PR/options?
<Sjors[m]>
Re (2): it will make my Stratum v2 life easier, because it allows me to stop maintaining two separate approaches for Template Provider. One version with IPC, and the original approach of shoving it all into bitcoind.
bitdex has joined #bitcoin-core-dev
<darosior>
Hi, stumbling upon #30975 i reached out to Sjors privately to raise concerns that it might be premature to release libmultiprocess binaries, especially a couple weeks from the release. He explained me his motivations and i suggested we should discuss it during a meeting because i was certain others would disagree and by coredev we would already be
<darosior>
past feature freeze. I was also interested in hearing from people more familiar than i am with the status of the multiprocess project and codebase.
<Sjors[m]>
fanquake: because it's the only thing that people can actually run right now, so I'll have to keep it rebased until we have an alternative
<ryanofsky>
(my response is below that, please take a look at that too)
<fanquake>
Could you also elaborate on who is running it right now. i.e how many users?
zeropoint has joined #bitcoin-core-dev
<cfields>
Sjors[m]: including in v29 release seems very premature to me as it's not yet even on by default :). It's not clear to me at all who's had eyes on it.
<Sjors[m]>
fanquake: the SRI team runs the IPC version, they have a handful of testers using a custom signet.
<Sjors[m]>
And afaik the new Demand pool runs the regular version.
<Sjors[m]>
I have no idea how many, if any, people use Demand pool, they're still starting up as a business.
<fanquake>
So a single pool using the old version (experimentally I assume)
<Sjors[m]>
fanquake: yes, it's partially a chicken-egg problem - without Bitcoin Core support Stratum v2 is dead on arrival
<ryanofsky>
One idea is more people would use this if it were it were easier to use?
<sipa>
i don't think Sjors[m]'s desire to maintain an alternative approach should have a bearing on this discussion, neither the reasons for doing so, but also not as an argument for why people should prioritize review
<Sjors[m]>
And even experimenta support is a pain now.
<Sjors[m]>
Because people have to install Bitcoin Core binaries from some random guy (me).
<fanquake>
Sjors: I understand that, it's just unfortuante that as a side-effect of wanting to do an (external) stratum v2 project, the idea is taht core has to turn on another feature that clearly has a much wider scope, no clear plan/rollout etc
<achow101>
I think the question is really whether multiprocess is ready enough for people to try to use it in production?
<fanquake>
It's also unclear what we are commiting to. Is the mining interface going to be regarded as stable, if real pools are using it? Or will they just take the breakage, given it's all still experimental
<sipa>
to me, the answer to (1) is yes, but it is obviously contingent on it getting sufficient review
<cfields>
looking at the responses on github, I think maybe there's a disagreement/misalignment on what we're signaling when we ship a binary as part of a release.
<Sjors[m]>
Stratum v2 is not production ready in general, so imo it's about whether it's good enough for testing. But afaik fanquake says, also. whether we're committed to maintain it.
<sipa>
(2) is a much harder question, as it's not clear to me both how serious concerns about bugs/reviewer confidence are, and at the same time, it's not all that clear how much we lose by delaying one release
<fanquake>
sipa: unfortunately during the life of libmultiprocess, getting sufficient reivew from anyone other
<Sjors[m]>
I think it's perfectly fine if v29 still has bugs in it, for these pools. They'll probably need to offer Stratum v1 as a fallback for a while anyway.
<darosior>
I agree with sipa for (1). And as far as i'm aware we aren't there yet, unfortunately.
<fanquake>
than Russ, has seemed to be very difficult
<fanquake>
Sjors: bugs might be fine for the pools, but no so much for our CI
<ryanofsky>
What is (1)? I'm having problems following this discussion...
<Sjors[m]>
As for the Mining interface, I think we should consider it unstable for a few releases. I maintain the only application that uses it, so changes aren't a problem yet.
<fanquake>
and that is the current state of affairs, given there are multiple unsolved intermittent issues related to libmultiprocess
<achow101>
what if we did a separate multiprocess only package, and make it very clear that that is experimental and subject to breakage and/or disappearnce?
<Sjors[m]>
fanquake: fixing intermittend CI failures is always a good reason to wait with merging
<fanquake>
If Russ dissapears (hopefuly not) tomorrow, are you planning on taking over maintainership libmultiprocess?
<Sjors[m]>
That relates to my question (3) - there may be specific things that need to happen before the feature freeze, or we simply miss this release.
<sipa>
fanquake: if we can direct people to change their approach in whatever way (unclear to what extent that's possible, but assuming we can), we can also make the change be "go review multiprocess"
<darosior>
"I think it's perfectly fine if v29 still has bugs in it" - I don't feel very comfortable with the idea of Bitcoin Core releasing binaries that "may have bugs in them but it's fine".
<stickies-v>
+1 darosior
<Sjors[m]>
fanquake: I don't have the skill for it, which means I can't do much more than very basic maintainance on it.
<glozow>
achow101: (sorry late but can we add topic v29.0 milestone today?)
<Sjors[m]>
So that relates to my question (1)
<Sjors[m]>
Whether we want multiprocess at all
<achow101>
darosior: well we always "may have bugs", and we certainly defer some bug fixes to future releases once we get past a certain point in the release process
<fanquake>
Apparently the answer has been "yes", but "not quite enough" for almost 10 years
<sipa>
darosior: right, agree; i think the label "experimental" is fine for "this is unstable, may change, don't depend on it", for a limited amount of time; but i'm much less happy with a "this is actually not up to our review standards"
jackielove4u3 has joined #bitcoin-core-dev
<darosior>
achow101: sure but there is a difference between no warranty and breaking our standards.
<stickies-v>
I don't understand the urgency in getting this merged. I think it's excellent that we're progressing multiprocess work, but rushing this in v29 seems not worth the potential costs given the number of substantiated concerns raised
<fanquake>
achow101: sure, but at this point it's not even clear if anyone in the project other than sjors has even run this code
<fanquake>
that alone seems like a weird place to be, to be merging this stuff
<sipa>
fanquake: for me personally, seeing the interaction between sv2 work and multiprocess has positively changed my outlook on how useful the multiprocess work is
<ryanofsky>
I don't understand what the harm would be exactly. This PR does not affect exiting binaries, it adds a new binary that we can label however we want to label it
<sipa>
so actually seeing it "going somewhere" may very realistically change how reviewers deal with it
<Sjors[m]>
ryanofsky: I opened the topic with 3 questions, so that's what (1), (2) , (3) refer to.
<achow101>
I agree that we don't want to break any standards that we may already have, but all of the multiprocess code that has been merged and presumably reviewed to the same standard as everything else
<fanquake>
sipa: I somewhat agree, if we have a longer term plan to actually do the process separation, in a way that gives the us the benefits of process separation. i.e currently, it's still a bitcoin-node process, if you don't care about wallet or gui etc
<ryanofsky>
Can we do something like install it in bin/experimental/? bin/unstable/?
jackielove4u has quit [Ping timeout: 265 seconds]
jackielove4u3 is now known as jackielove4u
<fanquake>
achow101: I don't see how that could be true if you look at the PRs in the multiprocess repo
<darosior>
"Whether we want multiprocess at all" -> my opinion is yes for 1) being able to have external people experiment with alternative GUI / wallets in the short term and 2) being able to potentially, maybe, have more interesting process separation in the future (like one process per peer? let me dream ok!).
<achow101>
unless the question is that this pr in particular doesn't meet review standards?
<darosior>
"Whether we want multiprocess at all" -> plus as Pieter points out experiments with other interfaces we didn't think about in the first place.
<fanquake>
It's a shame that this needs to be decided pre core dev. It'd be great to hash these questions out not over irc.
<Sjors[m]>
If we ship this in v30 instead of v29 it's annoying for me. I might delay Stratum v2 adoption by half a year, though it's certainly not completely blocked. What I'm mainly worried about is an indefinately punting of shipping this for vague reasons, as opposed to specific blocking bugs.
<Sjors[m]>
* it might
<Sjors[m]>
(annoying, but not end of the world)
<sipa>
fanquake: i agree with that, i'd rather have this discussion (in addition to here) also at coredev
<ryanofsky>
I think we can also hash this out in the actual PR. (i also do not favor IRC)
<glozow>
should we explore shifting v29.0 dates?
<cfields>
I like the idea of multiprocess and shipping it in the future. But imo it's not a good idea (and not consistent with our history) to ship something that's not on by default because otherwise we have no idea who's had eyes on it. And from what I understand, it's currently (if nothing else becausse libmultiprocess is not vendored) not ready to be on by default. It'd be more consistent with our process to turn it on by default at the beginning of a
<cfields>
release cycle, have all devs dogfood it for 6 months, then discuss shipping it once we're all on the same page.
<darosior>
Sjors[m]: yes absolutely understand this. I think it's part of a larger issue of not being able as a project to set some clear goals. I have some separate thoughts on this i might share another time.
<achow101>
Sjors[m]: what's half a year to waiting 6 years already (or however long it's been, feels like forever)
<fanquake>
sjors: i dissagree that we should do it, as long as there are no (known) bugs, there are other process/project issues here
<darosior>
achow101: for multiprocess since 2017 :/
<fanquake>
(there are still known bugs in either case)
<Sjors[m]>
achow101: I've only worked on Stratum v2 for 1 year. I'm sure I'll still be motivated in 6 months. Probably not in 6 years.
<Sjors[m]>
I do not posess ryanofsky level patience :-)
<sipa>
cfields: i think i agree, but can you clarify with "on by default"? because releases only have defaults, and the options are (1) no multiprocess binaries (2) both multiprocess and classic binaries and (3) only multiprocess binaries
<fanquake>
How we ship multiprocess is another thing that is still undecided
<fanquake>
#31375
<core-meetbot>
fanquake: Unknown command: #31375
<ryanofsky>
fanquake undecided as in not merged yet? i think we have a clear path
<cfields>
sipa: I mean on by default in our buildsystem at all, ignoring the question of release. As i understand, pretty much the only realistic way to build/test now is with depends, and I don't know how many people do that. So I'm assuming that there aren't many devs interacting with it on a daily basis atm.
<sipa>
cfields: agreed
<achow101>
doesn't the dev-mode preset turn it on?
<sipa>
i haven't even gotten it to work the last time i tried
<ryanofsky>
the PR does not turn multiprocess on by default for developers
<fanquake>
That only works with depends though, whcih isn't part of the dev mode
<sipa>
i think we should have it on in dev builds by default before considering adding to releases
<ryanofsky>
that would be a nice step to take at some point the future
<cfields>
ryanofsky: right, that's my point. Imo that ordering is backwards.
<darosior>
Yeah you need a patch to build it because of an issue with libatomic
<achow101>
oh i installed libmultiprocess to my system, so dev-mode always builds with it. I don't necessarily test with it though
<darosior>
sipa: +1
<sipa>
fanquake: ah thanks
<fanquake>
which is why I'm more in favour of vendoring, as it removes a whole class of issues
<ryanofsky>
i see, so no feature can be in a release if it is not enabled by default in developer builds
<cfields>
+1 for vendoring.
<sipa>
ryanofsky: i think it's a reasonable bar, because we want to dogfood it actually working before shipping something, even if experimental?
<fanquake>
ryanofsky: I think it's somewhat weird for us to be shipping things that developers are not actively building / using testing etc
<ryanofsky>
yes, understood
<cfields>
ryanofsky: I'm not sure that's a hard hard rule, but I think it's at least consistent with how we've done things in the past.
<cfields>
and it makes sense to me in this case as well.
<darosior>
+1
<ryanofsky>
these are just new requests and I'm trying to boil them down
<Sjors[m]>
fanquake: I agree there are "other process/project issues", but I'd like to see them enumerated so it's clear when we've resolved them. Though that itself takes time.
<darosior>
So is there any other thing we could do that would make your life easier Sjors[m]?
<jonatack>
It does sound like this could very much benefit from a tangible, non-risky nudge...and from 1-2 committed reviewers who may very reasonably be gating their review investment in seeing it likely to make progress (myself included, and as sipa pointed out)
<Sjors[m]>
darosior: getting a multiprocess binary released by the Bitcoin Core project in some way is the most useful. Can be seperate from the main release.
<cfields>
ryanofsky: fwiw, I'm using "can we turn it on for daily devs by default?" as a proxy for "is it maybe ready to ship?". And if the answer to the former is a no, then the answer to the latter seems pretty obvious to me.
<ryanofsky>
i'd like to figure out a next step for 30975. seems like it could just enable multprocess in CI and not flip the depends default
<Sjors[m]>
I could do that myself, but it makes little sense for me to release two binaries myself: a Bitcoin Core IPC build + a Template Provider. Then it's easier for me to keep them combined.
<hebasto>
agree with vendoring libmultiprocess
<cfields>
ryanofsky: Imo vendoring makes sense as a next step.
<sipa>
agree
<cfields>
to at least get everyone on the same page
<fanquake>
Sjors: how what a separate from the main release build work? We aren't going to release/provide bin with unmerged/reviewed code
<ryanofsky>
cfields, i dont' think it's a big deal to ship a new binary that may have bugs but has been reviewed is clearly labeled unstable
<ryanofsky>
but understand if it's a minority opinion
<Sjors[m]>
fanquake: if we vendor it, then we could guix build a bitcoin-node binary and ship that seperately?
<fanquake>
Sjors: will the pools still use this if we tell them it's completely experimental / unstable, and the sidecar will likely need further changes / refactoring
<Sjors[m]>
fanquake: that's already better than the status quo
<fanquake>
Sjors: maybe, where do you want to distribute that from? A different download page on the website? github? etc
<Sjors[m]>
Whatever is easier, the SRI documentation can point to it.
<achow101>
it could just be in bitcoincore.org/bin and not actually on the downloads page
<darosior>
Exactly. It seems this is just not possible. Pools want the Bitcoin Core seal of approval because of our release standard. Breaking these standards to be able to release a binary is probably not a solution to get them to run it.
<Sjors[m]>
It would basically say "Please install Bitcoin Core from X instead of the normal place", then install the sidecar app.
<fanquake>
RIght, so why can't SRI build and distribute this themselves?
<fanquake>
Does this only work if it exists on bitcoincore.org
<fanquake>
Surely bundling it with the sidecar would be even easier
<Sjors[m]>
SRI is a Rust project, they're not going to release Bitcoin Core binaries I think.
<ryanofsky>
I think seal of approval can mean we reviewed this we build this we tested this, but it it is unstable and may still have bugs and is clearly labeled as such
<Sjors[m]>
Bundling a custom Bitcoin Core with a sidecar makes no sense, it's just more complicated to install than the combined binary I've been shipping.
<fanquake>
Sjors: I mean a tarball can have both the custom core bin, and the sidecar
<fanquake>
which also removes this distribution problem, given they are downloading the sidecar in any case
<sipa>
fanquake: i don't know if that's all that much of a reasonable distinction
<cfields>
ryanofsky: I think there's a difference between "this is an all-hands wip and may still be unstable" and "this has barely been dogfooded internally at all, but may be useful to some".
<achow101>
I think we're gettinga bit off topic here, It seems like there's still unresolved issues that can probably be worked out in the pr, and things we definitely need to discuss at coredev. I'd say this will likely miss v29.
<sipa>
if we're working on it, it must mean that we want people to use it, whether we distribute it or others
<achow101>
there's still one more topic for today's meeting
<cfields>
maybe I'm underestimating how many devs are playing with it on a daily basis?
<fanquake>
sipa: right, but it seems just as easy as making as host some special binaries for them
<sipa>
fanquake: fair
<sipa>
but neither should be the end goal
<sipa>
as a temporary situation, i don't care much
<glozow>
I think we should move on if there are other topics, e.g. wg updates
<sipa>
agree
<Sjors[m]>
If I have to maintain a node binary forever, then it makes no sense for me to use the more complicated IPC variant. That only makes sense as a temporary measure, if I'm sure eventually Bitcoin Core will ship it.
<achow101>
feel free to hash this out after the meeting
<achow101>
#topic 29.0 milestone (glozow)
<darosior>
sipa: seems like getting people to rely on temporary binaries we release may well be pretty permanent.
<ryanofsky>
cfields, i don't understand importance of the all-hands part. there is value in us building and testing and releasing something even if not every developer has done it
<glozow>
As per #31029. We have feature freeze scheduled for Feb 20
<ryanofsky>
but if that's the standard fine. you are just saying these things like they should be obvious to me and they are not
<glozow>
I think it's an appropriate time to think "assuming people devote their time to X, is there a potential universe where we have X in v29.0"
<glozow>
But also, given earlier comments in this meeting, do people feel very strongly about changing the date?
<achow101>
could we delay feature freeze to after coredev?
<darosior>
glozow: i don't think changing the date would help with the previous topic discussed.
<darosior>
achow101: why?
<sipa>
i'd prefer not changing the date
Emc99 has joined #bitcoin-core-dev
<sipa>
and having a relaxed coredev where we can talk about bigger things, rather than last-minute things that may or may not still make it in
<fanquake>
achow101: do you have particular PRs in mind that would benefit from delaying
<glozow>
It's relevant to questions like "assuming people devote their time to X, is there a potential universe where we get X to a state where it could be in v29.0"
<achow101>
darosior: i think there are things currently milestoned for 29.0 that could make it in during/after coredev
<cfields>
ryanofsky: oh no no, i'm just giving my opinion because you asked. definitely not the standard and I didn't mean that as any kind of statement of fact. sorry if it came across that way.
<glozow>
sipa: yeah I agree with not doing last minute things at coredev
<Sjors[m]>
I would also prefer to either get multiprocess in well before the feature freeze, or wait for v30. It seems to big a change for a last minute discussion.
<glozow>
Ok then we'll keep the date as is, and the coredev conversation can be about having it in v30
<jonatack>
when the laanwj began delegating release management for the first time during a core dev IRC meeting, IIRC the idea was for the release management to be rotated
<jonatack>
when the laanwj -> when the lead maintainer
<fanquake>
it is currently being rotated
<fanquake>
i did 27
<fanquake>
achow did 28
<achow101>
we're rotating, mostly
<fanquake>
gloria will do 29
<fanquake>
depends on what you mean by management, but the tagging has been mostly to that effect, backports still a bit more spread out etc
<jonatack>
I see. I'll read through that meeting again.
<fanquake>
website updated, bin uploading etc also a bit spread, can see who's doing anything via all the PRs in either case
<glozow>
don't need to read through meetings, just observe the release PRs and announcements haha. I think we've done a pretty good job distributing load
<jonatack>
I did think it would be delegated more widely, assuming people wanted to, as the suggestions during the meeting included delegating to non-maintainers.
<fanquake>
Not sure that non-maintainers can make release, because they'd need push access to github, access to the webserver to upload bins etc
<achow101>
fanquake: for the process/project things that you mentioned, can you be sure to schedule a session to discuss that at coredev? i feel like there's things there that we say we should talk about but never actually do..
<glozow>
If you want to participate in the release process, reviewing backports is the majority of the labor
<achow101>
jonatack: non-maintainers is a bit meh due to the elevated permissions required
<fanquake>
achow101: yes, that will be happening, possibly from cfields, but nothing concrete yet
<glozow>
the majority of the non-perms labor*
<darosior>
Agree it is part of the role of maintainer of doing releases.
<cfields>
achow101: yeah I've been talking to fanquake about it recently and plan to hit up all the maintainers for before coredev for discussion points.
<jonatack>
Thanks. No need for a meeting topic for now. It's a thought I have from time to time when recalling that meeting.
mcey_ has quit [Ping timeout: 264 seconds]
Emc99 has quit [Quit: Client closed]
jon_atack has joined #bitcoin-core-dev
mcey has joined #bitcoin-core-dev
catnip has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 265 seconds]
<fanquake>
achow101: can you add the next most-relevant wallet removal PR to the 29.x milestone
catnip has quit [Quit: Client closed]
dzxzg has quit [Ping timeout: 240 seconds]
<achow101>
fanquake: added #31495
<gribble>
https://github.com/bitcoin/bitcoin/issues/31495 | wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases by achow101 · Pull Request #31495 · bitcoin/bitcoin · GitHub
jon_atack has quit [Ping timeout: 252 seconds]
jonatack has joined #bitcoin-core-dev
<Sjors[m]>
Thanks for the discussion everyone. I marked #30975 draft and left a comment linking to the meeting, addressing some of the comments.
<jeremyrubin>
I'm a bit confused about descriptor ranges -- If I wanted to create a non-ranged descriptor, and i use start/end 0 0, then I get the error UpdateWalletDescriptor: new range must include current range = [0,0]. is [0,0] an uninhabited descriptor then, is that the right way to understand it? and 0,1 is a single descriptor at 0?
<Sjors[m]>
jeremyrubin: a non-ranged descriptor should look like tr(xpub/0) and you don't need to provide a range arugment
<Sjors[m]>
Did you try to do tr(xpub/*) with range [0,0] ?
<jonatack>
found the initial IRC meeting: "topic: Training to rotate release responsibility (neha)"
<jeremyrubin>
walletutil WalletDescriptor requires range arguments
<Sjors[m]>
Do you mean the bitcoin-wallet binary?
<jonatack>
(iirc there was a follow-up meeting on further candidates to be trained, could be misremebering, may look for it later -- doing CUBO+/Plan B Network School training for students this afternoon in San Salvador)
<jeremyrubin>
Ah, no I'm working on some experimental RPCs that make use of the functionality directly
<jeremyrubin>
so am really asking about that the constructor for WalletDescriptor accepts range_start = 0, range_end = 0
<achow101>
jeremyrubin: range is ignored for non-ranged descriptors
<achow101>
just don't change the range if you're trying to update an existing descriptor
<jeremyrubin>
i'll poke at it a bit more, I'm fairly certain I'm not making a ranged descriptor, but while changing some other things in my code suddenly it started getting picked up as one, and my 0,0 failed, while setting it to 0,1 works
<jeremyrubin>
the change was dropping one tapscript branch
<achow101>
if the error message says [0,0], the range is actually stored as [0, 1)
preimage has quit [Ping timeout: 264 seconds]
<achow101>
except for display, the range is always beginning inclusive, end exclusive
<achow101>
no, the error is entirely about what is in the wallet already
<achow101>
inferdescriptor doesn't do anything with ranges
<achow101>
and if inferdescriptor infers an entirely different descriptor, you would not have this error
<achow101>
jeremyrubin: does this snippet have the change to WalletDescriptor's arguments that made it work?
<achow101>
or is this the original descriptor?
<achow101>
or something else?
<achow101>
also you have start=1, end=0, which doesn't make any sense
preimage has quit [Ping timeout: 246 seconds]
preimage has joined #bitcoin-core-dev
core-meetbot has quit [Remote host closed the connection]
core-meetbot has joined #bitcoin-core-dev
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
preimage has quit [Quit: WeeChat 4.5.1]
core-meetbot has quit [Remote host closed the connection]
core-meetbot has joined #bitcoin-core-dev
core-meetbot has quit [Remote host closed the connection]
core-meetbot has joined #bitcoin-core-dev
jonatack has quit [Read error: Connection reset by peer]
dongcarl has quit [Ping timeout: 244 seconds]
Talkless has joined #bitcoin-core-dev
<jeremyrubin>
yes this is what made it work, with 0, 0 it failed
<jeremyrubin>
i have this def for the constrcutor, WalletDescriptor(std::shared_ptr<Descriptor> descriptor, uint64_t creation_time, int32_t range_start, int32_t range_end, int32_t next_index)
<jeremyrubin>
so 0 1 0 should be start=0, end = 0, next = 0
<jeremyrubin>
* start = 0, end = 1, next = 0
<jeremyrubin>
when it is set to start = 0, end = 0, next = 0, then I get the failure
<achow101>
ah missed creation was being passed
<achow101>
is the same function producing the descriptor both times?
<jeremyrubin>
yes
jespada has joined #bitcoin-core-dev
<achow101>
is there a reason you are calling UpdateWalletDescriptor?
<achow101>
I think there's probably bug, but we never tested that on non-ranged descriptors since it doesn't really make sense to
jespada has quit [Client Quit]
<jeremyrubin>
I'm not actually, I'm calling CWallet::AddWalletDescriptor
<achow101>
multiple times, presumably
<jeremyrubin>
good catch -- you found a bug in my code XD
<jeremyrubin>
was supposed to be calling it with A then B, was calling with A twice by mistake
<jeremyrubin>
so yes, was calling twice
<achow101>
i see. well there's probably a bug in UpdateWalletDescriptor too
<jeremyrubin>
it still seems like a bug yeah
<jeremyrubin>
since at very least AddWalletDescriptor should be idempotent
<jeremyrubin>
well at the very least it seems that fixing my AA / AB bug made it so that i'm not repeating calls -- thanks for pointing that out. But I do think there's likely a minor bug in the range handling, so I'm glad I asked :)
<jeremyrubin>
(verified working with 0,0 and AB)
<achow101>
can you open an issue for the range bug?
<jeremyrubin>
yeah np
core-meetbot has quit [Remote host closed the connection]
core-meetbot has joined #bitcoin-core-dev
<jeremyrubin>
#31728
<gribble>
https://github.com/bitcoin/bitcoin/issues/31728 | Bug: Non-Ranged Descriptors with Range [0,0] Trigger Unexpected Wallet Errors in `AddWalletDescriptor` · Issue #31728 · bitcoin/bitcoin · GitHub
core-meetbot has quit [Remote host closed the connection]
core-meetbot has joined #bitcoin-core-dev
purpleKarrot has quit [Quit: Client closed]
jonatack has joined #bitcoin-core-dev
pyth has quit [Ping timeout: 244 seconds]
pyth has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
pyth has quit [Ping timeout: 276 seconds]
pyth has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 246 seconds]
jonatack has joined #bitcoin-core-dev
spynx has joined #bitcoin-core-dev
spynxic has quit [Remote host closed the connection]
LainExperiments has joined #bitcoin-core-dev
<darosior>
Does anyone have data on the number of RPCs per release by any chance?