12025-01-23T00:10:25 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has joined #bitcoin-core-dev
22025-01-23T00:29:17 *** twistedline <twistedline!~bitcoin@185.193.125.44> has quit IRC ()
32025-01-23T00:34:26 *** twistedline <twistedline!~bitcoin@185.193.125.44> has joined #bitcoin-core-dev
42025-01-23T00:35:47 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has quit IRC (Ping timeout: 252 seconds)
52025-01-23T00:36:05 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has joined #bitcoin-core-dev
62025-01-23T00:40:21 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has quit IRC (Ping timeout: 248 seconds)
72025-01-23T01:04:07 *** josie <josie!~josibake@suhail.uberspace.de> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)
82025-01-23T01:04:21 *** josie <josie!~josibake@suhail.uberspace.de> has joined #bitcoin-core-dev
92025-01-23T01:04:46 <darosior> Can someone with permission restart this CI job? It's unrelated to the PR. https://github.com/bitcoin/bitcoin/actions/runs/12917231673/job/36023158007?pr=31713
102025-01-23T01:05:25 <achow101> darosior: done
112025-01-23T01:05:31 <darosior> Thanks!
122025-01-23T01:16:11 *** rszarka <rszarka!~szarka@2603:3003:4eac:100:4d73:f33a:d7c7:d7db> has joined #bitcoin-core-dev
132025-01-23T01:19:39 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:e4aa:a83c:6862:9b92> has quit IRC (Ping timeout: 276 seconds)
142025-01-23T01:43:37 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
152025-01-23T01:53:24 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has quit IRC (Quit: leaving)
162025-01-23T01:57:55 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has joined #bitcoin-core-dev
172025-01-23T02:14:05 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
182025-01-23T02:17:32 *** eval-exec <eval-exec!~Thunderbi@45.78.56.68.16clouds.com> has joined #bitcoin-core-dev
192025-01-23T02:18:48 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 276 seconds)
202025-01-23T02:31:45 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
212025-01-23T02:36:47 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 272 seconds)
222025-01-23T03:07:43 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
232025-01-23T03:36:32 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
242025-01-23T03:47:05 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has quit IRC (Ping timeout: 272 seconds)
252025-01-23T03:52:51 <bitcoin-git> [bitcoin] wgyt opened pull request #31718: Docs: fix typos in documentation files (master...typo) https://github.com/bitcoin/bitcoin/pull/31718
262025-01-23T03:58:33 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has joined #bitcoin-core-dev
272025-01-23T04:12:11 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 265 seconds)
282025-01-23T04:39:51 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
292025-01-23T04:50:47 <bitcoin-git> [gui-qml] johnny9 opened pull request #442: qml: Introduce the Desktop Wallet Activity Page (main...activity-page) https://github.com/bitcoin-core/gui-qml/pull/442
302025-01-23T05:02:06 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 252 seconds)
312025-01-23T05:02:09 *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
322025-01-23T05:06:28 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
332025-01-23T05:36:19 *** agentcas- <agentcas-!~agentcase@143-42-229-181.ip.linodeusercontent.com> has joined #bitcoin-core-dev
342025-01-23T05:36:26 *** eval-exec1 <eval-exec1!~Thunderbi@212.87.193.114> has joined #bitcoin-core-dev
352025-01-23T05:36:46 *** agentcasey <agentcasey!~agentcase@143-42-229-181.ip.linodeusercontent.com> has quit IRC (Ping timeout: 265 seconds)
362025-01-23T05:37:38 <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
372025-01-23T05:37:56 *** eval-exec1 <eval-exec1!~Thunderbi@212.87.193.114> has quit IRC (Remote host closed the connection)
382025-01-23T05:37:57 *** eval-exec <eval-exec!~Thunderbi@45.78.56.68.16clouds.com> has quit IRC (Ping timeout: 248 seconds)
392025-01-23T05:38:10 *** eval-exec <eval-exec!~Thunderbi@212.87.193.114> has joined #bitcoin-core-dev
402025-01-23T05:38:57 *** eval-exec <eval-exec!~Thunderbi@212.87.193.114> has quit IRC (Remote host closed the connection)
412025-01-23T05:39:12 *** eval-exec <eval-exec!~Thunderbi@45.78.56.68.16clouds.com> has joined #bitcoin-core-dev
422025-01-23T05:51:11 *** eval-exec1 <eval-exec1!~Thunderbi@212.87.193.114> has joined #bitcoin-core-dev
432025-01-23T05:52:20 *** eval-exec <eval-exec!~Thunderbi@45.78.56.68.16clouds.com> has quit IRC (Ping timeout: 264 seconds)
442025-01-23T05:52:20 *** eval-exec1 is now known as eval-exec
452025-01-23T05:53:08 *** eval-exec <eval-exec!~Thunderbi@212.87.193.114> has quit IRC (Remote host closed the connection)
462025-01-23T05:53:22 *** eval-exec <eval-exec!~Thunderbi@212.87.193.114> has joined #bitcoin-core-dev
472025-01-23T05:56:29 *** eval-exec <eval-exec!~Thunderbi@212.87.193.114> has quit IRC (Remote host closed the connection)
482025-01-23T05:58:19 *** eval-exec <eval-exec!~Thunderbi@144.34.183.180.16clouds.com> has joined #bitcoin-core-dev
492025-01-23T06:01:26 *** mcey_ <mcey_!~emcy@85.255.235.171> has quit IRC (Remote host closed the connection)
502025-01-23T06:01:49 *** mcey_ <mcey_!~emcy@85.255.235.171> has joined #bitcoin-core-dev
512025-01-23T06:13:30 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 252 seconds)
522025-01-23T06:37:21 *** emcy__ <emcy__!~emcy@85.255.235.171> has joined #bitcoin-core-dev
532025-01-23T06:40:45 *** mcey_ <mcey_!~emcy@85.255.235.171> has quit IRC (Ping timeout: 276 seconds)
542025-01-23T06:42:01 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has quit IRC (Ping timeout: 265 seconds)
552025-01-23T06:42:55 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
562025-01-23T06:57:07 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 244 seconds)
572025-01-23T06:58:17 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has joined #bitcoin-core-dev
582025-01-23T07:02:45 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has quit IRC (Ping timeout: 248 seconds)
592025-01-23T07:12:11 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
602025-01-23T07:34:58 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has joined #bitcoin-core-dev
612025-01-23T07:39:39 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has quit IRC (Ping timeout: 260 seconds)
622025-01-23T07:44:18 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 248 seconds)
632025-01-23T07:53:59 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has joined #bitcoin-core-dev
642025-01-23T07:57:52 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
652025-01-23T08:02:04 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 245 seconds)
662025-01-23T08:17:14 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
672025-01-23T08:23:39 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 252 seconds)
682025-01-23T08:39:53 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
692025-01-23T08:44:32 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 264 seconds)
702025-01-23T09:00:10 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
712025-01-23T09:05:31 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
722025-01-23T09:38:17 <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
732025-01-23T09:42:14 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 244 seconds)
742025-01-23T09:46:48 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5acf12bafeb1...449a25b9582e
752025-01-23T09:46:49 <bitcoin-git> bitcoin/master c31166a Hennadii Stepanov: cmake: Fail if `Libmultiprocess` is missing when `WITH_MULTIPROCESS=ON`
762025-01-23T09:46:49 <bitcoin-git> bitcoin/master 449a25b merge-script: Merge bitcoin/bitcoin#31709: cmake: Fail if `Libmultiprocess` is missing w...
772025-01-23T09:46:53 <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
782025-01-23T09:49:10 *** purpleKarrot <purpleKarrot!~purpleKar@2001:1620:5547:0:fafe:5eff:fe5b:42e9> has joined #bitcoin-core-dev
792025-01-23T09:52:41 *** Cory93 <Cory93!~Cory93@user/pasha> has quit IRC (Quit: Client closed)
802025-01-23T09:52:57 *** Cory93 <Cory93!~Cory93@user/pasha> has joined #bitcoin-core-dev
812025-01-23T10:10:04 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
822025-01-23T10:16:48 *** Nebraskka <Nebraskka!~Nebraskka@user/nebraskka> has joined #bitcoin-core-dev
832025-01-23T10:19:30 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev (Closing Window)
842025-01-23T10:36:01 <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
852025-01-23T10:46:17 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 252 seconds)
862025-01-23T10:47:28 <bitcoin-git> [bitcoin] maflcko closed pull request #31717: docs: fix README.md (master...docs-fix) https://github.com/bitcoin/bitcoin/pull/31717
872025-01-23T10:51:22 <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
882025-01-23T10:54:54 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/449a25b9582e...59876b3ad71c
892025-01-23T10:54:54 <bitcoin-git> bitcoin/master 733fa0b Antoine Poinsot: miner: never create a template which exploits the timewarp bug
902025-01-23T10:54:55 <bitcoin-git> bitcoin/master 59876b3 merge-script: Merge bitcoin/bitcoin#31376: Miner: never create a template which exploits...
912025-01-23T10:54:57 <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
922025-01-23T11:05:14 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
932025-01-23T11:08:39 *** purpleKarrot <purpleKarrot!~purpleKar@2001:1620:5547:0:fafe:5eff:fe5b:42e9> has quit IRC (Quit: Client closed)
942025-01-23T11:09:41 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 248 seconds)
952025-01-23T11:18:27 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/59876b3ad71c...94f0adcc31d2
962025-01-23T11:18:28 <bitcoin-git> bitcoin/master d38ade7 Hennadii Stepanov: qa: Use `sys.executable` when invoking other Python scripts
972025-01-23T11:18:28 <bitcoin-git> bitcoin/master 94f0adc merge-script: Merge bitcoin/bitcoin#31541: qa: Use `sys.executable` when invoking other ...
982025-01-23T11:18:30 <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
992025-01-23T11:22:52 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1002025-01-23T11:26:30 *** arferreira3 <arferreira3!~arferreir@syn-075-112-159-147.biz.spectrum.com> has quit IRC (Remote host closed the connection)
1012025-01-23T11:40:27 *** Guest45 <Guest45!~Guest45@105.172.82.238> has joined #bitcoin-core-dev
1022025-01-23T11:41:12 *** eval-exec <eval-exec!~Thunderbi@144.34.183.180.16clouds.com> has quit IRC (Ping timeout: 265 seconds)
1032025-01-23T11:43:09 *** Guest45 <Guest45!~Guest45@105.172.82.238> has quit IRC (Client Quit)
1042025-01-23T11:43:38 *** Guest45 <Guest45!~Guest45@105.172.82.238> has joined #bitcoin-core-dev
1052025-01-23T11:44:11 *** Guest45 <Guest45!~Guest45@105.172.82.238> has quit IRC (Client Quit)
1062025-01-23T11:52:02 <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
1072025-01-23T11:54:22 <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
1082025-01-23T12:21:23 *** jespada <jespada!~jespada@2800:a4:2317:8200:52e:e131:1453:b068> has joined #bitcoin-core-dev
1092025-01-23T12:26:01 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 252 seconds)
1102025-01-23T12:43:02 <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/94f0adcc31d2...2317e6cf2da8
1112025-01-23T12:43:03 <bitcoin-git> bitcoin/master fa9593e MarcoFalke: test: Use high-level python types
1122025-01-23T12:43:03 <bitcoin-git> bitcoin/master fa9aced MarcoFalke: test: Check that reindex with prune wipes blk files
1132025-01-23T12:43:03 <bitcoin-git> bitcoin/master 2317e6c merge-script: Merge bitcoin/bitcoin#31696: test: Check that reindex with prune wipes blk...
1142025-01-23T12:43:05 <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
1152025-01-23T12:50:45 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2317e6cf2da8...188b02116d84
1162025-01-23T12:50:46 <bitcoin-git> bitcoin/master 4da7bfd brunoerg: test: add coverage for unknown address type for `createwalletdescriptor`
1172025-01-23T12:50:46 <bitcoin-git> bitcoin/master 188b021 merge-script: Merge bitcoin/bitcoin#31635: test: add coverage for unknown address type f...
1182025-01-23T12:50:48 <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
1192025-01-23T12:53:09 *** eval-exec <eval-exec!~Thunderbi@45.78.56.68.16clouds.com> has joined #bitcoin-core-dev
1202025-01-23T13:15:13 *** Earnestly <Earnestly!~earnest@user/earnestly> has quit IRC (Read error: Connection reset by peer)
1212025-01-23T13:18:10 <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
1222025-01-23T13:21:48 *** Earnestly <Earnestly!~earnest@user/earnestly> has joined #bitcoin-core-dev
1232025-01-23T13:22:41 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1242025-01-23T13:32:46 *** c2 <c2!~c@user/uyea> has quit IRC (Ping timeout: 252 seconds)
1252025-01-23T13:32:46 *** jrayhawk <jrayhawk!~jrayhawk@user/jrayhawk> has quit IRC (Ping timeout: 252 seconds)
1262025-01-23T13:34:30 *** jrayhawk <jrayhawk!~jrayhawk@user/jrayhawk> has joined #bitcoin-core-dev
1272025-01-23T13:38:08 *** eval-exec1 <eval-exec1!~Thunderbi@93.179.103.163.16clouds.com> has joined #bitcoin-core-dev
1282025-01-23T13:39:42 *** eval-exec <eval-exec!~Thunderbi@45.78.56.68.16clouds.com> has quit IRC (Ping timeout: 246 seconds)
1292025-01-23T13:39:43 *** eval-exec1 is now known as eval-exec
1302025-01-23T13:43:36 *** c <c!~c@172.245.81.218> has joined #bitcoin-core-dev
1312025-01-23T13:43:37 *** S3RK <S3RK!~S3RK@user/s3rk> has joined #bitcoin-core-dev
1322025-01-23T13:46:49 *** S3RK_ <S3RK_!~S3RK@user/s3rk> has quit IRC (Ping timeout: 252 seconds)
1332025-01-23T13:58:51 *** Emc99 <Emc99!~Emc99@212.129.76.254> has joined #bitcoin-core-dev
1342025-01-23T14:00:29 <Sjors[m]> Meeting?
1352025-01-23T14:01:49 *** Emc99 <Emc99!~Emc99@212.129.76.254> has quit IRC (Client Quit)
1362025-01-23T14:01:53 <fanquake> Weekly Meeting Thursday @ 16:00 UTC
1372025-01-23T14:02:03 *** virtu <virtu!~virtu@user/virtu> has joined #bitcoin-core-dev
1382025-01-23T14:02:06 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 252 seconds)
1392025-01-23T14:02:17 <Sjors[m]> Ah we bumped the time?
1402025-01-23T14:02:31 <Sjors[m]> Alright, will be back in 2 hours.
1412025-01-23T14:02:37 <fanquake> Yes. It changed at the last meeting.
1422025-01-23T14:08:39 <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
1432025-01-23T14:25:35 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/188b02116d84...9914e7372976
1442025-01-23T14:25:36 <bitcoin-git> bitcoin/master 5c3e4d8 Antoine Poinsot: doc: add a section about using MSan
1452025-01-23T14:25:36 <bitcoin-git> bitcoin/master 9914e73 merge-script: Merge bitcoin/bitcoin#31704: doc: add a section in the fuzzing documentati...
1462025-01-23T14:25:38 <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
1472025-01-23T14:29:29 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1482025-01-23T14:30:37 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has joined #bitcoin-core-dev
1492025-01-23T14:32:09 *** catnip <catnip!~catnip@host-92-13-94-227.as13285.net> has joined #bitcoin-core-dev
1502025-01-23T15:00:47 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has quit IRC (*.net *.split)
1512025-01-23T15:00:47 *** S3RK <S3RK!~S3RK@user/s3rk> has quit IRC (*.net *.split)
1522025-01-23T15:00:48 *** TheRec_ <TheRec_!~toto@84-75-225-47.dclient.hispeed.ch> has quit IRC (*.net *.split)
1532025-01-23T15:00:48 *** jamesob1566 <jamesob1566!~jamesob@pool-108-44-213-219.clppva.fios.verizon.net> has quit IRC (*.net *.split)
1542025-01-23T15:00:49 *** maflcko <maflcko!~none@107.172.8.183> has quit IRC (*.net *.split)
1552025-01-23T15:00:49 *** instagibbs <instagibbs!~instagibb@pool-100-15-116-202.washdc.fios.verizon.net> has quit IRC (*.net *.split)
1562025-01-23T15:00:50 *** adiabat_ <adiabat_!~adiabat@63.209.32.102> has quit IRC (*.net *.split)
1572025-01-23T15:00:50 *** theStack <theStack!~theStack@95.179.145.232> has quit IRC (*.net *.split)
1582025-01-23T15:05:45 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has joined #bitcoin-core-dev
1592025-01-23T15:05:45 *** S3RK <S3RK!~S3RK@user/s3rk> has joined #bitcoin-core-dev
1602025-01-23T15:05:45 *** TheRec_ <TheRec_!~toto@84-75-225-47.dclient.hispeed.ch> has joined #bitcoin-core-dev
1612025-01-23T15:05:45 *** jamesob1566 <jamesob1566!~jamesob@pool-108-44-213-219.clppva.fios.verizon.net> has joined #bitcoin-core-dev
1622025-01-23T15:05:45 *** maflcko <maflcko!~none@107.172.8.183> has joined #bitcoin-core-dev
1632025-01-23T15:05:45 *** instagibbs <instagibbs!~instagibb@pool-100-15-116-202.washdc.fios.verizon.net> has joined #bitcoin-core-dev
1642025-01-23T15:05:45 *** adiabat_ <adiabat_!~adiabat@63.209.32.102> has joined #bitcoin-core-dev
1652025-01-23T15:05:45 *** theStack <theStack!~theStack@95.179.145.232> has joined #bitcoin-core-dev
1662025-01-23T15:07:39 <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
1672025-01-23T15:19:52 <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
1682025-01-23T15:24:34 *** eval-exec <eval-exec!~Thunderbi@93.179.103.163.16clouds.com> has quit IRC (Ping timeout: 245 seconds)
1692025-01-23T15:37:02 <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
1702025-01-23T15:40:54 *** dzxzg <dzxzg!~dzxzg@user/dzxzg> has joined #bitcoin-core-dev
1712025-01-23T15:41:40 *** catnip <catnip!~catnip@host-92-13-94-227.as13285.net> has quit IRC (Ping timeout: 240 seconds)
1722025-01-23T15:44:51 *** mcey_ <mcey_!~emcy@148.252.128.80> has joined #bitcoin-core-dev
1732025-01-23T15:45:16 <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
1742025-01-23T15:47:08 *** preimage <preimage!~halosghos@user/halosghost> has joined #bitcoin-core-dev
1752025-01-23T15:48:27 *** emcy__ <emcy__!~emcy@85.255.235.171> has quit IRC (Ping timeout: 272 seconds)
1762025-01-23T15:59:03 *** core-meetbot <core-meetbot!~limnoria@user/core-meetbot> has quit IRC (Remote host closed the connection)
1772025-01-23T15:59:18 *** core-meetbot <core-meetbot!~limnoria@user/core-meetbot> has joined #bitcoin-core-dev
1782025-01-23T16:00:10 <achow101> #startmeeting
1792025-01-23T16:00:11 <core-meetbot> achow101: Meeting started at 2025-01-23T16:00+0000
1802025-01-23T16:00:11 <core-meetbot> achow101: Current chairs: achow101
1812025-01-23T16:00:12 <core-meetbot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
1822025-01-23T16:00:13 <core-meetbot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
1832025-01-23T16:00:15 <core-meetbot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
1842025-01-23T16:00:20 <Murch[m]> Hi
1852025-01-23T16:00:23 <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
1862025-01-23T16:00:23 <core-meetbot> achow101: Unknown command: #bitcoin
1872025-01-23T16:00:23 <hodlinator> hi
1882025-01-23T16:00:26 <Murch[m]> #here
1892025-01-23T16:00:29 <cfields> hi
1902025-01-23T16:00:30 <sipa> hi
1912025-01-23T16:00:32 <sr_gi[m]> #here
1922025-01-23T16:00:32 <lightlike> hi
1932025-01-23T16:00:33 <darosior> hi
1942025-01-23T16:00:33 <glozow> hi
1952025-01-23T16:00:38 <achow101> i've gotta change that bot command behavior..
1962025-01-23T16:00:39 <kevkevin> hi
1972025-01-23T16:00:41 <Sjors[m]> hi
1982025-01-23T16:00:43 <darosior> What's with the #here?
1992025-01-23T16:00:43 <abubakarsadiq> hi
2002025-01-23T16:00:43 <dzxzg> hi
2012025-01-23T16:00:54 <pinheadmz> yo
2022025-01-23T16:00:56 <Murch[m]> "achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'"
2032025-01-23T16:01:03 <achow101> It actually doesn't matter
2042025-01-23T16:01:14 <sr_gi[m]> hi then :P
2052025-01-23T16:01:16 <achow101> saying anything works just as well
2062025-01-23T16:01:17 <sipa> #here FirstLast
2072025-01-23T16:01:20 <stickies-v> hi
2082025-01-23T16:01:23 <Murch[m]> lol
2092025-01-23T16:01:27 <achow101> sipa: but that confuses the bot
2102025-01-23T16:01:31 <furszy> hi
2112025-01-23T16:01:42 <tdb3> hi
2122025-01-23T16:01:43 <achow101> anyways. there's one preproposed meeting topic this week, any last minute ones to add
2132025-01-23T16:01:44 <sr_gi[m]> #hi FirstLast mybe?
2142025-01-23T16:01:44 <core-meetbot> sr_gi[m]: Unknown command: #hi
2152025-01-23T16:01:51 <marcofleon> hi
2162025-01-23T16:02:39 <achow101> #topic Erlay WG Update (sr_gi, gleb, marcofleon)
2172025-01-23T16:03:39 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 272 seconds)
2182025-01-23T16:04:03 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
2192025-01-23T16:04:09 <sipa> sr_gi[m], gleb?
2202025-01-23T16:04:21 <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
2212025-01-23T16:04:25 <jonatack> hi (slow internet here atm, sorry)
2222025-01-23T16:04:41 <sr_gi[m]> There first two tabs should the data volume per transaction in different configurations
2232025-01-23T16:05:04 <maxedw> hi
2242025-01-23T16:05:22 *** purpleKarrot <purpleKarrot!~purpleKar@2001:1620:5547:0:fafe:5eff:fe5b:42e9> has joined #bitcoin-core-dev
2252025-01-23T16:05:40 <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
2262025-01-23T16:05:42 <kanzure> hi
2272025-01-23T16:06:01 <sr_gi[m]> So I'll check on some of those next.
2282025-01-23T16:06:58 <sr_gi[m]> I think Gleb also had a plan on his end but not sure if he's around
2292025-01-23T16:08:02 <sr_gi[m]> He'll share next time. That's all on my end
2302025-01-23T16:08:50 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
2312025-01-23T16:08:52 *** brunoerg_ <brunoerg_!~brunoerg@2804:14d:5285:84b2::1000> has quit IRC ()
2322025-01-23T16:09:01 *** brunoerg <brunoerg!~brunoerg@2804:14d:5285:84b2::1000> has joined #bitcoin-core-dev
2332025-01-23T16:09:24 <brunoerg> hi
2342025-01-23T16:10:06 <sipa> sdaftuar is continuing his rebase of #28676 on top of my txgraph code (up to and including #31553)
2352025-01-23T16:10:09 <gribble> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
2362025-01-23T16:10:11 <gribble> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
2372025-01-23T16:10:12 <sipa> i hear there is progress
2382025-01-23T16:10:59 <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
2392025-01-23T16:11:01 <gribble> https://github.com/bitcoin/bitcoin/issues/31363 | cluster mempool: introduce TxGraph by sipa · Pull Request #31363 · bitcoin/bitcoin · GitHub
2402025-01-23T16:11:13 <sipa> that's it from me
2412025-01-23T16:11:15 <glozow> There will be a review club meeting on #31363 on February 5
2422025-01-23T16:11:15 <gribble> https://github.com/bitcoin/bitcoin/issues/31363 | cluster mempool: introduce TxGraph by sipa · Pull Request #31363 · bitcoin/bitcoin · GitHub
2432025-01-23T16:11:20 <sipa> oooh!
2442025-01-23T16:11:55 <glozow> Can't guarantee more eyes, but can promise I will write some notes before then
2452025-01-23T16:13:13 <achow101> #topic MuSig2 WG Update (achow101)
2462025-01-23T16:13:23 <achow101> #31242 was merged. Spent a bunch of time working on #31622 and fixing the issues there. It should not be ready for review.
2472025-01-23T16:13:24 <core-meetbot> achow101: Unknown command: #31242
2482025-01-23T16:13:26 <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
2492025-01-23T16:13:30 <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
2502025-01-23T16:13:31 <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
2512025-01-23T16:13:33 <achow101> s/not/now
2522025-01-23T16:14:33 <achow101> I'll also be working on fixed test vectors for #31247 and to add to the bip
2532025-01-23T16:14:35 <gribble> https://github.com/bitcoin/bitcoin/issues/31247 | psbt: MuSig2 Fields by achow101 · Pull Request #31247 · bitcoin/bitcoin · GitHub
2542025-01-23T16:14:45 <achow101> so that's been marked as a draft for now
2552025-01-23T16:15:06 <achow101> the prs to review are #31243 and #31622
2562025-01-23T16:15:08 <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
2572025-01-23T16:15:09 <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
2582025-01-23T16:15:25 <achow101> #topic Legacy Wallet Removal WG Update (achow101)
2592025-01-23T16:15:52 <achow101> #31495 has been getting some review and is still the pr to review
2602025-01-23T16:15:53 <core-meetbot> achow101: Unknown command: #31495
2612025-01-23T16:15:55 <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
2622025-01-23T16:15:55 <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
2632025-01-23T16:16:08 <darosior> bad bot
2642025-01-23T16:16:17 <achow101> and #31241 is probably rfm.
2652025-01-23T16:16:19 <gribble> https://github.com/bitcoin/bitcoin/issues/31241 | wallet: remove BDB dependency from wallet migration benchmark by furszy · Pull Request #31241 · bitcoin/bitcoin · GitHub
2662025-01-23T16:16:37 <achow101> which I'll take another look at today
2672025-01-23T16:16:55 <achow101> #topic orphan resolution WG Update (glozow)
2682025-01-23T16:17:03 <glozow> The current PR to review is #31666, the followup from #31397.
2692025-01-23T16:17:05 <gribble> https://github.com/bitcoin/bitcoin/issues/31666 | multi-peer orphan resolution followups by glozow · Pull Request #31666 · bitcoin/bitcoin · GitHub
2702025-01-23T16:17:09 <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
2712025-01-23T16:17:11 <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
2722025-01-23T16:17:23 <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 ð¤).
2732025-01-23T16:18:31 <glozow> TLDR, it will make TxOrphanage no longer global; we'll have limits per-peer
2742025-01-23T16:19:01 <sipa> well, the TxOrphanage instance itself remains global, it's just the accounting that happens per peer?
2752025-01-23T16:19:09 *** jespada <jespada!~jespada@2800:a4:2317:8200:52e:e131:1453:b068> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzzâ¦)
2762025-01-23T16:19:13 <sipa> or do you think actually making the orphanage per-peer is simpler?
2772025-01-23T16:19:24 <glozow> sipa: yes, still a global `TxOrphanage` object
2782025-01-23T16:19:29 <sipa> alright
2792025-01-23T16:20:18 <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.
2802025-01-23T16:20:43 <glozow> vasild sent me some interesting logs a few weeks ago (thank you)
2812025-01-23T16:20:55 <instagibbs> you mean in general on master or whic hpr
2822025-01-23T16:20:55 <sipa> glozow: happy to run some, what PR/options?
2832025-01-23T16:21:06 <glozow> on top of #31666 would be best
2842025-01-23T16:21:07 <gribble> https://github.com/bitcoin/bitcoin/issues/31666 | multi-peer orphan resolution followups by glozow · Pull Request #31666 · bitcoin/bitcoin · GitHub
2852025-01-23T16:21:30 <glozow> sorry not "debug-only" haha. I mean in debug mode. Brain a bit fuzzy right now.
2862025-01-23T16:21:38 <achow101> glozow: I can setup one of my nodes to do that
2872025-01-23T16:22:02 <instagibbs> removes all logic but Assumes()
2882025-01-23T16:22:26 <darosior> I can run a mainnet node on this PR too
2892025-01-23T16:23:01 <glozow> Thank you very much!
2902025-01-23T16:23:37 <achow101> #topic Stratum v2 WG Update (sjors)
2912025-01-23T16:23:37 <glozow> That's all from me
2922025-01-23T16:23:41 <Sjors[m]> Suggested by darosior, he'll elaborate shortly. From my end, I think there's three questions that are good to discuss:
2932025-01-23T16:23:46 <Sjors[m]> 1. Are people still on board with including libmultiprocess in the release build at some point?
2942025-01-23T16:23:51 <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?
2952025-01-23T16:23:52 <achow101> Sjors[m]: oops wrong topic
2962025-01-23T16:23:58 <Sjors[m]> 3. Are the specific things still missing?
2972025-01-23T16:24:12 <achow101> #topic Adding multiprocess binaries to release build (#30975) (sjors)
2982025-01-23T16:24:13 <Sjors[m]> Well that's fine, it's about #30975
2992025-01-23T16:24:14 <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
3002025-01-23T16:24:15 <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
3012025-01-23T16:24:21 <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.
3022025-01-23T16:24:36 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
3032025-01-23T16:24:49 <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
3042025-01-23T16:24:49 <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.
3052025-01-23T16:24:50 <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
3062025-01-23T16:25:05 <achow101> I think we should do multiprocess releases eventually
3072025-01-23T16:25:06 <fanquake> Why are you still maintaining the "shove it into core" approach, when it's clear we are never going to do that?
3082025-01-23T16:25:29 <fanquake> I left my more general thoughts about multiprocess being added to the build here: https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2610191420
3092025-01-23T16:25:39 <sipa> fanquake: thanks for commenting there
3102025-01-23T16:25:47 <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
3112025-01-23T16:25:56 <ryanofsky> (my response is below that, please take a look at that too)
3122025-01-23T16:26:13 <fanquake> Could you also elaborate on who is running it right now. i.e how many users?
3132025-01-23T16:26:15 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
3142025-01-23T16:26:28 <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.
3152025-01-23T16:26:50 <Sjors[m]> fanquake: the SRI team runs the IPC version, they have a handful of testers using a custom signet.
3162025-01-23T16:27:04 <Sjors[m]> And afaik the new Demand pool runs the regular version.
3172025-01-23T16:27:22 <Sjors[m]> I have no idea how many, if any, people use Demand pool, they're still starting up as a business.
3182025-01-23T16:27:36 <fanquake> So a single pool using the old version (experimentally I assume)
3192025-01-23T16:28:12 <Sjors[m]> fanquake: yes, it's partially a chicken-egg problem - without Bitcoin Core support Stratum v2 is dead on arrival
3202025-01-23T16:28:17 <ryanofsky> One idea is more people would use this if it were it were easier to use?
3212025-01-23T16:28:29 <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
3222025-01-23T16:28:39 <Sjors[m]> And even experimenta support is a pain now.
3232025-01-23T16:28:55 <Sjors[m]> Because people have to install Bitcoin Core binaries from some random guy (me).
3242025-01-23T16:29:35 <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
3252025-01-23T16:29:35 <achow101> I think the question is really whether multiprocess is ready enough for people to try to use it in production?
3262025-01-23T16:30:08 <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
3272025-01-23T16:30:25 <sipa> to me, the answer to (1) is yes, but it is obviously contingent on it getting sufficient review
3282025-01-23T16:30:26 <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.
3292025-01-23T16:30:43 <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.
3302025-01-23T16:31:18 <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
3312025-01-23T16:31:20 <fanquake> sipa: unfortunately during the life of libmultiprocess, getting sufficient reivew from anyone other
3322025-01-23T16:31:21 <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.
3332025-01-23T16:31:27 <darosior> I agree with sipa for (1). And as far as i'm aware we aren't there yet, unfortunately.
3342025-01-23T16:31:30 <fanquake> than Russ, has seemed to be very difficult
3352025-01-23T16:31:51 <fanquake> Sjors: bugs might be fine for the pools, but no so much for our CI
3362025-01-23T16:32:01 <ryanofsky> What is (1)? I'm having problems following this discussion...
3372025-01-23T16:32:04 <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.
3382025-01-23T16:32:21 <fanquake> and that is the current state of affairs, given there are multiple unsolved intermittent issues related to libmultiprocess
3392025-01-23T16:32:35 <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?
3402025-01-23T16:32:53 <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?
3412025-01-23T16:32:57 <Sjors[m]> fanquake: fixing intermittend CI failures is always a good reason to wait with merging
3422025-01-23T16:33:28 <fanquake> If Russ dissapears (hopefuly not) tomorrow, are you planning on taking over maintainership libmultiprocess?
3432025-01-23T16:33:43 <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.
3442025-01-23T16:34:01 <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"
3452025-01-23T16:34:11 <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".
3462025-01-23T16:34:23 <stickies-v> +1 darosior
3472025-01-23T16:34:31 <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.
3482025-01-23T16:34:53 <glozow> achow101: (sorry late but can we add topic v29.0 milestone today?)
3492025-01-23T16:34:55 <Sjors[m]> So that relates to my question (1)
3502025-01-23T16:35:16 <Sjors[m]> Whether we want multiprocess at all
3512025-01-23T16:35:24 <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
3522025-01-23T16:35:43 <fanquake> Apparently the answer has been "yes", but "not quite enough" for almost 10 years
3532025-01-23T16:35:45 <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"
3542025-01-23T16:36:08 *** jackielove4u3 <jackielove4u3!~jackielov@user/jackielove4u> has joined #bitcoin-core-dev
3552025-01-23T16:36:11 <darosior> achow101: sure but there is a difference between no warranty and breaking our standards.
3562025-01-23T16:36:29 <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
3572025-01-23T16:36:32 <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
3582025-01-23T16:36:51 <fanquake> that alone seems like a weird place to be, to be merging this stuff
3592025-01-23T16:36:59 <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
3602025-01-23T16:37:08 <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
3612025-01-23T16:37:34 <sipa> so actually seeing it "going somewhere" may very realistically change how reviewers deal with it
3622025-01-23T16:37:58 <Sjors[m]> ryanofsky: I opened the topic with 3 questions, so that's what (1), (2) , (3) refer to.
3632025-01-23T16:38:08 <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
3642025-01-23T16:38:22 <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
3652025-01-23T16:38:25 <ryanofsky> Can we do something like install it in bin/experimental/? bin/unstable/?
3662025-01-23T16:38:27 *** jackielove4u <jackielove4u!~jackielov@user/jackielove4u> has quit IRC (Ping timeout: 265 seconds)
3672025-01-23T16:38:27 *** jackielove4u3 is now known as jackielove4u
3682025-01-23T16:38:34 <fanquake> achow101: I don't see how that could be true if you look at the PRs in the multiprocess repo
3692025-01-23T16:38:47 <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!).
3702025-01-23T16:38:49 <achow101> unless the question is that this pr in particular doesn't meet review standards?
3712025-01-23T16:39:45 <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.
3722025-01-23T16:39:46 <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.
3732025-01-23T16:39:53 <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.
3742025-01-23T16:40:00 <Sjors[m]> * it might
3752025-01-23T16:40:09 <Sjors[m]> (annoying, but not end of the world)
3762025-01-23T16:40:12 <sipa> fanquake: i agree with that, i'd rather have this discussion (in addition to here) also at coredev
3772025-01-23T16:40:31 <ryanofsky> I think we can also hash this out in the actual PR. (i also do not favor IRC)
3782025-01-23T16:40:38 <glozow> should we explore shifting v29.0 dates?
3792025-01-23T16:40:43 <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
3802025-01-23T16:40:43 <cfields> release cycle, have all devs dogfood it for 6 months, then discuss shipping it once we're all on the same page.
3812025-01-23T16:40:49 <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.
3822025-01-23T16:41:01 <achow101> Sjors[m]: what's half a year to waiting 6 years already (or however long it's been, feels like forever)
3832025-01-23T16:41:02 <fanquake> sjors: i dissagree that we should do it, as long as there are no (known) bugs, there are other process/project issues here
3842025-01-23T16:41:24 <darosior> achow101: for multiprocess since 2017 :/
3852025-01-23T16:41:26 <fanquake> (there are still known bugs in either case)
3862025-01-23T16:41:51 <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.
3872025-01-23T16:42:33 <Sjors[m]> I do not posess ryanofsky level patience :-)
3882025-01-23T16:42:36 <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
3892025-01-23T16:43:25 <fanquake> How we ship multiprocess is another thing that is still undecided
3902025-01-23T16:43:56 <fanquake> #31375
3912025-01-23T16:43:56 <core-meetbot> fanquake: Unknown command: #31375
3922025-01-23T16:43:57 <ryanofsky> fanquake undecided as in not merged yet? i think we have a clear path
3932025-01-23T16:43:59 <gribble> https://github.com/bitcoin/bitcoin/issues/31375 | multiprocess: Add bitcoin wrapper executable by ryanofsky · Pull Request #31375 · bitcoin/bitcoin · GitHub
3942025-01-23T16:43:59 <gribble> https://github.com/bitcoin/bitcoin/issues/31375 | multiprocess: Add bitcoin wrapper executable by ryanofsky · Pull Request #31375 · bitcoin/bitcoin · GitHub
3952025-01-23T16:44:05 <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.
3962025-01-23T16:44:14 <sipa> cfields: agreed
3972025-01-23T16:44:28 <achow101> doesn't the dev-mode preset turn it on?
3982025-01-23T16:44:39 <sipa> i haven't even gotten it to work the last time i tried
3992025-01-23T16:44:43 <ryanofsky> the PR does not turn multiprocess on by default for developers
4002025-01-23T16:44:47 <fanquake> That only works with depends though, whcih isn't part of the dev mode
4012025-01-23T16:44:54 <sipa> i think we should have it on in dev builds by default before considering adding to releases
4022025-01-23T16:44:57 <ryanofsky> that would be a nice step to take at some point the future
4032025-01-23T16:45:00 <cfields> ryanofsky: right, that's my point. Imo that ordering is backwards.
4042025-01-23T16:45:06 <darosior> Yeah you need a patch to build it because of an issue with libatomic
4052025-01-23T16:45:10 * 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
4062025-01-23T16:45:13 <achow101> oh i installed libmultiprocess to my system, so dev-mode always builds with it. I don't necessarily test with it though
4072025-01-23T16:45:15 <darosior> sipa: +1
4082025-01-23T16:45:31 <sipa> fanquake: ah thanks
4092025-01-23T16:46:06 <fanquake> which is why I'm more in favour of vendoring, as it removes a whole class of issues
4102025-01-23T16:46:07 <ryanofsky> i see, so no feature can be in a release if it is not enabled by default in developer builds
4112025-01-23T16:46:36 <cfields> +1 for vendoring.
4122025-01-23T16:46:39 <sipa> ryanofsky: i think it's a reasonable bar, because we want to dogfood it actually working before shipping something, even if experimental?
4132025-01-23T16:46:44 <fanquake> ryanofsky: I think it's somewhat weird for us to be shipping things that developers are not actively building / using testing etc
4142025-01-23T16:46:52 <ryanofsky> yes, understood
4152025-01-23T16:47:00 <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.
4162025-01-23T16:47:10 <cfields> and it makes sense to me in this case as well.
4172025-01-23T16:47:16 <darosior> +1
4182025-01-23T16:47:31 <ryanofsky> these are just new requests and I'm trying to boil them down
4192025-01-23T16:47:59 <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.
4202025-01-23T16:48:22 <darosior> So is there any other thing we could do that would make your life easier Sjors[m]?
4212025-01-23T16:48:34 <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)
4222025-01-23T16:49:34 <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.
4232025-01-23T16:49:39 <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.
4242025-01-23T16:50:02 <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
4252025-01-23T16:50:11 <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.
4262025-01-23T16:50:14 <hebasto> agree with vendoring libmultiprocess
4272025-01-23T16:50:28 <cfields> ryanofsky: Imo vendoring makes sense as a next step.
4282025-01-23T16:50:55 <sipa> agree
4292025-01-23T16:50:56 <cfields> to at least get everyone on the same page
4302025-01-23T16:50:57 <fanquake> Sjors: how what a separate from the main release build work? We aren't going to release/provide bin with unmerged/reviewed code
4312025-01-23T16:51:17 <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
4322025-01-23T16:51:31 <ryanofsky> but understand if it's a minority opinion
4332025-01-23T16:52:03 <Sjors[m]> fanquake: if we vendor it, then we could guix build a bitcoin-node binary and ship that seperately?
4342025-01-23T16:52:05 <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
4352025-01-23T16:53:10 <Sjors[m]> fanquake: that's already better than the status quo
4362025-01-23T16:53:12 <fanquake> Sjors: maybe, where do you want to distribute that from? A different download page on the website? github? etc
4372025-01-23T16:53:48 <Sjors[m]> Whatever is easier, the SRI documentation can point to it.
4382025-01-23T16:53:49 <achow101> it could just be in bitcoincore.org/bin and not actually on the downloads page
4392025-01-23T16:53:54 <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.
4402025-01-23T16:54:08 <Sjors[m]> It would basically say "Please install Bitcoin Core from X instead of the normal place", then install the sidecar app.
4412025-01-23T16:54:22 <fanquake> RIght, so why can't SRI build and distribute this themselves?
4422025-01-23T16:54:36 <fanquake> Does this only work if it exists on bitcoincore.org
4432025-01-23T16:55:08 <fanquake> Surely bundling it with the sidecar would be even easier
4442025-01-23T16:55:10 <Sjors[m]> SRI is a Rust project, they're not going to release Bitcoin Core binaries I think.
4452025-01-23T16:55:43 <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
4462025-01-23T16:55:52 <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.
4472025-01-23T16:56:16 <fanquake> Sjors: I mean a tarball can have both the custom core bin, and the sidecar
4482025-01-23T16:56:35 <fanquake> which also removes this distribution problem, given they are downloading the sidecar in any case
4492025-01-23T16:56:35 <sipa> fanquake: i don't know if that's all that much of a reasonable distinction
4502025-01-23T16:56:44 <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".
4512025-01-23T16:56:45 <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.
4522025-01-23T16:56:50 <sipa> if we're working on it, it must mean that we want people to use it, whether we distribute it or others
4532025-01-23T16:56:53 <achow101> there's still one more topic for today's meeting
4542025-01-23T16:56:55 <cfields> maybe I'm underestimating how many devs are playing with it on a daily basis?
4552025-01-23T16:56:58 <fanquake> sipa: right, but it seems just as easy as making as host some special binaries for them
4562025-01-23T16:57:06 <sipa> fanquake: fair
4572025-01-23T16:57:18 <sipa> but neither should be the end goal
4582025-01-23T16:57:35 <sipa> as a temporary situation, i don't care much
4592025-01-23T16:57:43 <glozow> I think we should move on if there are other topics, e.g. wg updates
4602025-01-23T16:57:51 <sipa> agree
4612025-01-23T16:57:52 <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.
4622025-01-23T16:58:00 <achow101> feel free to hash this out after the meeting
4632025-01-23T16:58:03 <achow101> #topic 29.0 milestone (glozow)
4642025-01-23T16:58:10 <darosior> sipa: seems like getting people to rely on temporary binaries we release may well be pretty permanent.
4652025-01-23T16:58:17 <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
4662025-01-23T16:58:23 <glozow> As per #31029. We have feature freeze scheduled for Feb 20
4672025-01-23T16:58:24 <gribble> https://github.com/bitcoin/bitcoin/issues/31029 | Release Schedule for 29.0 · Issue #31029 · bitcoin/bitcoin · GitHub
4682025-01-23T16:58:36 <glozow> That's 4 weeks away
4692025-01-23T16:58:37 <ryanofsky> s/importance/criticality/
4702025-01-23T16:59:00 <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
4712025-01-23T16:59:15 <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"
4722025-01-23T16:59:35 <glozow> But also, given earlier comments in this meeting, do people feel very strongly about changing the date?
4732025-01-23T17:00:13 <achow101> could we delay feature freeze to after coredev?
4742025-01-23T17:00:15 <darosior> glozow: i don't think changing the date would help with the previous topic discussed.
4752025-01-23T17:00:28 <darosior> achow101: why?
4762025-01-23T17:00:35 <sipa> i'd prefer not changing the date
4772025-01-23T17:00:50 *** Emc99 <Emc99!~Emc99@212.129.76.254> has joined #bitcoin-core-dev
4782025-01-23T17:00:59 <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
4792025-01-23T17:00:59 <fanquake> achow101: do you have particular PRs in mind that would benefit from delaying
4802025-01-23T17:01:11 <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"
4812025-01-23T17:01:24 <achow101> darosior: i think there are things currently milestoned for 29.0 that could make it in during/after coredev
4822025-01-23T17:01:55 <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.
4832025-01-23T17:01:56 <glozow> sipa: yeah I agree with not doing last minute things at coredev
4842025-01-23T17:02:18 *** jespada <jespada!~jespada@2800:a4:2317:8200:52e:e131:1453:b068> has joined #bitcoin-core-dev
4852025-01-23T17:02:29 <jonatack> PRs labeled as v29 milestone: https://github.com/bitcoin/bitcoin/milestone/69
4862025-01-23T17:02:51 <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.
4872025-01-23T17:03:34 <glozow> Ok then we'll keep the date as is, and the coredev conversation can be about having it in v30
4882025-01-23T17:03:39 <jonatack> #proposedmeetingtopic release management rotation
4892025-01-23T17:03:39 <core-meetbot> jonatack: Unknown command: #proposedmeetingtopic
4902025-01-23T17:03:49 <achow101> fanquake: I think the legacy wallet removal stuff would benefit, but I don't feel that strongly
4912025-01-23T17:04:04 <achow101> anyways, we're out of time
4922025-01-23T17:04:08 <achow101> jonatack: we can do that next week
4932025-01-23T17:04:13 <glozow> jonatack: what do you mean by that?
4942025-01-23T17:04:32 <achow101> #endmeeting
4952025-01-23T17:04:32 <core-meetbot> achow101: Meeting ended at 2025-01-23T17:04+0000
4962025-01-23T17:04:33 <core-meetbot> achow101: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-01-23_16_00.log.json
4972025-01-23T17:04:34 <core-meetbot> achow101: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-01-23_16_00.log.html
4982025-01-23T17:04:35 <core-meetbot> achow101: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-01-23_16_00.html
4992025-01-23T17:05:09 <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
5002025-01-23T17:05:25 <jonatack> when the laanwj -> when the lead maintainer
5012025-01-23T17:05:29 <fanquake> it is currently being rotated
5022025-01-23T17:05:32 <fanquake> i did 27
5032025-01-23T17:05:34 <fanquake> achow did 28
5042025-01-23T17:05:35 <achow101> we're rotating, mostly
5052025-01-23T17:05:40 <fanquake> gloria will do 29
5062025-01-23T17:06:09 <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
5072025-01-23T17:06:27 <jonatack> I see. I'll read through that meeting again.
5082025-01-23T17:07:09 <fanquake> website updated, bin uploading etc also a bit spread, can see who's doing anything via all the PRs in either case
5092025-01-23T17:07:12 <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
5102025-01-23T17:07:41 <achow101> moreso recently though
5112025-01-23T17:08:01 <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
5122025-01-23T17:08:13 <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.
5132025-01-23T17:08:44 <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
5142025-01-23T17:08:56 <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..
5152025-01-23T17:09:20 <glozow> If you want to participate in the release process, reviewing backports is the majority of the labor
5162025-01-23T17:09:22 <achow101> jonatack: non-maintainers is a bit meh due to the elevated permissions required
5172025-01-23T17:09:22 <fanquake> achow101: yes, that will be happening, possibly from cfields, but nothing concrete yet
5182025-01-23T17:09:40 <glozow> the majority of the non-perms labor*
5192025-01-23T17:10:00 <darosior> Agree it is part of the role of maintainer of doing releases.
5202025-01-23T17:10:29 <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
5212025-01-23T17:11:00 <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.
5222025-01-23T17:11:43 <jonatack> Thanks. No need for a meeting topic for now. It's a thought I have from time to time when recalling that meeting.
5232025-01-23T17:15:44 *** mcey_ <mcey_!~emcy@148.252.128.80> has quit IRC (Ping timeout: 264 seconds)
5242025-01-23T17:16:41 *** Emc99 <Emc99!~Emc99@212.129.76.254> has quit IRC (Quit: Client closed)
5252025-01-23T17:18:12 *** jon_atack <jon_atack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
5262025-01-23T17:18:19 *** mcey <mcey!~emcy@185.69.145.48> has joined #bitcoin-core-dev
5272025-01-23T17:18:26 *** catnip <catnip!~catnip@host-92-13-94-227.as13285.net> has joined #bitcoin-core-dev
5282025-01-23T17:20:30 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 265 seconds)
5292025-01-23T17:23:58 <fanquake> achow101: can you add the next most-relevant wallet removal PR to the 29.x milestone
5302025-01-23T17:25:31 *** catnip <catnip!~catnip@host-92-13-94-227.as13285.net> has quit IRC (Quit: Client closed)
5312025-01-23T17:26:40 *** dzxzg <dzxzg!~dzxzg@user/dzxzg> has quit IRC (Ping timeout: 240 seconds)
5322025-01-23T17:27:12 <achow101> fanquake: added #31495
5332025-01-23T17:27: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
5342025-01-23T17:32:34 *** jon_atack <jon_atack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 252 seconds)
5352025-01-23T17:34:41 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
5362025-01-23T17:42:29 <Sjors[m]> Thanks for the discussion everyone. I marked #30975 draft and left a comment linking to the meeting, addressing some of the comments.
5372025-01-23T17:42:32 <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
5382025-01-23T17:43:00 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9914e7372976...d5a2ba44ba4f
5392025-01-23T17:43:01 <bitcoin-git> bitcoin/master fad83e7 MarcoFalke: doc: Fix incorrect send RPC docs
5402025-01-23T17:43:01 <bitcoin-git> bitcoin/master d5a2ba4 merge-script: Merge bitcoin/bitcoin#31416: doc: Fix incorrect send RPC docs
5412025-01-23T17:43:04 <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
5422025-01-23T17:46:41 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Quit: = "")
5432025-01-23T17:49:25 <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?
5442025-01-23T17:51:27 <Sjors[m]> jeremyrubin: a non-ranged descriptor should look like tr(xpub/0) and you don't need to provide a range arugment
5452025-01-23T17:51:49 <Sjors[m]> Did you try to do tr(xpub/*) with range [0,0] ?
5462025-01-23T17:52:01 <jonatack> found the initial IRC meeting: "topic: Training to rotate release responsibility (neha)"
5472025-01-23T17:52:03 <jonatack> https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-07-01#689418;
5482025-01-23T17:52:04 <gribble> https://github.com/bitcoin/bitcoin/issues/689418 | HTTP Error 404: Not Found
5492025-01-23T17:52:28 <jeremyrubin> walletutil WalletDescriptor requires range arguments
5502025-01-23T17:54:03 <Sjors[m]> Do you mean the bitcoin-wallet binary?
5512025-01-23T17:54:25 <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)
5522025-01-23T17:54:38 <jeremyrubin> Ah, no I'm working on some experimental RPCs that make use of the functionality directly
5532025-01-23T17:55:11 <jeremyrubin> so am really asking about that the constructor for WalletDescriptor accepts range_start = 0, range_end = 0
5542025-01-23T17:55:17 <achow101> jeremyrubin: range is ignored for non-ranged descriptors
5552025-01-23T17:55:41 <achow101> just don't change the range if you're trying to update an existing descriptor
5562025-01-23T17:56:32 <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
5572025-01-23T17:56:58 <jeremyrubin> the change was dropping one tapscript branch
5582025-01-23T17:58:27 <achow101> if the error message says [0,0], the range is actually stored as [0, 1)
5592025-01-23T17:58:56 *** preimage <preimage!~halosghos@user/halosghost> has quit IRC (Ping timeout: 264 seconds)
5602025-01-23T18:00:06 <achow101> except for display, the range is always beginning inclusive, end exclusive
5612025-01-23T18:00:08 <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
5622025-01-23T18:00:15 <jeremyrubin> on inferdescriptor
5632025-01-23T18:00:26 *** preimage <preimage!~halosghos@user/halosghost> has joined #bitcoin-core-dev
5642025-01-23T18:01:22 <achow101> no, the error is entirely about what is in the wallet already
5652025-01-23T18:01:30 <achow101> inferdescriptor doesn't do anything with ranges
5662025-01-23T18:01:42 <achow101> and if inferdescriptor infers an entirely different descriptor, you would not have this error
5672025-01-23T18:02:33 <achow101> jeremyrubin: does this snippet have the change to WalletDescriptor's arguments that made it work?
5682025-01-23T18:02:38 <achow101> or is this the original descriptor?
5692025-01-23T18:02:40 <achow101> or something else?
5702025-01-23T18:03:30 <achow101> also you have start=1, end=0, which doesn't make any sense
5712025-01-23T18:05:42 *** preimage <preimage!~halosghos@user/halosghost> has quit IRC (Ping timeout: 246 seconds)
5722025-01-23T18:07:40 *** preimage <preimage!~halosghos@user/halosghost> has joined #bitcoin-core-dev
5732025-01-23T18:11:45 *** core-meetbot <core-meetbot!~limnoria@user/core-meetbot> has quit IRC (Remote host closed the connection)
5742025-01-23T18:12:02 *** core-meetbot <core-meetbot!~limnoria@user/core-meetbot> has joined #bitcoin-core-dev
5752025-01-23T18:12:06 *** jespada <jespada!~jespada@2800:a4:2317:8200:52e:e131:1453:b068> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzzâ¦)
5762025-01-23T18:17:17 *** preimage <preimage!~halosghos@user/halosghost> has quit IRC (Quit: WeeChat 4.5.1)
5772025-01-23T18:27:06 *** core-meetbot <core-meetbot!~limnoria@user/core-meetbot> has quit IRC (Remote host closed the connection)
5782025-01-23T18:27:22 *** core-meetbot <core-meetbot!~limnoria@user/core-meetbot> has joined #bitcoin-core-dev
5792025-01-23T18:31:56 *** core-meetbot <core-meetbot!~limnoria@user/core-meetbot> has quit IRC (Remote host closed the connection)
5802025-01-23T18:32:12 *** core-meetbot <core-meetbot!~limnoria@user/core-meetbot> has joined #bitcoin-core-dev
5812025-01-23T18:35:41 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Read error: Connection reset by peer)
5822025-01-23T18:36:59 *** dongcarl <dongcarl!~dongcarl@syn-066-065-169-019.res.spectrum.com> has quit IRC (Ping timeout: 244 seconds)
5832025-01-23T18:38:17 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
5842025-01-23T18:45:51 <jeremyrubin> yes this is what made it work, with 0, 0 it failed
5852025-01-23T18:46:20 <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)
5862025-01-23T18:46:32 <jeremyrubin> so 0 1 0 should be start=0, end = 0, next = 0
5872025-01-23T18:46:45 <jeremyrubin> * start = 0, end = 1, next = 0
5882025-01-23T18:47:01 <jeremyrubin> when it is set to start = 0, end = 0, next = 0, then I get the failure
5892025-01-23T18:52:28 <achow101> ah missed creation was being passed
5902025-01-23T18:52:43 <achow101> is the same function producing the descriptor both times?
5912025-01-23T19:01:36 <jeremyrubin> yes
5922025-01-23T19:04:40 *** jespada <jespada!~jespada@2800:a4:2317:8200:52e:e131:1453:b068> has joined #bitcoin-core-dev
5932025-01-23T19:05:20 <achow101> is there a reason you are calling UpdateWalletDescriptor?
5942025-01-23T19:05:42 <achow101> I think there's probably bug, but we never tested that on non-ranged descriptors since it doesn't really make sense to
5952025-01-23T19:06:07 *** jespada <jespada!~jespada@2800:a4:2317:8200:52e:e131:1453:b068> has quit IRC (Client Quit)
5962025-01-23T19:08:20 <jeremyrubin> I'm not actually, I'm calling CWallet::AddWalletDescriptor
5972025-01-23T19:09:03 <achow101> multiple times, presumably
5982025-01-23T19:10:04 <jeremyrubin> good catch -- you found a bug in my code XD
5992025-01-23T19:10:23 <jeremyrubin> was supposed to be calling it with A then B, was calling with A twice by mistake
6002025-01-23T19:10:27 <jeremyrubin> so yes, was calling twice
6012025-01-23T19:10:58 <achow101> i see. well there's probably a bug in UpdateWalletDescriptor too
6022025-01-23T19:11:04 <jeremyrubin> it still seems like a bug yeah
6032025-01-23T19:11:20 <jeremyrubin> since at very least AddWalletDescriptor should be idempotent
6042025-01-23T19:15:58 <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 :)
6052025-01-23T19:16:18 <jeremyrubin> (verified working with 0,0 and AB)
6062025-01-23T19:16:31 <achow101> can you open an issue for the range bug?
6072025-01-23T19:17:16 <jeremyrubin> yeah np
6082025-01-23T19:18:26 *** core-meetbot <core-meetbot!~limnoria@user/core-meetbot> has quit IRC (Remote host closed the connection)
6092025-01-23T19:18:43 *** core-meetbot <core-meetbot!~limnoria@user/core-meetbot> has joined #bitcoin-core-dev
6102025-01-23T19:25:23 <jeremyrubin> #31728
6112025-01-23T19:25:24 <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
6122025-01-23T19:30:58 *** core-meetbot <core-meetbot!~limnoria@user/core-meetbot> has quit IRC (Remote host closed the connection)
6132025-01-23T19:31:13 *** core-meetbot <core-meetbot!~limnoria@user/core-meetbot> has joined #bitcoin-core-dev
6142025-01-23T19:44:22 *** purpleKarrot <purpleKarrot!~purpleKar@2001:1620:5547:0:fafe:5eff:fe5b:42e9> has quit IRC (Quit: Client closed)
6152025-01-23T19:46:33 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
6162025-01-23T19:51:36 *** pyth <pyth!~pyth@123.25.162.204> has quit IRC (Ping timeout: 244 seconds)
6172025-01-23T19:52:47 *** pyth <pyth!~pyth@94.131.10.128> has joined #bitcoin-core-dev
6182025-01-23T20:15:55 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
6192025-01-23T20:30:09 *** pyth <pyth!~pyth@94.131.10.128> has quit IRC (Ping timeout: 276 seconds)
6202025-01-23T20:31:06 *** pyth <pyth!~pyth@123.25.162.204> has joined #bitcoin-core-dev
6212025-01-23T20:51:57 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 246 seconds)
6222025-01-23T20:53:19 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev