--- Log opened Thu Jan 23 00:00:56 2025
00:02 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 245 seconds]
00:17 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
00:23 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
00:39 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
00:44 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 264 seconds]
01:00 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
01:05 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
01:38 < 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
01:42 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 244 seconds]
01:46 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5acf12bafeb1...449a25b9582e
01:46 < bitcoin-git> bitcoin/master c31166a Hennadii Stepanov: cmake: Fail if `Libmultiprocess` is missing when `WITH_MULTIPROCESS=ON`
01:46 < bitcoin-git> bitcoin/master 449a25b merge-script: Merge bitcoin/bitcoin#31709: cmake: Fail if `Libmultiprocess` is missing w...
01:46 < bitcoin-git> [bitcoin] fanquake merged pull request #31709: cmake: Fail if `Libmultiprocess` is missing when `WITH_MULTIPROCESS=ON` (master...250122-mp-error) https://github.com/bitcoin/bitcoin/pull/31709
01:49 -!- purpleKarrot [~purpleKar@2001:1620:5547:0:fafe:5eff:fe5b:42e9] has joined #bitcoin-core-dev
01:52 -!- Cory93 [~Cory93@user/pasha] has quit [Quit: Client closed]
01:52 -!- Cory93 [~Cory93@user/pasha] has joined #bitcoin-core-dev
02:10 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
02:16 -!- Nebraskka [~Nebraskka@user/nebraskka] has joined #bitcoin-core-dev
02:19 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
02:36 < bitcoin-git> [bitcoin] fanquake closed pull request #28055: Bugfix: net_processing: Restore "Already requested" error for FetchBlock (master...fix_getblockfrompeer_rereq_err) https://github.com/bitcoin/bitcoin/pull/28055
02:46 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
02:47 < bitcoin-git> [bitcoin] maflcko closed pull request #31717: docs: fix  README.md (master...docs-fix) https://github.com/bitcoin/bitcoin/pull/31717
02:51 < 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
02:54 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/449a25b9582e...59876b3ad71c
02:54 < bitcoin-git> bitcoin/master 733fa0b Antoine Poinsot: miner: never create a template which exploits the timewarp bug
02:54 < bitcoin-git> bitcoin/master 59876b3 merge-script: Merge bitcoin/bitcoin#31376: Miner: never create a template which exploits...
02:54 < 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
03:05 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
03:08 -!- purpleKarrot [~purpleKar@2001:1620:5547:0:fafe:5eff:fe5b:42e9] has quit [Quit: Client closed]
03:09 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 248 seconds]
03:18 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/59876b3ad71c...94f0adcc31d2
03:18 < bitcoin-git> bitcoin/master d38ade7 Hennadii Stepanov: qa: Use `sys.executable` when invoking other Python scripts
03:18 < bitcoin-git> bitcoin/master 94f0adc merge-script: Merge bitcoin/bitcoin#31541: qa: Use `sys.executable` when invoking other ...
03:18 < bitcoin-git> [bitcoin] fanquake merged pull request #31541: qa: Use `sys.executable` when invoking other Python scripts (master...241219-qa-signers) https://github.com/bitcoin/bitcoin/pull/31541
03:22 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
03:26 -!- arferreira3 [~arferreir@syn-075-112-159-147.biz.spectrum.com] has quit [Remote host closed the connection]
03:40 -!- Guest45 [~Guest45@105.172.82.238] has joined #bitcoin-core-dev
03:41 -!- eval-exec [~Thunderbi@144.34.183.180.16clouds.com] has quit [Ping timeout: 265 seconds]
03:43 -!- Guest45 [~Guest45@105.172.82.238] has quit [Client Quit]
03:43 -!- Guest45 [~Guest45@105.172.82.238] has joined #bitcoin-core-dev
03:44 -!- Guest45 [~Guest45@105.172.82.238] has quit [Client Quit]
03:52 < bitcoin-git> [bitcoin] hebasto closed pull request #31613: depends, NetBSD: Fix `bdb` package compilation with GCC-14 (master...250106-netbsd-bdb) https://github.com/bitcoin/bitcoin/pull/31613
03:54 < bitcoin-git> [bitcoin] hebasto closed pull request #31504: cmake: De-duplicate libraries on link lines opportunistically (master...241215-duplicate) https://github.com/bitcoin/bitcoin/pull/31504
04:21 -!- jespada [~jespada@2800:a4:2317:8200:52e:e131:1453:b068] has joined #bitcoin-core-dev
04:26 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
04:43 < bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/94f0adcc31d2...2317e6cf2da8
04:43 < bitcoin-git> bitcoin/master fa9593e MarcoFalke: test: Use high-level python types
04:43 < bitcoin-git> bitcoin/master fa9aced MarcoFalke: test: Check that reindex with prune wipes blk files
04:43 < bitcoin-git> bitcoin/master 2317e6c merge-script: Merge bitcoin/bitcoin#31696: test: Check that reindex with prune wipes blk...
04:43 < bitcoin-git> [bitcoin] fanquake merged pull request #31696: test: Check that reindex with prune wipes blk files (master...2501-test-reindex-prune) https://github.com/bitcoin/bitcoin/pull/31696
04:50 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2317e6cf2da8...188b02116d84
04:50 < bitcoin-git> bitcoin/master 4da7bfd brunoerg: test: add coverage for unknown address type for `createwalletdescriptor`
04:50 < bitcoin-git> bitcoin/master 188b021 merge-script: Merge bitcoin/bitcoin#31635: test: add coverage for unknown address type f...
04:50 < bitcoin-git> [bitcoin] fanquake merged pull request #31635: test: add coverage for unknown address type for `createwalletdescriptor` (master...2025-01-test-wallet-createwalletdescriptor) https://github.com/bitcoin/bitcoin/pull/31635
04:53 -!- eval-exec [~Thunderbi@45.78.56.68.16clouds.com] has joined #bitcoin-core-dev
05:15 -!- Earnestly [~earnest@user/earnestly] has quit [Read error: Connection reset by peer]
05:18 < bitcoin-git> [bitcoin] hodlinator opened pull request #31723: qa debug: Add --debugnode/-waitfordebugger [DRAFT] (master...2024/06/wait_for_debugger) https://github.com/bitcoin/bitcoin/pull/31723
05:21 -!- Earnestly [~earnest@user/earnestly] has joined #bitcoin-core-dev
05:22 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
05:32 -!- c2 [~c@user/uyea] has quit [Ping timeout: 252 seconds]
05:32 -!- jrayhawk [~jrayhawk@user/jrayhawk] has quit [Ping timeout: 252 seconds]
05:34 -!- jrayhawk [~jrayhawk@user/jrayhawk] has joined #bitcoin-core-dev
05:38 -!- eval-exec1 [~Thunderbi@93.179.103.163.16clouds.com] has joined #bitcoin-core-dev
05:39 -!- eval-exec [~Thunderbi@45.78.56.68.16clouds.com] has quit [Ping timeout: 246 seconds]
05:39 -!- eval-exec1 is now known as eval-exec
05:43 -!- c [~c@172.245.81.218] has joined #bitcoin-core-dev
05:43 -!- S3RK [~S3RK@user/s3rk] has joined #bitcoin-core-dev
05:46 -!- S3RK_ [~S3RK@user/s3rk] has quit [Ping timeout: 252 seconds]
05:58 -!- Emc99 [~Emc99@212.129.76.254] has joined #bitcoin-core-dev
06:00 < Sjors[m]> Meeting?
06:01 -!- Emc99 [~Emc99@212.129.76.254] has quit [Client Quit]
06:01 < fanquake> Weekly Meeting Thursday @ 16:00 UTC
06:02 -!- virtu [~virtu@user/virtu] has joined #bitcoin-core-dev
06:02 -!- kevkevin [~kevkevin@209.242.39.30] has quit [Ping timeout: 252 seconds]
06:02 < Sjors[m]> Ah we bumped the time?
06:02 < Sjors[m]> Alright, will be back in 2 hours.
06:02 < fanquake> Yes. It changed at the last meeting.
06:08 < bitcoin-git> [bitcoin] hebasto opened pull request #31724: cmake: Fix `-pthread` flags in summary (master...250123-cmake-pthread) https://github.com/bitcoin/bitcoin/pull/31724
06:25 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/188b02116d84...9914e7372976
06:25 < bitcoin-git> bitcoin/master 5c3e4d8 Antoine Poinsot: doc: add a section about using MSan
06:25 < bitcoin-git> bitcoin/master 9914e73 merge-script: Merge bitcoin/bitcoin#31704: doc: add a section in the fuzzing documentati...
06:25 < 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
06:29 -!- kevkevin [~kevkevin@209.242.39.30] has joined #bitcoin-core-dev
06:30 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
06:32 -!- catnip [~catnip@host-92-13-94-227.as13285.net] has joined #bitcoin-core-dev
07:00 -!- Netsplit *.net <-> *.split quits: adiabat_, S3RK, maflcko, jamesob1566, bugs_, TheRec_, instagibbs, theStack
07:06 -!- Netsplit over, joins: adiabat_, S3RK, instagibbs, jamesob1566, maflcko, bugs_, TheRec_, theStack
07:07 < 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
07:19 < 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
07:24 -!- eval-exec [~Thunderbi@93.179.103.163.16clouds.com] has quit [Ping timeout: 245 seconds]
07:37 < bitcoin-git> [bitcoin] sipa closed pull request #28678: miniscript: convert non-critical asserts to Assumes (master...202310_miniscript_assume) https://github.com/bitcoin/bitcoin/pull/28678
07:40 -!- dzxzg [~dzxzg@user/dzxzg] has joined #bitcoin-core-dev
07:41 -!- catnip [~catnip@host-92-13-94-227.as13285.net] has quit [Ping timeout: 240 seconds]
07:44 -!- mcey_ [~emcy@148.252.128.80] has joined #bitcoin-core-dev
07:45 < 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
07:47 -!- preimage [~halosghos@user/halosghost] has joined #bitcoin-core-dev
07:48 -!- emcy__ [~emcy@85.255.235.171] has quit [Ping timeout: 272 seconds]
07:59 -!- core-meetbot [~limnoria@user/core-meetbot] has quit [Remote host closed the connection]
07:59 -!- core-meetbot [~limnoria@user/core-meetbot] has joined #bitcoin-core-dev
08:00 < achow101> #startmeeting
08:00 < core-meetbot> achow101: Meeting started at 2025-01-23T16:00+0000
08:00 < core-meetbot> achow101: Current chairs: achow101
08:00 < core-meetbot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
08:00 < core-meetbot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
08:00 < core-meetbot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
08:00 < Murch[m]> Hi
08:00 < achow101> #bitcoin-core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto instagibbs jarolrod jonatack josibake kanzure laanwj LarryRuane lightlike luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
08:00 < core-meetbot> achow101: Unknown command: #bitcoin
08:00 < hodlinator> hi
08:00 < Murch[m]> #here
08:00 < cfields> hi
08:00 < sipa> hi
08:00 < sr_gi[m]> #here
08:00 < lightlike> hi
08:00 < darosior> hi
08:00 < glozow> hi
08:00 < achow101> i've gotta change that bot command behavior..
08:00 < kevkevin> hi
08:00 < Sjors[m]> hi
08:00 < darosior> What's with the #here?
08:00 < abubakarsadiq> hi 
08:00 < dzxzg> hi
08:00 < pinheadmz> yo
08:00 < Murch[m]> "achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'"
08:01 < achow101> It actually doesn't matter
08:01 < sr_gi[m]> hi then :P
08:01 < achow101> saying anything works just as well
08:01 < sipa> #here FirstLast
08:01 < stickies-v> hi
08:01 < Murch[m]> lol
08:01 < achow101> sipa: but that confuses the bot
08:01 < furszy> hi
08:01 < tdb3> hi
08:01 < achow101> anyways. there's one preproposed meeting topic this week, any last minute ones to add
08:01 < sr_gi[m]> #hi FirstLast mybe? 
08:01 < core-meetbot> sr_gi[m]: Unknown command: #hi
08:01 < marcofleon> hi
08:02 < achow101> #topic Erlay WG Update (sr_gi, gleb, marcofleon)
08:03 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 272 seconds]
08:04 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
08:04 < sipa> sr_gi[m], gleb?
08:04 < sr_gi[m]> Following on the experiments I was mentioning last week, I got the results for a wide range of combinations of inbounds and outbounds for fanout selection. I haven't written down the whole experiment and conclusions yet, but the results can be found here: https://docs.google.com/spreadsheets/d/1uaoJW941edzDvZiJDNvXruiRbjpHXM0TSfrTunivjJY/edit?gid=1920160722#gid=1920160722
08:04 < jonatack> hi (slow internet here atm, sorry)
08:04 < sr_gi[m]> There first two tabs should the data volume per transaction in different configurations 
08:05 < maxedw> hi
08:05 -!- purpleKarrot [~purpleKar@2001:1620:5547:0:fafe:5eff:fe5b:42e9] has joined #bitcoin-core-dev
08:05 < 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
08:05 < kanzure> hi
08:06 < sr_gi[m]> So I'll check on some of those next. 
08:06 < sr_gi[m]> I think Gleb also had a plan on his end but not sure if he's around
08:08 < sr_gi[m]> He'll share next time. That's all on my end
08:08 < achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
08:08 -!- brunoerg_ [~brunoerg@2804:14d:5285:84b2::1000] has quit []
08:09 -!- brunoerg [~brunoerg@2804:14d:5285:84b2::1000] has joined #bitcoin-core-dev
08:09 < brunoerg> hi
08:10 < sipa> sdaftuar is continuing his rebase of #28676 on top of my txgraph code (up to and including #31553)
08:10 <@gribble> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
08:10 <@gribble> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
08:10 < sipa> i hear there is progress
08:10 < sipa> we also did an in-person code review of a part of #31363 with him and instagibbs and glozow, hoping to get more eyes/comments soon
08:11 <@gribble> https://github.com/bitcoin/bitcoin/issues/31363 | cluster mempool: introduce TxGraph by sipa · Pull Request #31363 · bitcoin/bitcoin · GitHub
08:11 < sipa> that's it from me
08:11 < glozow> There will be a review club meeting on #31363 on February 5
08:11 <@gribble> https://github.com/bitcoin/bitcoin/issues/31363 | cluster mempool: introduce TxGraph by sipa · Pull Request #31363 · bitcoin/bitcoin · GitHub
08:11 < sipa> oooh!
08:11 < glozow> Can't guarantee more eyes, but can promise I will write some notes before then
08:13 < achow101> #topic MuSig2 WG Update (achow101)
08:13 < achow101> #31242 was merged. Spent a bunch of time working on #31622 and fixing the issues there. It should not be ready for review.
08:13 < core-meetbot> achow101: Unknown command: #31242
08:13 <@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
08:13 <@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
08:13 <@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
08:13 < achow101> s/not/now
08:14 < achow101> I'll also be working on fixed test vectors for #31247 and to add to the bip
08:14 <@gribble> https://github.com/bitcoin/bitcoin/issues/31247 | psbt: MuSig2 Fields by achow101 · Pull Request #31247 · bitcoin/bitcoin · GitHub
08:14 < achow101> so that's been marked as a draft for now
08:15 < achow101> the prs to review are #31243 and #31622
08:15 <@gribble> https://github.com/bitcoin/bitcoin/issues/31243 | descriptor: Move filling of keys from `DescriptorImpl::MakeScripts` to `PubkeyProvider::GetPubKey` by achow101 · Pull Request #31243 · bitcoin/bitcoin · GitHub
08:15 <@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
08:15 < achow101> #topic Legacy Wallet Removal WG Update (achow101)
08:15 < achow101> #31495 has been getting some review and is still the pr to review
08:15 < core-meetbot> achow101: Unknown command: #31495
08:15 <@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
08:15 <@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
08:16 < darosior> bad bot
08:16 < achow101> and #31241 is probably rfm.
08:16 <@gribble> https://github.com/bitcoin/bitcoin/issues/31241 | wallet: remove BDB dependency from wallet migration benchmark by furszy · Pull Request #31241 · bitcoin/bitcoin · GitHub
08:16 < achow101> which I'll take another look at today
08:16 < achow101> #topic orphan resolution WG Update (glozow)
08:17 < glozow> The current PR to review is #31666, the followup from #31397.
08:17 <@gribble> https://github.com/bitcoin/bitcoin/issues/31666 | multi-peer orphan resolution followups by glozow · Pull Request #31666 · bitcoin/bitcoin · GitHub
08:17 <@gribble> https://github.com/bitcoin/bitcoin/issues/31397 | p2p: track and use all potential peers for orphan resolution by glozow · Pull Request #31397 · bitcoin/bitcoin · GitHub
08:17 < 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
08:17 < 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 🤒).
08:18 < glozow> TLDR, it will make TxOrphanage no longer global; we'll have limits per-peer
08:19 < sipa> well, the TxOrphanage instance itself remains global, it's just the accounting that happens per peer?
08:19 -!- jespada [~jespada@2800:a4:2317:8200:52e:e131:1453:b068] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
08:19 < sipa> or do you think actually making the orphanage per-peer is simpler?
08:19 < glozow> sipa: yes, still a global `TxOrphanage` object
08:19 < sipa> alright
08:20 < 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.
08:20 < glozow> vasild sent me some interesting logs a few weeks ago (thank you)
08:20 < instagibbs> you mean in general on master or whic hpr
08:20 < sipa> glozow: happy to run some, what PR/options?
08:21 < glozow> on top of #31666 would be best
08:21 <@gribble> https://github.com/bitcoin/bitcoin/issues/31666 | multi-peer orphan resolution followups by glozow · Pull Request #31666 · bitcoin/bitcoin · GitHub
08:21 < glozow> sorry not "debug-only" haha. I mean in debug mode. Brain a bit fuzzy right now.
08:21 < achow101> glozow: I can setup one of my nodes to do that
08:22 < instagibbs> removes all logic but Assumes()
08:22 < darosior> I can run a mainnet node on this PR too
08:23 < glozow> Thank you very much!
08:23 < achow101> #topic Stratum v2 WG Update (sjors)
08:23 < glozow> That's all from me
08:23 < Sjors[m]> Suggested by darosior, he'll elaborate shortly. From my end, I think there's three questions that are good to discuss:
08:23 < Sjors[m]> 1. Are people still on board with including libmultiprocess in the release build at some point?
08:23 < Sjors[m]> 2. Can we do that for v29 or is it not good enough yet for a "Bitcoin Core seal of approval", even if marked experimental?
08:23 < achow101> Sjors[m]: oops wrong topic
08:23 < Sjors[m]> 3. Are the specific things still missing?
08:24 < achow101> #topic Adding multiprocess binaries to release build (#30975) (sjors)
08:24 < Sjors[m]> Well that's fine, it's about #30975
08:24 <@gribble> https://github.com/bitcoin/bitcoin/issues/30975 | Add multiprocess binaries to release build (except Windows, OpenBSD) by Sjors · Pull Request #30975 · bitcoin/bitcoin · GitHub
08:24 <@gribble> https://github.com/bitcoin/bitcoin/issues/30975 | Add multiprocess binaries to release build (except Windows, OpenBSD) by Sjors · Pull Request #30975 · bitcoin/bitcoin · GitHub
08:24 < 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.
08:24 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
08:24 < 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
08:24 < 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.
08:24 <@gribble> https://github.com/bitcoin/bitcoin/issues/30975 | Add multiprocess binaries to release build (except Windows, OpenBSD) by Sjors · Pull Request #30975 · bitcoin/bitcoin · GitHub
08:25 < achow101> I think we should do multiprocess releases eventually
08:25 < fanquake> Why are you still maintaining the "shove it into core" approach, when it's clear we are never going to do that?
08:25 < fanquake> I left my more general thoughts about multiprocess being added to the build here: https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2610191420
08:25 < sipa> fanquake: thanks for commenting there
08:25 < 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
08:25 < ryanofsky> (my response is below that, please take a look at that too)
08:26 < fanquake> Could you also elaborate on who is running it right now. i.e how many users?
08:26 -!- zeropoint [~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
08:26 < 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.
08:26 < Sjors[m]> fanquake: the SRI team runs the IPC version, they have a handful of testers using a custom signet.
08:27 < Sjors[m]> And afaik the new Demand pool runs the regular version.
08:27 < Sjors[m]> I have no idea how many, if any, people use Demand pool, they're still starting up as a business.
08:27 < fanquake> So a single pool using the old version (experimentally I assume) 
08:28 < Sjors[m]> fanquake: yes, it's partially a chicken-egg problem - without Bitcoin Core support Stratum v2 is dead on arrival
08:28 < ryanofsky> One idea is more people would use this if it were it were easier to use?
08:28 < 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
08:28 < Sjors[m]> And even experimenta support is a pain now.
08:28 < Sjors[m]> Because people have to install Bitcoin Core binaries from some random guy (me).
08:29 < 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
08:29 < achow101> I think the question is really whether multiprocess is ready enough for people to try to use it in production?
08:30 < 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
08:30 < sipa> to me, the answer to (1) is yes, but it is obviously contingent on it getting sufficient review
08:30 < 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.
08:30 < 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.
08:31 < 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
08:31 < fanquake> sipa: unfortunately during the life of libmultiprocess, getting sufficient reivew from anyone other 
08:31 < 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.
08:31 < darosior> I agree with sipa for (1). And as far as i'm aware we aren't there yet, unfortunately.
08:31 < fanquake> than Russ, has seemed to be very difficult
08:31 < fanquake> Sjors: bugs might be fine for the pools, but no so much for our CI
08:32 < ryanofsky> What is (1)? I'm having problems following this discussion...
08:32 < 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. 
08:32 < fanquake> and that is the current state of affairs, given there are multiple unsolved intermittent issues related to libmultiprocess
08:32 < 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?
08:32 < fanquake> I see that now there are some new PRs open in, https://github.com/chaincodelabs/libmultiprocess/pulls, but its unclear who is reviewing this changes?
08:32 < Sjors[m]> fanquake: fixing intermittend CI failures is always a good reason to wait with merging
08:33 < fanquake> If Russ dissapears (hopefuly not) tomorrow, are you planning on taking over maintainership libmultiprocess?
08:33 < 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.
08:34 < 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"
08:34 < 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".
08:34 < stickies-v> +1 darosior 
08:34 < 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.
08:34 < glozow> achow101: (sorry late but can we add topic v29.0 milestone today?)
08:34 < Sjors[m]> So that relates to my question (1)
08:35 < Sjors[m]> Whether we want multiprocess at all
08:35 < 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
08:35 < fanquake> Apparently the answer has been "yes", but "not quite enough" for almost 10 years
08:35 < 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"
08:36 -!- jackielove4u3 [~jackielov@user/jackielove4u] has joined #bitcoin-core-dev
08:36 < darosior> achow101: sure but there is a difference between no warranty and breaking our standards.
08:36 < 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
08:36 < 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
08:36 < fanquake> that alone seems like a weird place to be, to be merging this stuff
08:36 < 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
08:37 < 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
08:37 < sipa> so actually seeing it "going somewhere" may very realistically change how reviewers deal with it
08:37 < Sjors[m]> ryanofsky: I opened the topic with 3 questions, so that's what (1), (2) , (3) refer to.
08:38 < 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
08:38 < 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
08:38 < ryanofsky> Can we do something like install it in bin/experimental/? bin/unstable/?
08:38 -!- jackielove4u [~jackielov@user/jackielove4u] has quit [Ping timeout: 265 seconds]
08:38 -!- jackielove4u3 is now known as jackielove4u
08:38 < fanquake> achow101: I don't see how that could be true if you look at the PRs in the multiprocess repo
08:38 < 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!).
08:38 < achow101> unless the question is that this pr in particular doesn't meet review standards?
08:39 < 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.
08:39 < 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.
08:39 < 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.
08:40 < Sjors[m]> * it might
08:40 < Sjors[m]> (annoying, but not end of the world)
08:40 < sipa> fanquake: i agree with that, i'd rather have this discussion (in addition to here) also at coredev
08:40 < ryanofsky> I think we can also hash this out in the actual PR. (i also do not favor IRC)
08:40 < glozow> should we explore shifting v29.0 dates?
08:40 < 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 
08:40 < cfields> release cycle, have all devs dogfood it for 6 months, then discuss shipping it once we're all on the same page.
08:40 < 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.
08:41 < achow101> Sjors[m]: what's half a year to waiting 6 years already (or however long it's been, feels like forever)
08:41 < fanquake> sjors: i dissagree that we should do it, as long as there are no (known) bugs, there are other process/project issues here
08:41 < darosior> achow101: for multiprocess since 2017 :/
08:41 < fanquake> (there are still known bugs in either case)
08:41 < 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.
08:42 < Sjors[m]> I do not posess ryanofsky level patience :-)
08:42 < 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
08:43 < fanquake> How we ship multiprocess is another thing that is still undecided
08:43 < fanquake> #31375
08:43 < core-meetbot> fanquake: Unknown command: #31375
08:43 < ryanofsky> fanquake undecided as in not merged yet? i think we have a clear path
08:43 <@gribble> https://github.com/bitcoin/bitcoin/issues/31375 | multiprocess: Add bitcoin wrapper executable by ryanofsky · Pull Request #31375 · bitcoin/bitcoin · GitHub
08:43 <@gribble> https://github.com/bitcoin/bitcoin/issues/31375 | multiprocess: Add bitcoin wrapper executable by ryanofsky · Pull Request #31375 · bitcoin/bitcoin · GitHub
08:44 < 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.
08:44 < sipa> cfields: agreed
08:44 < achow101> doesn't the dev-mode preset turn it on?
08:44 < sipa> i haven't even gotten it to work the last time i tried
08:44 < ryanofsky> the PR does not turn multiprocess on by default for developers
08:44 < fanquake> That only works with depends though, whcih isn't part of the dev mode
08:44 < sipa> i think we should have it on in dev builds by default before considering adding to releases
08:44 < ryanofsky> that would be a nice step to take at some point the future
08:45 < cfields> ryanofsky: right, that's my point. Imo that ordering is backwards.
08:45 < darosior> Yeah you need a patch to build it because of an issue with libatomic
08:45  * fanquake and using libmulitprocess outside of depends, may or may not work depending on your os, see https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2610191420
08:45 < achow101> oh i installed libmultiprocess to my system, so dev-mode always builds with it. I don't necessarily test with it though
08:45 < darosior> sipa: +1
08:45 < sipa> fanquake: ah thanks
08:46 < fanquake> which is why I'm more in favour of vendoring, as it removes a whole class of issues
08:46 < ryanofsky> i see, so no feature can be in a release if it is not enabled by default in developer builds
08:46 < cfields> +1 for vendoring.
08:46 < sipa> ryanofsky: i think it's a reasonable bar, because we want to dogfood it actually working before shipping something, even if experimental?
08:46 < fanquake> ryanofsky: I think it's somewhat weird for us to be shipping things that developers are not actively building / using testing etc
08:46 < ryanofsky> yes, understood
08:47 < 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.
08:47 < cfields> and it makes sense to me in this case as well.
08:47 < darosior> +1
08:47 < ryanofsky> these are just new requests and I'm trying to boil them down
08:47 < 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.
08:48 < darosior> So is there any other thing we could do that would make your life easier Sjors[m]?
08:48 < 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)
08:49 < 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.
08:49 < 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.
08:50 < 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
08:50 < 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.
08:50 < hebasto> agree with vendoring libmultiprocess
08:50 < cfields> ryanofsky: Imo vendoring makes sense as a next step.
08:50 < sipa> agree
08:50 < cfields> to at least get everyone on the same page
08:50 < fanquake> Sjors: how what a separate from the main release build work? We aren't going to release/provide bin with unmerged/reviewed code
08:51 < 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
08:51 < ryanofsky> but understand if it's a minority opinion
08:52 < Sjors[m]> fanquake: if we vendor it, then we could guix build a bitcoin-node binary and ship that seperately?
08:52 < 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
08:53 < Sjors[m]> fanquake: that's already better than the status quo
08:53 < fanquake> Sjors: maybe, where do you want to distribute that from? A different download page on the website? github? etc
08:53 < Sjors[m]> Whatever is easier, the SRI documentation can point to it.
08:53 < achow101> it could just be in bitcoincore.org/bin and not actually on the downloads page
08:53 < 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.
08:54 < Sjors[m]> It would basically say "Please install Bitcoin Core from X instead of the normal place", then install the sidecar app.
08:54 < fanquake> RIght, so why can't SRI build and distribute this themselves?
08:54 < fanquake> Does this only work if it exists on bitcoincore.org
08:55 < fanquake> Surely bundling it with the sidecar would be even easier
08:55 < Sjors[m]> SRI is a Rust project, they're not going to release Bitcoin Core binaries I think.
08:55 < 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
08:55 < 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.
08:56 < fanquake> Sjors: I mean a tarball can have both the custom core bin, and the sidecar
08:56 < fanquake> which also removes this distribution problem, given they are downloading the sidecar in any case
08:56 < sipa> fanquake: i don't know if that's all that much of a reasonable distinction
08:56 < 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".
08:56 < 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.
08:56 < sipa> if we're working on it, it must mean that we want people to use it, whether we distribute it or others
08:56 < achow101> there's still one more topic for today's meeting
08:56 < cfields> maybe I'm underestimating how many devs are playing with it on a daily basis?
08:56 < fanquake> sipa: right, but it seems just as easy as making as host some special binaries for them
08:57 < sipa> fanquake: fair
08:57 < sipa> but neither should be the end goal
08:57 < sipa> as a temporary situation, i don't care much
08:57 < glozow> I think we should move on if there are other topics, e.g. wg updates
08:57 < sipa> agree
08:57 < 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.
08:58 < achow101> feel free to hash this out after the meeting
08:58 < achow101> #topic 29.0 milestone (glozow)
08:58 < darosior> sipa: seems like getting people to rely on temporary binaries we release may well be pretty permanent.
08:58 < 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
08:58 < glozow> As per #31029. We have feature freeze scheduled for Feb 20
08:58 <@gribble> https://github.com/bitcoin/bitcoin/issues/31029 | Release Schedule for 29.0 · Issue #31029 · bitcoin/bitcoin · GitHub
08:58 < glozow> That's 4 weeks away
08:58 < ryanofsky> s/importance/criticality/
08:59 < 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
08:59 < 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"
08:59 < glozow> But also, given earlier comments in this meeting, do people feel very strongly about changing the date?
09:00 < achow101> could we delay feature freeze to after coredev?
09:00 < darosior> glozow: i don't think changing the date would help with the previous topic discussed.
09:00 < darosior> achow101: why?
09:00 < sipa> i'd prefer not changing the date
09:00 -!- Emc99 [~Emc99@212.129.76.254] has joined #bitcoin-core-dev
09:00 < 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
09:00 < fanquake> achow101: do you have particular PRs in mind that would benefit from delaying
09:01 < 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"
09:01 < achow101> darosior: i think there are things currently milestoned for 29.0 that could make it in during/after coredev
09:01 < 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.
09:01 < glozow> sipa: yeah I agree with not doing last minute things at coredev
09:02 -!- jespada [~jespada@2800:a4:2317:8200:52e:e131:1453:b068] has joined #bitcoin-core-dev
09:02 < jonatack> PRs labeled as v29 milestone: https://github.com/bitcoin/bitcoin/milestone/69
09:02 < 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.
09:03 < glozow> Ok then we'll keep the date as is, and the coredev conversation can be about having it in v30
09:03 < jonatack> #proposedmeetingtopic release management rotation
09:03 < core-meetbot> jonatack: Unknown command: #proposedmeetingtopic
09:03 < achow101> fanquake: I think the legacy wallet removal stuff would benefit, but I don't feel that strongly
09:04 < achow101> anyways, we're out of time
09:04 < achow101> jonatack: we can do that next week
09:04 < glozow> jonatack: what do you mean by that?
09:04 < achow101> #endmeeting
09:04 < core-meetbot> achow101: Meeting ended at 2025-01-23T17:04+0000
09:04 < core-meetbot> achow101: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-01-23_16_00.log.json
09:04 < core-meetbot> achow101: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-01-23_16_00.log.html
09:04 < core-meetbot> achow101: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-01-23_16_00.html
09:05 < 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
09:05 < jonatack> when the laanwj -> when the lead maintainer
09:05 < fanquake> it is currently being rotated
09:05 < fanquake> i did 27
09:05 < fanquake> achow did 28
09:05 < achow101> we're rotating, mostly
09:05 < fanquake> gloria will do 29
09:06 < 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
09:06 < jonatack> I see. I'll read through that meeting again.
09:07 < fanquake> website updated, bin uploading etc also a bit spread, can see who's doing anything via all the PRs in either case
09:07 < 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
09:07 < achow101> moreso recently though
09:08 < bitcoin-git> [bitcoin] l0rinc closed pull request #31699: test,bench: validate `CheckTransaction`'s duplicate input detection in broader context (master...l0rinc/bench-processtransaction) https://github.com/bitcoin/bitcoin/pull/31699
09:08 < 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.
09:08 < 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
09:08 < 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..
09:09 < glozow> If you want to participate in the release process, reviewing backports is the majority of the labor
09:09 < achow101> jonatack: non-maintainers is a bit meh due to the elevated permissions required
09:09 < fanquake> achow101: yes, that will be happening, possibly from cfields, but nothing concrete yet
09:09 < glozow> the majority of the non-perms labor*
09:10 < darosior> Agree it is part of the role of maintainer of doing releases.
09:10 < glozow> Here's a list of things, I marked them by whether or not they require perms. Most of them take about 10 seconds, but main thing that people could help with is backports review. https://github.com/glozow/bitcoin-notes/blob/master/release_checklist.md
09:11 < 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.
09:11 < jonatack> Thanks. No need for a meeting topic for now. It's a thought I have from time to time when recalling that meeting. 
09:15 -!- mcey_ [~emcy@148.252.128.80] has quit [Ping timeout: 264 seconds]
09:16 -!- Emc99 [~Emc99@212.129.76.254] has quit [Quit: Client closed]
09:18 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
09:18 -!- mcey [~emcy@185.69.145.48] has joined #bitcoin-core-dev
09:18 -!- catnip [~catnip@host-92-13-94-227.as13285.net] has joined #bitcoin-core-dev
09:20 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 265 seconds]
09:23 < fanquake> achow101: can you add the next most-relevant wallet removal PR to the 29.x milestone
09:25 -!- catnip [~catnip@host-92-13-94-227.as13285.net] has quit [Quit: Client closed]
09:26 -!- dzxzg [~dzxzg@user/dzxzg] has quit [Ping timeout: 240 seconds]
09:27 < achow101> fanquake: added #31495
09:27 <@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
09:32 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
09:34 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
09:42 < Sjors[m]> Thanks for the discussion everyone. I marked #30975 draft and left a comment linking to the meeting, addressing some of the comments. 
09:42 <@gribble> https://github.com/bitcoin/bitcoin/issues/30975 | Add multiprocess binaries to release build (except Windows, OpenBSD) by Sjors · Pull Request #30975 · bitcoin/bitcoin · GitHub
09:43 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9914e7372976...d5a2ba44ba4f
09:43 < bitcoin-git> bitcoin/master fad83e7 MarcoFalke: doc: Fix incorrect send RPC docs
09:43 < bitcoin-git> bitcoin/master d5a2ba4 merge-script: Merge bitcoin/bitcoin#31416: doc: Fix incorrect send RPC docs
09:43 < bitcoin-git> [bitcoin] fanquake merged pull request #31416: doc: Fix incorrect send RPC docs (master...2412-doc-rpc) https://github.com/bitcoin/bitcoin/pull/31416
09:46 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
09:49 < 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?
09:51 < Sjors[m]> jeremyrubin: a non-ranged descriptor should look like tr(xpub/0) and you don't need to provide a range arugment
09:51 < Sjors[m]> Did you try to do tr(xpub/*) with range [0,0] ?
09:52 < jonatack> found the initial IRC meeting: "topic: Training to rotate release responsibility (neha)"
09:52 < jonatack> https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-07-01#689418;
09:52 <@gribble> https://github.com/bitcoin/bitcoin/issues/689418 | HTTP Error 404: Not Found
09:52 < jeremyrubin> walletutil WalletDescriptor requires range arguments
09:54 < Sjors[m]> Do you mean the bitcoin-wallet binary?
09:54 < 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)
09:54 < jeremyrubin> Ah, no I'm working on some experimental RPCs that make use of the functionality directly 
09:55 < jeremyrubin> so am really asking about that the constructor for WalletDescriptor accepts range_start = 0, range_end = 0
09:55 < achow101> jeremyrubin: range is ignored for non-ranged descriptors
09:55 < achow101> just don't change the range if you're trying to update an existing descriptor
09:56 < 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
09:56 < jeremyrubin> the change was dropping one tapscript branch
09:58 < achow101> if the error message says [0,0], the range is actually stored as [0, 1)
09:58 -!- preimage [~halosghos@user/halosghost] has quit [Ping timeout: 264 seconds]
10:00 < achow101> except for display, the range is always beginning inclusive, end exclusive
10:00 < jeremyrubin> https://gist.github.com/JeremyRubin/dd86544f79a0072ff4647e5b22ff35fa code snippet; might be pointing to a discrepency in how single leaf taptree vs multi leaf taptree is being handled
10:00 < jeremyrubin> on inferdescriptor 
10:00 -!- preimage [~halosghos@user/halosghost] has joined #bitcoin-core-dev
10:01 < achow101> no, the error is entirely about what is in the wallet already
10:01 < achow101> inferdescriptor doesn't do anything with ranges
10:01 < achow101> and if inferdescriptor infers an entirely different descriptor, you would not have this error
10:02 < achow101> jeremyrubin: does this snippet have the change to WalletDescriptor's arguments that made it work?
10:02 < achow101> or is this the original descriptor?
10:02 < achow101> or something else?
10:03 < achow101> also you have start=1, end=0, which doesn't make any sense
10:05 -!- preimage [~halosghos@user/halosghost] has quit [Ping timeout: 246 seconds]
10:07 -!- preimage [~halosghos@user/halosghost] has joined #bitcoin-core-dev
10:11 -!- core-meetbot [~limnoria@user/core-meetbot] has quit [Remote host closed the connection]
10:12 -!- core-meetbot [~limnoria@user/core-meetbot] has joined #bitcoin-core-dev
10:12 -!- jespada [~jespada@2800:a4:2317:8200:52e:e131:1453:b068] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
10:17 -!- preimage [~halosghos@user/halosghost] has quit [Quit: WeeChat 4.5.1]
10:27 -!- core-meetbot [~limnoria@user/core-meetbot] has quit [Remote host closed the connection]
10:27 -!- core-meetbot [~limnoria@user/core-meetbot] has joined #bitcoin-core-dev
10:31 -!- core-meetbot [~limnoria@user/core-meetbot] has quit [Remote host closed the connection]
10:32 -!- core-meetbot [~limnoria@user/core-meetbot] has joined #bitcoin-core-dev
10:35 -!- jonatack [~jonatack@user/jonatack] has quit [Read error: Connection reset by peer]
10:36 -!- dongcarl [~dongcarl@syn-066-065-169-019.res.spectrum.com] has quit [Ping timeout: 244 seconds]
10:38 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:45 < jeremyrubin> yes this is what made it work, with 0, 0 it failed
10:46 < 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)
10:46 < jeremyrubin> so 0 1 0 should be start=0, end = 0, next = 0
10:46 < jeremyrubin> * start = 0, end = 1, next = 0
10:47 < jeremyrubin> when it is set to start = 0, end = 0, next = 0, then I get the failure
10:52 < achow101> ah missed creation was being passed
10:52 < achow101> is the same function producing the descriptor both times?
11:01 < jeremyrubin> yes
11:04 -!- jespada [~jespada@2800:a4:2317:8200:52e:e131:1453:b068] has joined #bitcoin-core-dev
11:05 < achow101> is there a reason you are calling UpdateWalletDescriptor?
11:05 < achow101> I think there's probably bug, but we never tested that on non-ranged descriptors since it doesn't really make sense to
11:06 -!- jespada [~jespada@2800:a4:2317:8200:52e:e131:1453:b068] has quit [Client Quit]
11:08 < jeremyrubin> I'm not actually, I'm calling CWallet::AddWalletDescriptor
11:09 < achow101> multiple times, presumably
11:10 < jeremyrubin> good catch -- you found a bug in my code XD
11:10 < jeremyrubin> was supposed to be calling it with A then B, was calling with A twice by mistake
11:10 < jeremyrubin> so yes, was calling twice
11:10 < achow101> i see. well there's probably a bug in UpdateWalletDescriptor too
11:11 < jeremyrubin> it still seems like a bug yeah
11:11 < jeremyrubin> since at very least AddWalletDescriptor should be idempotent
11:15 < 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 :)
11:16 < jeremyrubin> (verified working with 0,0 and AB)
11:16 < achow101> can you open an issue for the range bug?
11:17 < jeremyrubin> yeah np
11:18 -!- core-meetbot [~limnoria@user/core-meetbot] has quit [Remote host closed the connection]
11:18 -!- core-meetbot [~limnoria@user/core-meetbot] has joined #bitcoin-core-dev
11:25 < jeremyrubin> #31728
11:25 <@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
11:30 -!- core-meetbot [~limnoria@user/core-meetbot] has quit [Remote host closed the connection]
11:31 -!- core-meetbot [~limnoria@user/core-meetbot] has joined #bitcoin-core-dev
11:44 -!- purpleKarrot [~purpleKar@2001:1620:5547:0:fafe:5eff:fe5b:42e9] has quit [Quit: Client closed]
11:46 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
11:51 -!- pyth [~pyth@123.25.162.204] has quit [Ping timeout: 244 seconds]
11:52 -!- pyth [~pyth@94.131.10.128] has joined #bitcoin-core-dev
12:15 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:30 -!- pyth [~pyth@94.131.10.128] has quit [Ping timeout: 276 seconds]
12:31 -!- pyth [~pyth@123.25.162.204] has joined #bitcoin-core-dev
12:51 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
12:53 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
13:08 -!- spynx [~spynxic@spynxic.powered.by.lunarbnc.net] has joined #bitcoin-core-dev
13:08 -!- spynxic [~spynxic@spynxic.powered.by.lunarbnc.net] has quit [Remote host closed the connection]