<glozow>
A few chunks have been split off from #26711. #28764 and #28758 should be reviewable by anyone (ie without knowing everything about mempool/validation)
<achow101>
#topic contents of the 26 testing guide (maxedw)
<core-meetingbot>
topic: contents of the 26 testing guide (maxedw)
<stickies-v>
if maxedw is not here i'm happy to cover this for him, he sent me his proposal yesterday
<stickies-v>
maxedw are you here?
<sipa>
hi
<maxedw>
after reading the release notes, these topics struck me as potentially good candidates: V2 Transport (BIP 324), assumeutxo, Submit packag, Wallet loading /migration, Importmempool rpc
<stickies-v>
so i think you're looking for feedback about whether or not these topics make sense, or if anyone has topics they think would benefit well from being in the testing guide?
<maxedw>
yes, any feedback on if these are good topics or if I've missed an important one
<achow101>
since assumeutxo and 324 are disabled by default, I'm not sure how useful it is to test those in the release candidates
<sipa>
at least 324 is testable on mainnet even
<fjahr>
I would say it makes even more sense to advertise testing them because of that
<stickies-v>
achow101: wouldn't we especially want to test those, given that they're new?
<stickies-v>
we'll also be hosting a review club around the testing guide btw, so what we have done before is let attendees peer with each other (e.g. for CJDNS)
<achow101>
stickies-v: isn't the purpose of the testing guide to test the release candidates prior to the final release?
<sipa>
it depends what kind of testing we want... things relating to how an end user will interact with them, probably not
<stickies-v>
well yes but the functionality is there, so we'd want to make sure there are no bugs, even if disabled by default
<sipa>
achow101: that's a fair point; issues discovered through testing of features that aren't actually usable in production wouldn't really affect whether we promote an RC to final
<maxedw>
so are we thinking drop assumeutxo and 324?
<fanquake>
We still need to do some testing / sanity checking though. Otherwise we might ship bins with a broken 324 impl and then it won't work for all the power users that want to turn it on
<maxedw>
I don't mind making a separate testing guide on those things for review club if that's a best of both situation?
<stickies-v>
achow101: wdyt about the wallet loading PR (#24914)? is that worth testing? my initial view was no, but i'm not familiar with the PR
<achow101>
there isn't anything use facing to test
<achow101>
*user
<sipa>
i think there's a difference between BIP324 and assumeutxo still; the former will probably end up being enabled by some, on mainnet, following 26.0 release, while assumeutxo is actually not usable on mainnet
<achow101>
other than your wallet loads, which it will because we have functional tests for that
<stickies-v>
okay yeah thx that was my assumption as well, would drop that from the guide then
<sipa>
but also, all testing results are welcome of course, even if they just result in changes in master that don't make it to 26.0
<sipa>
it's more a question of priority i think
<sipa>
the closer a feature is to being usable the more important it is that it works well
<maxedw>
sipa: there is a new RPC for assumeutxo `loadtxoutset`
<stickies-v>
we've previously also had a bonus section in the testing guide near the end, so could put assumeutxo there? still useful feedback, but won't block 26 final
<sipa>
maxedw: yes, but you can't use it on mainnet IIRC?
<lightlike>
I think that bip324 has sufficient "hype" in the wider community that many users will turn it on on mainnet - so it should be included in the testing.
<achow101>
For MacOS users, the packaging change to use a zip instead of dmg?
<fanquake>
I think he was going to write rel notes
<darosior>
Will do
<stickies-v>
achow101: yeah i think the macos packaging stuff would be good to add indeed, very quick to test too
<fjahr>
IMO BIP324 should definitely be included, there are a lot of people excited about turning it on in mainnet. For assumeutxo I would really like it if there would still be some encouragement still to test it. Bonus section sounds good to me.
<maxedw>
I was unsure about importmempool RPC as it sounded like it was the same mechanism as what was available before, now just available via RPC
<stickies-v>
fyi maxedw the macos packaging stuff is PR #28432
<maxedw>
so are we thinking: BIP324, Submit package, MacOS packaging, TapMiniscript
<maxedw>
and importmempool RPC?
<achow101>
I think there's a bunch of smaller things that we want testing in the RCs that don't have release notes. you might want to look at the git log since 25.0
<achow101>
importmempool seems fine to test
<abubakarsadiq>
could be nice to add some RPC test also like #26485
<maxedw>
I wonder if that one can be tested as part of the others
<stickies-v>
yup, combining maxes sense 👍
<achow101>
couple other ones that might be useful: deprecation of creating new legacy wallets, submitpackage's new restrictions
<maxedw>
I can go through the git log, shall I report back in this channel any other suggestions I find?
<sipa>
<Murch> @maxedw I wouldn’t mind if Ancestor Aware Funding made the testing guide. Send a few transactions to yourself with unconfirmed inputs at different feerates and see if something unexpected happens.
<lightlike>
#27213 (outbound connection management wrt networks) is also a possibility
<gribble>
https://github.com/bitcoin/bitcoin/issues/27213 | p2p: Diversify automatic outbound connections with respect to networks by amitiuttarwar · Pull Request #27213 · bitcoin/bitcoin · GitHub
<sipa>
(relaying for Murch who seems to have IRC-Matrix bridge issues)
<stickies-v>
i'd say don't let (lack of/slow) feedback hold you back on making progress with the guide though, thank you for working on this!
<ajonas>
maxedw: maybe just write up the list on the devwiki (where this will ultimately live) and return back next week with a request for comments
<darosior>
Yeah, thanks for doing this maxedw.
<sipa>
indeed ^
<maxedw>
can do ajonas
<glozow>
thank you maxedw!
<maxedw>
no probs all!
<achow101>
#topic mailing list (kanzure)
<core-meetingbot>
topic: mailing list (kanzure)
<kanzure>
linuxfoundation.org has decided to stop hosting mailing lists, which includes bitcoin-dev (and btw lightning-dev but i don't know who manages that). they have offered or agreed to continue to preserve/host the email archive urls and content.
<kanzure>
no proposal or answers yet, so that's all i have for this meeting really.
<kanzure>
uh, an email should be going out at ~some point, to the mailing list.
<achow101>
if the mailing list changes to somewhere else, will the old email still work (autoforward)
<RubenSomsen>
Options I've seen thus far are delvingbitcoin.org, groups.io, mailman3.com, or finding someone else to host mailman2
<kanzure>
we could ask them about auto-forward. they have either offered or agreed to keep the email archive urls up, but maybe we could ask them to redirect to another location if that's what we want.
<RubenSomsen>
Functionality wise I think what's important are easy back-ups, transparency (no stealth edits), and a reliable host
<achow101>
I think we can have that discussion on the list
<sipa>
This discussion really belongs on the mailinglist.
<sipa>
It's good to inform people here about the problem, but this isn't the place to discuss it.
<RubenSomsen>
Sure
<achow101>
for the bitcoin-core-dev list, it's an announcement's only list, so we really can just move that whereever
willcl-ark_ has left #bitcoin-core-dev [#bitcoin-core-dev]
<core-meetingbot>
Meeting ended Thu Nov 2 14:46:03 2023 UTC.
<achow101>
Also, daylight savings time is changing/has already changed. check your time and don't miss the meeting!
brunoerg has quit [Remote host closed the connection]
vasild has quit [Ping timeout: 256 seconds]
vasild has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<gleb>
shoot, the time savings thing totally happened to me.
<bitcoin-git>
[bitcoin] BrandonOdiwuor opened pull request #28776: Wallet: Functions to enable adding used balance to GUI overview page (master...gui_overview_page_add_used_balance) https://github.com/bitcoin/bitcoin/pull/28776
brunoerg has quit [Remote host closed the connection]
test__ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
flooded has quit [Ping timeout: 260 seconds]
brunoerg has quit [Ping timeout: 255 seconds]
AaronvanW has quit [Quit: Leaving...]
bugs_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
BrinkingChancell has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has quit [Ping timeout: 260 seconds]
<bitcoin-git>
[bitcoin] fanquake opened pull request #28778: depends: drop -O1 workaround from arm64 apple Qt build (master...drop_O1_workaround_qt) https://github.com/bitcoin/bitcoin/pull/28778
brunoerg has joined #bitcoin-core-dev
salvatoshi has quit [Ping timeout: 245 seconds]
preimage has joined #bitcoin-core-dev
benwestgate has quit [Read error: Connection reset by peer]
brunoerg has quit [Remote host closed the connection]
salvatoshi has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] kevkevinpal closed pull request #28454: wallet: allowing walletpassphrase timeout to be MAX_SLEEP_TIME if set to -1 (master...defaultWalletPassphraseTimeout) https://github.com/bitcoin/bitcoin/pull/28454