12025-11-20T00:14:47 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
22025-11-20T00:22:29 <bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/509dc91db143...27ac11ea0a27
32025-11-20T00:22:30 <bitcoin-git> bitcoin/master 6657bcb stickies-v: kernel: allow null data_directory
42025-11-20T00:22:30 <bitcoin-git> bitcoin/master 27ac11e Ava Chow: Merge bitcoin/bitcoin#33867: kernel: handle null or empty directories in i...
52025-11-20T00:22:31 <bitcoin-git> [bitcoin] achow101 merged pull request #33867: kernel: handle null or empty directories in implementation (master...2025-11/kernel-datadir-nullptr) https://github.com/bitcoin/bitcoin/pull/33867
62025-11-20T00:23:18 <bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/27ac11ea0a27...1af46cff9478
72025-11-20T00:23:19 <bitcoin-git> bitcoin/master fa1bf68 MarcoFalke: clang-format: Set InsertNewlineAtEOF: true
82025-11-20T00:23:19 <bitcoin-git> bitcoin/master 1af46cf Ava Chow: Merge bitcoin/bitcoin#33896: clang-format: Set InsertNewlineAtEOF: true
92025-11-20T00:23:21 <bitcoin-git> [bitcoin] achow101 merged pull request #33896: clang-format: Set InsertNewlineAtEOF: true (master...2511-clang-format-eof-newline) https://github.com/bitcoin/bitcoin/pull/33896
102025-11-20T00:28:45 *** stringintech <stringintech!~stringint@user/stringintech> has quit IRC (Quit: Client closed)
112025-11-20T00:34:46 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has quit IRC (Quit: leaving)
122025-11-20T01:21:17 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Remote host closed the connection)
132025-11-20T01:21:45 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
142025-11-20T01:51:07 <_aj_> achow101: if you're still around to give a quick hot take on the other alternatives for #33671 i can probably update the PR to one of them today
152025-11-20T01:51:09 <corebot> https://github.com/bitcoin/bitcoin/issues/33671 | wallet: Add separate balance info for non-mempool wallet txs by ajtowns · Pull Request #33671 · bitcoin/bitcoin · GitHub
162025-11-20T01:51:47 <_aj_> achow101: ofc if none appeal and we need to think of something else, no rush
172025-11-20T01:53:01 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Remote host closed the connection)
182025-11-20T02:05:33 <achow101> _aj_: need to think on it
192025-11-20T02:13:24 *** dzxzg <dzxzg!~dzxzg@user/dzxzg> has quit IRC (Remote host closed the connection)
202025-11-20T02:18:24 <_aj_> achow101: np
212025-11-20T03:03:08 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
222025-11-20T03:36:00 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
232025-11-20T03:36:33 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
242025-11-20T03:41:16 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 256 seconds)
252025-11-20T03:53:57 *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has quit IRC (Quit: bye)
262025-11-20T03:54:12 *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has joined #bitcoin-core-dev
272025-11-20T03:55:36 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
282025-11-20T05:01:02 *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
292025-11-20T05:01:34 *** cmirror <cmirror!~cmirror@4.53.92.114> has joined #bitcoin-core-dev
302025-11-20T05:04:17 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 264 seconds)
312025-11-20T05:19:59 *** dermoth_ <dermoth_!~dermoth@user/dermoth> has joined #bitcoin-core-dev
322025-11-20T05:20:13 *** dermoth <dermoth!~dermoth@user/dermoth> has quit IRC (Remote host closed the connection)
332025-11-20T05:24:50 *** dermoth_ is now known as dermoth
342025-11-20T05:28:33 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
352025-11-20T05:33:37 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 264 seconds)
362025-11-20T05:46:48 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
372025-11-20T07:04:06 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 244 seconds)
382025-11-20T07:23:44 *** Holz <Holz!~Holz@user/Holz> has quit IRC (Ping timeout: 244 seconds)
392025-11-20T07:24:41 *** jetpack <jetpack!~jetpack@mcfly.vm.tornadovps.net> has quit IRC (Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in)
402025-11-20T07:25:02 *** jetpack <jetpack!~jetpack@mcfly.vm.tornadovps.net> has joined #bitcoin-core-dev
412025-11-20T07:35:33 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
422025-11-20T07:40:17 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 265 seconds)
432025-11-20T07:47:28 *** Holz <Holz!~Holz@user/Holz> has joined #bitcoin-core-dev
442025-11-20T08:04:19 *** memset_ <memset_!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
452025-11-20T08:05:07 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
462025-11-20T08:09:20 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
472025-11-20T08:11:20 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
482025-11-20T08:40:46 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev (Closing Window)
492025-11-20T08:55:50 *** f321x <f321x!~f321x@user/f321x> has joined #bitcoin-core-dev
502025-11-20T08:57:03 *** f321x <f321x!~f321x@user/f321x> has quit IRC (Remote host closed the connection)
512025-11-20T08:58:50 *** f321x <f321x!~f321x@user/f321x> has joined #bitcoin-core-dev
522025-11-20T09:13:40 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 246 seconds)
532025-11-20T09:14:18 *** janb84 <janb84!~janb84@user/janb84> has quit IRC (Ping timeout: 252 seconds)
542025-11-20T09:22:43 *** afiore <afiore!~afiore@user/afiore> has quit IRC (Remote host closed the connection)
552025-11-20T09:27:12 *** janb84 <janb84!~janb84@user/janb84> has joined #bitcoin-core-dev
562025-11-20T09:28:32 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
572025-11-20T09:28:56 *** saturday7 <saturday7!~saturday7@168.140.254.137> has joined #bitcoin-core-dev
582025-11-20T09:35:35 *** janb84 <janb84!~janb84@user/janb84> has quit IRC (Ping timeout: 244 seconds)
592025-11-20T09:37:31 *** janb84 <janb84!~janb84@user/janb84> has joined #bitcoin-core-dev
602025-11-20T09:40:05 *** vasild <vasild!~vd@user/vasild> has quit IRC (Remote host closed the connection)
612025-11-20T09:40:25 *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
622025-11-20T09:51:16 *** afiore <afiore!~afiore@user/afiore> has joined #bitcoin-core-dev
632025-11-20T10:10:36 <bitcoin-git> [bitcoin] maflcko opened pull request #33912: clang-format: Set PackConstructorInitializers: CurrentLine (master...2511-clang-format-PackConstructorInitializers) https://github.com/bitcoin/bitcoin/pull/33912
642025-11-20T10:25:42 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
652025-11-20T10:31:54 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 244 seconds)
662025-11-20T10:47:02 *** vasild <vasild!~vd@user/vasild> has quit IRC (Remote host closed the connection)
672025-11-20T10:47:12 *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
682025-11-20T11:00:35 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
692025-11-20T11:29:30 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
702025-11-20T11:30:03 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
712025-11-20T11:32:52 <bitcoin-git> [bitcoin] Sjors opened pull request #33914: Add string literal convenience overload to Parse() (master...2025/11/parse-string) https://github.com/bitcoin/bitcoin/pull/33914
722025-11-20T11:35:00 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 256 seconds)
732025-11-20T11:48:25 <bitcoin-git> [bitcoin] maflcko opened pull request #33915: test: Retry download in get_previous_releases.py (master...2511-test-retry-prev-donwload) https://github.com/bitcoin/bitcoin/pull/33915
742025-11-20T11:53:07 *** btsf_1 <btsf_1!~btsf_1@2a01cb0885d55c00b020708ad4607b01.ipv6.abo.wanadoo.fr> has quit IRC (Ping timeout: 264 seconds)
752025-11-20T11:53:26 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:3462:8cb2:eb95:dc01> has joined #bitcoin-core-dev
762025-11-20T11:57:05 *** szarka <szarka!~szarka@2603:3003:4eac:100:fcf8:ed5e:a9aa:648d> has quit IRC (Ping timeout: 264 seconds)
772025-11-20T12:03:06 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
782025-11-20T12:08:28 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 255 seconds)
792025-11-20T12:20:40 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
802025-11-20T12:20:59 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
812025-11-20T12:23:29 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
822025-11-20T12:29:13 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 260 seconds)
832025-11-20T12:34:26 *** vasild <vasild!~vd@user/vasild> has quit IRC (Remote host closed the connection)
842025-11-20T12:34:36 *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
852025-11-20T13:01:59 *** btsf_1 <btsf_1!~btsf_1@lmontsouris-659-1-22-122.w81-250.abo.wanadoo.fr> has joined #bitcoin-core-dev
862025-11-20T13:12:37 *** btsf_1 <btsf_1!~btsf_1@lmontsouris-659-1-22-122.w81-250.abo.wanadoo.fr> has quit IRC (Ping timeout: 264 seconds)
872025-11-20T13:14:16 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
882025-11-20T13:20:41 *** btsf_1 <btsf_1!~btsf_1@lmontsouris-659-1-22-122.w81-250.abo.wanadoo.fr> has joined #bitcoin-core-dev
892025-11-20T13:33:46 *** btsf_1 <btsf_1!~btsf_1@lmontsouris-659-1-22-122.w81-250.abo.wanadoo.fr> has quit IRC (Ping timeout: 244 seconds)
902025-11-20T13:45:04 *** afiore_ <afiore_!~afiore@user/afiore> has joined #bitcoin-core-dev
912025-11-20T13:46:00 *** afiore <afiore!~afiore@user/afiore> has quit IRC (Ping timeout: 272 seconds)
922025-11-20T13:46:02 *** afiore_ is now known as afiore
932025-11-20T13:48:53 *** btsf_1 <btsf_1!~btsf_1@lmontsouris-659-1-22-122.w81-250.abo.wanadoo.fr> has joined #bitcoin-core-dev
942025-11-20T13:54:01 *** btsf_1 <btsf_1!~btsf_1@lmontsouris-659-1-22-122.w81-250.abo.wanadoo.fr> has quit IRC (Ping timeout: 264 seconds)
952025-11-20T14:06:58 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Quit: = "")
962025-11-20T14:07:45 <bitcoin-git> [bitcoin] brunoerg opened pull request #33916: fuzz: wallet: add target for `TransactionCanBeBumped` (master...2025-11-fuzz-wallet-feebumper) https://github.com/bitcoin/bitcoin/pull/33916
972025-11-20T14:08:00 *** szkl <szkl!uid110435@id-110435.uxbridge.irccloud.com> has joined #bitcoin-core-dev
982025-11-20T14:17:41 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 244 seconds)
992025-11-20T14:19:33 <bitcoin-git> [bitcoin] hebasto pushed 12 commits to master: https://github.com/bitcoin/bitcoin/compare/1af46cff9478...a07bd8415df4
1002025-11-20T14:19:34 <bitcoin-git> bitcoin/master fad30d4 MarcoFalke: ci: Enable experimental kernel stuff in MSan task
1012025-11-20T14:19:34 <bitcoin-git> bitcoin/master fa9c297 MarcoFalke: ci: Enable experimental kernel stuff in TSan task
1022025-11-20T14:19:34 <bitcoin-git> bitcoin/master fa7da8a MarcoFalke: ci: Enable experimental kernel stuff in valgrind task
1032025-11-20T14:19:36 <bitcoin-git> [bitcoin] hebasto merged pull request #33824: ci: Enable experimental kernel stuff in most CI tasks via `dev-mode` (master...2511-ci-dev-mode-kernel) https://github.com/bitcoin/bitcoin/pull/33824
1042025-11-20T14:29:23 *** btsf_1 <btsf_1!~btsf_1@2a01cb0885d55c005d55722d9e6c9a2a.ipv6.abo.wanadoo.fr> has joined #bitcoin-core-dev
1052025-11-20T14:42:09 <BlueMatt[m]> /query @libera_irc_fanquake:bitcoin.ninja
1062025-11-20T14:42:19 <BlueMatt[m]> okay apparently that doesnt work lol
1072025-11-20T14:44:29 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has joined #bitcoin-core-dev
1082025-11-20T14:47:23 *** enochazariah <enochazariah!~enochazar@user/enochazariah> has joined #bitcoin-core-dev
1092025-11-20T14:55:59 *** stringintech <stringintech!~stringint@user/stringintech> has joined #bitcoin-core-dev
1102025-11-20T14:57:36 *** enochazariah <enochazariah!~enochazar@user/enochazariah> has quit IRC (Quit: Client closed)
1112025-11-20T15:04:39 <bitcoin-git> [bitcoin] hebasto pushed 12 commits to master: https://github.com/bitcoin/bitcoin/compare/a07bd8415df4...e55c49f85143
1122025-11-20T15:04:40 <bitcoin-git> bitcoin/master 8d07292 fanquake: depends: libXau 1.0.12
1132025-11-20T15:04:40 <bitcoin-git> bitcoin/master 5bc0dde fanquake: depends: libxcb-util 0.4.1
1142025-11-20T15:04:40 <bitcoin-git> bitcoin/master 74b68ad fanquake: depends: libxcb-util-image 0.4.1
1152025-11-20T15:04:41 <bitcoin-git> [bitcoin] hebasto merged pull request #33851: depends: update xcb-util packages to latest versions (master...xcb_util_updates) https://github.com/bitcoin/bitcoin/pull/33851
1162025-11-20T15:05:55 *** btsf_1 <btsf_1!~btsf_1@2a01cb0885d55c005d55722d9e6c9a2a.ipv6.abo.wanadoo.fr> has quit IRC (Remote host closed the connection)
1172025-11-20T15:19:11 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has joined #bitcoin-core-dev
1182025-11-20T15:24:08 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1192025-11-20T15:27:34 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
1202025-11-20T15:28:16 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
1212025-11-20T15:57:31 <bitcoin-git> [bitcoin] maflcko opened pull request #33917: clang-format: Set Bitcoin Core IncludeCategories (master...2511-format-includes) https://github.com/bitcoin/bitcoin/pull/33917
1222025-11-20T16:01:22 <kevkevin> hi
1232025-11-20T16:01:26 <l0rinc> hi
1242025-11-20T16:01:28 <eugenesiegel> hi
1252025-11-20T16:01:44 <instagibbs> who's in charge here (hi)
1262025-11-20T16:01:56 <stringintech> hi
1272025-11-20T16:01:57 <cfields> hi
1282025-11-20T16:02:00 <janb84> hi
1292025-11-20T16:02:00 <sipa> hi
1302025-11-20T16:02:04 <TheCharlatan> someone have the meeting link handy?
1312025-11-20T16:02:08 <willcl-ark> hi
1322025-11-20T16:02:15 *** enochazariah <enochazariah!~enochazar@user/enochazariah> has joined #bitcoin-core-dev
1332025-11-20T16:02:15 <fjahr> abubakarsadiq: you here?
1342025-11-20T16:02:24 <yancy> hi
1352025-11-20T16:02:27 <enochazariah> hi
1362025-11-20T16:02:39 <fjahr> he volunteered to host but I can jump in
1372025-11-20T16:02:39 <abubakarsadiq> #startmeeting
1382025-11-20T16:02:39 <corebot> abubakarsadiq: Meeting started at 2025-11-20T16:02+0000
1392025-11-20T16:02:40 <corebot> abubakarsadiq: Current chairs: abubakarsadiq
1402025-11-20T16:02:41 <corebot> abubakarsadiq: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
1412025-11-20T16:02:42 <corebot> abubakarsadiq: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
1422025-11-20T16:02:43 <corebot> abubakarsadiq: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
1432025-11-20T16:02:51 <TheCharlatan> hi :)
1442025-11-20T16:02:55 <fjahr> hi
1452025-11-20T16:02:57 <eugenesiegel> re-hi
1462025-11-20T16:03:05 <abubakarsadiq> #bitcoin-core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge dzxzg eugenesiegel fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs janb84 jarolrod jonatack josibake kanzure kevkevin laanwj LarryRuane lightlike l0rinc luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild
1472025-11-20T16:03:05 <abubakarsadiq> willcl-ark
1482025-11-20T16:03:06 <hebasto> hi
1492025-11-20T16:03:07 <pinheadmz> hi
1502025-11-20T16:03:20 <sipa> i for one welcome our new overlord
1512025-11-20T16:03:28 <abubakarsadiq> There are no pre-proposed meeting topics this week. Any last minute ones to add?
1522025-11-20T16:03:30 *** enochazariah56 <enochazariah56!~enochazar@user/enochazariah> has joined #bitcoin-core-dev
1532025-11-20T16:03:45 *** enochazariah56 <enochazariah56!~enochazar@user/enochazariah> has quit IRC (Client Quit)
1542025-11-20T16:03:48 <laanwj> hii
1552025-11-20T16:03:57 <abubakarsadiq> sorry for being late :) first time thanks sipa
1562025-11-20T16:03:57 <vasild> hi
1572025-11-20T16:04:00 <lightlike> hi
1582025-11-20T16:04:08 *** enochazariah81 <enochazariah81!~enochazar@user/enochazariah> has joined #bitcoin-core-dev
1592025-11-20T16:04:15 <fjahr> I will give a super short asmap update at the end
1602025-11-20T16:04:32 <abubakarsadiq> #topic Kernel WG Update (TheCharlatan)
1612025-11-20T16:04:40 <TheCharlatan> Opened an RFC issue to figure out versioning of the kernel header: https://github.com/bitcoin/bitcoin/issues/33911
1622025-11-20T16:04:47 <TheCharlatan> Please leave some comments :)
1632025-11-20T16:04:56 <sr_gi[m]1> hi
1642025-11-20T16:05:06 <TheCharlatan> That's all.
1652025-11-20T16:05:18 *** stringintech <stringintech!~stringint@user/stringintech> has quit IRC (Quit: Client closed)
1662025-11-20T16:05:23 <abubakarsadiq> #topic Benchmarking WG Update (l0rinc)
1672025-11-20T16:05:31 <l0rinc> We've finished the article about benchmarking and performance optimization for Bitcoin Magazine: Outrunning Entropy: Why Bitcoin Can't Stand Still
1682025-11-20T16:05:39 <l0rinc> Did a few full reindex-chainstate measurements for different parallelism levels for the InputFetcher to see how the cpu affects the performance: https://github.com/bitcoin/bitcoin/pull/31132#issuecomment-3532063730 - it seems beyond ~4 threads the performance gains are usually negligible.
1692025-11-20T16:05:45 *** stringintech <stringintech!~stringint@user/stringintech> has joined #bitcoin-core-dev
1702025-11-20T16:05:46 <l0rinc> Looking for reviewers for two PRs I had to rebase recently: #33738 and #30442 - that's it from me
1712025-11-20T16:05:49 <corebot> https://github.com/bitcoin/bitcoin/issues/33738 | log: avoid collecting `GetSerializeSize` data when compact block logging is disabled by l0rinc · Pull Request #33738 · bitcoin/bitcoin · GitHub
1722025-11-20T16:05:53 <corebot> https://github.com/bitcoin/bitcoin/issues/30442 | precalculate SipHash constant salt XORs by l0rinc · Pull Request #30442 · bitcoin/bitcoin · GitHub
1732025-11-20T16:06:28 <sipa> i plan to review those, but i have a few other things on my plate too
1742025-11-20T16:06:47 *** stringintech <stringintech!~stringint@user/stringintech> has quit IRC (Client Quit)
1752025-11-20T16:06:51 <l0rinc> thank you
1762025-11-20T16:07:00 <abubakarsadiq> I will also review
1772025-11-20T16:07:02 <abubakarsadiq> #topic Cluster Mempool WG Update (sdaftuar, sipa)
1782025-11-20T16:07:06 *** stringintech <stringintech!~stringint@user/stringintech> has joined #bitcoin-core-dev
1792025-11-20T16:07:21 *** enochazariah <enochazariah!~enochazar@user/enochazariah> has quit IRC (Ping timeout: 250 seconds)
1802025-11-20T16:07:44 <sipa> review on #33629 seems to be going well, as the things being addressed seem to be becoming more nitty
1812025-11-20T16:07:48 <corebot> https://github.com/bitcoin/bitcoin/issues/33629 | Cluster mempool by sdaftuar · Pull Request #33629 · bitcoin/bitcoin · GitHub
1822025-11-20T16:08:28 <abubakarsadiq> #topic Stratum v2 WG Update (sjors)
1832025-11-20T16:08:36 <sipa> sdaftuar has been benchmarking the final resulting performance impact of the invocations of linearization, hoping to tune the logic for determining how much budget to give it
1842025-11-20T16:08:45 <sipa> (that's it for me, continue)
1852025-11-20T16:09:05 <Sjors[m]1> Some smal interface changes are in PRs.
1862025-11-20T16:09:43 <Sjors[m]1> And the SRI team is working a Rust client that consumes our IPC interface, which is nice.
1872025-11-20T16:09:44 <abubakarsadiq> share the links @sjors[m]1 ?
1882025-11-20T16:09:56 <Sjors[m]1> #33819
1892025-11-20T16:09:59 *** PaperSword <PaperSword!~Thunderbi@securemail.qrsnap.io> has joined #bitcoin-core-dev
1902025-11-20T16:10:01 <corebot> https://github.com/bitcoin/bitcoin/issues/33819 | mining: add getCoinbase() by Sjors · Pull Request #33819 · bitcoin/bitcoin · GitHub
1912025-11-20T16:10:06 <Sjors[m]1> Maybe #33890
1922025-11-20T16:10:08 <corebot> https://github.com/bitcoin/bitcoin/issues/33890 | mining: add requestedOutputs field, e.g. for merged mining by Sjors · Pull Request #33890 · bitcoin/bitcoin · GitHub
1932025-11-20T16:10:19 <Sjors[m]1> But it's unclear if merge mining is actually a goal for sv2.
1942025-11-20T16:10:37 <Sjors[m]1> BlueMatt or someone else should clarify
1952025-11-20T16:10:43 <yancy> https://github.com/bitcoin/bitcoin/issues/33890
1962025-11-20T16:10:47 <yancy> oops
1972025-11-20T16:10:53 <yancy> link to rust client for ipc?
1982025-11-20T16:10:55 <Sjors[m]1> Or maybe someone who worked on that can chime in on the latter PR.
1992025-11-20T16:11:16 <Sjors[m]1> yancy: https://github.com/stratum-mining/sv2-apps/pull/59
2002025-11-20T16:11:19 <BlueMatt[m]> yea, merged mining is definitely a goal
2012025-11-20T16:11:22 <yancy> thanks
2022025-11-20T16:11:25 <fanquake> Sjors: can you elaborate on #33899, and why we might need to start doing memory management for external clients?
2032025-11-20T16:11:27 <corebot> https://github.com/bitcoin/bitcoin/issues/33899 | Block template memory management (for IPC clients) · Issue #33899 · bitcoin/bitcoin · GitHub
2042025-11-20T16:11:28 <BlueMatt[m]> various miners have it as a requirement
2052025-11-20T16:11:57 <Sjors[m]1> ^ fanquake it's our memory that holds the transactions, we'll crash long before the client does.
2062025-11-20T16:12:09 <Sjors[m]1> It's because multiprocess holds shared pointers on behalf of the client
2072025-11-20T16:12:11 <cfields> Sjors[m]1: while changing the api, maybe fix the missing context param as discussed at coredev? Or has that been addressed somewhere already?
2082025-11-20T16:12:27 <BlueMatt[m]> presumably bitcoin core should just discard them after a minute?
2092025-11-20T16:12:34 <Sjors[m]1> cfields: yes, I have a PR with a bunch of small breaking changes that include the context fix.
2102025-11-20T16:12:43 <cfields> Sjors[m]1: ack, thanks.
2112025-11-20T16:12:43 <BlueMatt[m]> and if its only generating new templates once every NN seconds at max that would trivially remove the issue?
2122025-11-20T16:12:45 <Sjors[m]1> cfields: but the changes I listed above are non-breaking
2132025-11-20T16:12:56 <cfields> ð
2142025-11-20T16:13:17 <fanquake> sjors: ok, reading the issue its not super clear, which direction do you want the memory querying to go?
2152025-11-20T16:13:27 <Sjors[m]1> BlueMatt: ideally i'd like the client to decide when to drop things
2162025-11-20T16:13:46 <BlueMatt[m]> @sjors:sprovoost.nl that is rather incompatible with the goal of being able to expose this over TCP eventually?
2172025-11-20T16:13:52 <BlueMatt[m]> but also I'm not clear on why that's important?
2182025-11-20T16:14:05 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
2192025-11-20T16:14:07 <BlueMatt[m]> like, yea, client deciding when to drop things in the short term seems reasonable
2202025-11-20T16:14:19 <cfields> is that a goal??
2212025-11-20T16:14:24 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
2222025-11-20T16:14:33 <BlueMatt[m]> but if a template has been sitting around for several minutes, then it can presumably be dropped
2232025-11-20T16:14:36 <BlueMatt[m]> cfields: yes?
2242025-11-20T16:14:43 <abubakarsadiq> imo changes at this stage for the interface that is beneficial should go in we should discuss how not break compatibility when we expose a stable interface
2252025-11-20T16:14:54 <sipa> i wouldn't expect to expose the IPC interface over TCP; it'll incur latency you don't want i think?
2262025-11-20T16:15:15 <Sjors[m]1> I don't think the IPC interface needs to be exposed. The Template Provider would.
2272025-11-20T16:15:16 <sipa> run an sv2-ipv protocol adapter locally
2282025-11-20T16:15:23 <sipa> *sv2-ipc
2292025-11-20T16:15:41 <BlueMatt[m]> I do not see why you'd want to run a proxy?
2302025-11-20T16:15:55 <BlueMatt[m]> I mean you'll need to run a proxy if bitcoin core doesn't support listening on tcp, but that can be socat
2312025-11-20T16:15:55 <Sjors[m]1> And a public facing TP can simply tell clients: don't bother me about templates more than 60 seconds old.
2322025-11-20T16:16:15 <fanquake> abubakar: I agree. This is so new, has so few users, and we've given 0 expectations, there shouldn't be an issue making any changes at this point
2332025-11-20T16:16:19 <BlueMatt[m]> Sjors[m]1: I guess my question is why do you want to support templates older than a few minutes at all?
2342025-11-20T16:16:38 <Sjors[m]1> BlueMatt: maybe because miner ignored the fee bump templates?
2352025-11-20T16:16:39 <BlueMatt[m]> I mean after ten-ish minutes the templates are pretty likely to be useless :p
2362025-11-20T16:16:52 <sipa> BlueMatt[m]: my understanding is that they need to be kept for the case a hasher still finds a nonce for one
2372025-11-20T16:17:16 <BlueMatt[m]> right, but my point is only that after some reasonably long duration it seems like an incredibly safe assumption that no one is still mining on it
2382025-11-20T16:17:21 <BlueMatt[m]> and thus they wont find a nonce for it
2392025-11-20T16:17:34 <BlueMatt[m]> maybe a related question - is ten minutes sufficient?
2402025-11-20T16:17:40 <Sjors[m]1> My point is that stratum v2 software knows what miners need, and if it thinks it's safe to drop a template then it can do that. On our side we don't have to reason about it.
2412025-11-20T16:18:05 <BlueMatt[m]> like if all 10-minute-old templates are discarded even if the client hasn't marked it explicitly safe to discard does that sufficiently limit memory to not be a concern (I imagine it would?)
2422025-11-20T16:18:08 <Sjors[m]1> Currently the Template Provider holds on to all templates until 30 seconds after a tip change.
2432025-11-20T16:18:23 <BlueMatt[m]> even that presumably suffices to not run out of memory?
2442025-11-20T16:19:10 <Sjors[m]1> If we push a new template every second for 2 hours that's 28 GB assuming maximum mempool churn.
2452025-11-20T16:19:15 <BlueMatt[m]> as long as bitcoin core is deciding when to build a new template, and its only doing so every 30 seconds, worst-case you have like 40 templates?
2462025-11-20T16:19:32 <BlueMatt[m]> right, but presumably we aren't sending a new template every second ever?
2472025-11-20T16:19:35 <BlueMatt[m]> bitcoin core should refuse to do that
2482025-11-20T16:19:39 <Sjors[m]1> We do if the client asks
2492025-11-20T16:19:48 <BlueMatt[m]> we should stop doing that :)
2502025-11-20T16:19:56 <Sjors[m]1> And I also think we shouldn't decide what the safe minimum frequency is.
2512025-11-20T16:20:00 <BlueMatt[m]> well, if a client asks we can send the one we just generated :)
2522025-11-20T16:20:03 <sipa> the IPC interface is trivially DoS vulnerable anyway - it inherently assumes a client that isn't going to DoS it
2532025-11-20T16:20:27 <abubakarsadiq> fanquake: we would want to handle memory internally because currently we hold on the generated block templates, waitnext create templates after after second when their is fee increase. their is a scenario where there is lots of inflow that improve mempool fees continuously and you generate lots of templates and keep in memory. If you don't manage and have a limit it thats a potential problem I think
2542025-11-20T16:20:31 <Sjors[m]1> Currently the IPC takes an argument which sets that minimum update frequency (in seconds).
2552025-11-20T16:20:37 <BlueMatt[m]> sipa: if you assume the protocol is more strictly checked so that the messages aren't invalid is that still true?
2562025-11-20T16:20:54 <BlueMatt[m]> Sjors[m]1: why? shouldn't that be something bitcoin core decides?
2572025-11-20T16:20:55 <sipa> BlueMatt[m]: yes
2582025-11-20T16:21:02 <BlueMatt[m]> bitcoin core knows what the feerate difference is between different templates
2592025-11-20T16:21:15 <Sjors[m]1> BlueMatt[m]: No because we can do it 10x per second but node software of ASIC firmware might crash if it can't keep up.
2602025-11-20T16:21:20 <BlueMatt[m]> so it seems like it should always be bitcoin core deciding when to issue new templates (maybe based on config, but certainly not based on when clients request)
2612025-11-20T16:21:35 <Sjors[m]1> We send a new templates when fees rise by N sats, but only if it's been at least M seconds.
2622025-11-20T16:22:02 <BlueMatt[m]> right, but presumably if the client is limited to N updates per second on their asic they will simply not push the new work and ignore it?
2632025-11-20T16:22:13 <BlueMatt[m]> that's what ultimately will happen in the sv1/2 client on the device anyway
2642025-11-20T16:22:42 <BlueMatt[m]> like even if the translator feeds templates in 100 times a second the firmware will just not switch fast (unless you set the flush flag, ofc)
2652025-11-20T16:23:16 <BlueMatt[m]> anyway, all I'm saying is fewer config knobs for the template IPC client means less effort thinking about all this stuff, and I'm quite skeptical the config knobs are useful :)
2662025-11-20T16:23:35 <Sjors[m]1> Those are all things miners / pools should be experts in, and we have no idea what values to pick.
2672025-11-20T16:23:50 <BlueMatt[m]> sipa: I'll follow up and ask why later, but that seems like something we should resolve (at least if we limit the interface to just the mining IPC and not the various other IPC things)
2682025-11-20T16:23:54 <Sjors[m]1> The Template Provider can hardcode values.
2692025-11-20T16:24:14 <BlueMatt[m]> hmm? I'm really unclear on which of the above are an issue?
2702025-11-20T16:24:29 <BlueMatt[m]> my point is that it doesn't matter how fast bitcoin core generates templates, the mining device will rate-limit it itself
2712025-11-20T16:25:00 <sipa> so it should tell bitcoin core / template provider / something sv2, what that rate limit is?
2722025-11-20T16:25:02 <BlueMatt[m]> so istm bitcoin core should be configurable (via bitcoin.conf) to generate templates based on fee increases or time as needed, with reasonable defaults (seems like that's already a thing?) and from there we don't need to worry about individual clients
2732025-11-20T16:25:11 <Sjors[m]1> Bitcoin Core can ship only one release per 6 months. I'd rather have a few too many IPC parameters that the TP doesn't use, then having to argue about changing something in the codebase because new miner suddenly wants N or M different.
2742025-11-20T16:25:27 <BlueMatt[m]> sipa: no, I dont think so because you may have 1000 devices with different limits hanging off of one template generation coming out of bitcoin core
2752025-11-20T16:25:44 <BlueMatt[m]> the templates themselves shouldn't be rate-limited coming out of bitcoin core based on hardware limitations
2762025-11-20T16:26:01 <sipa> i don't follow at all anymore
2772025-11-20T16:26:08 <BlueMatt[m]> Sjors[m]1: my related comment was that the config knobs for this should be in bitcoin.conf, not the IPC client :p
2782025-11-20T16:26:08 <sipa> and i don't think this is a good use of this meeting time
2792025-11-20T16:26:24 <BlueMatt[m]> okay, well clearly this needs more discussion, maybe we schedule a followup call
2802025-11-20T16:26:29 <BlueMatt[m]> so we can do it live rather than over irc
2812025-11-20T16:26:30 <Sjors[m]1> Right, seems better to discuss in one of the above issues.
2822025-11-20T16:26:41 <abubakarsadiq> moving on
2832025-11-20T16:26:44 <abubakarsadiq> #topic Net Split WG Update (cfields)
2842025-11-20T16:26:59 <cfields> Very sorry to all who are waiting... still nothing to report. Working through a few other things before shifting my focus 99% to this.
2852025-11-20T16:27:31 <abubakarsadiq> #topic asmap update (fjahr)
2862025-11-20T16:27:46 <fjahr> Hi! The original embedding PR has been slip up into a triplet. The first part is already merged by now. The second part contains necessary refactorings and extensive added documentation in the implementation which was briefly discussed at CoreDev and should hopefully help getting people through this toughest part of the review. The third adds the build stuff (and that is the PR that used to be the main thing).
2872025-11-20T16:27:52 <fjahr> There have also been some spin-off discussions on how the -asmap arg should work and this resulted in two separate PRs that are currently open. All this can be found through the freshly rebooted tracking issue: #33879.
2882025-11-20T16:27:53 <corebot> https://github.com/bitcoin/bitcoin/issues/33879 | Embedded ASMap data Tracking Issue (Part 2) · Issue #33879 · bitcoin/bitcoin · GitHub
2892025-11-20T16:27:58 <fjahr> Special thanks to hodlinator who has given very valuable feedback in his detailed reviews in the last two weeks â¤ï¸
2902025-11-20T16:28:10 <fjahr> Thatâs it unless there are questions.
2912025-11-20T16:28:33 <fanquake> fjahr: Wanted to follow up with one of mine
2922025-11-20T16:28:40 <sipa> fjahr: i have been very hard to refrain myself from suggesting yet another "how -asmap argument should work", because i really don't care and want people to agree on something :p
2932025-11-20T16:28:59 <sipa> +trying
2942025-11-20T16:29:27 <fjahr> hehe, yeah, seems like everyone has their favorite -asmap :)
2952025-11-20T16:29:34 <fanquake> In regards to recreating the files in https://github.com/asmap/asmap-data. How does someone go about that
2962025-11-20T16:29:56 <fanquake> That was my question in regards to how would someone build from source, without having to take some binary blob as an input
2972025-11-20T16:30:21 <sipa> it's time sensitive, so if you repeat the gathering process at a different time, you'll get a different result
2982025-11-20T16:30:55 <fanquake> Yes, but is the raw data used to create those blobs saved somewhere?
2992025-11-20T16:31:03 <BlueMatt[m]> best you can do is re-run it and do some kind of diff telling you total IPs different
3002025-11-20T16:31:11 <fjahr> The runs we do with multiple people are coordinated in issues such as this: https://github.com/asmap/asmap-data/issues/34 If there is agreement between enough people about the included data, that is shared there.
3012025-11-20T16:31:12 <sipa> BlueMatt[m]: we have a diff tool
3022025-11-20T16:31:14 *** stringintech <stringintech!~stringint@user/stringintech> has quit IRC (Quit: Client closed)
3032025-11-20T16:31:18 <fanquake> Otherwise we are going to end up in a situation where you can't actually build a release bin from source, without taking some binary blob
3042025-11-20T16:31:29 <fanquake> which some group, and some time, generated
3052025-11-20T16:31:32 <fanquake> *at
3062025-11-20T16:31:43 <fjahr> Then the file is processed and merged into the repo with a PR such as this: https://github.com/asmap/asmap-data/pull/35
3072025-11-20T16:31:47 <fanquake> it'd be nice if that didn't become mandatory
3082025-11-20T16:32:03 <sipa> so that would imply storing all the data fetched by kartograf in the repo?
3092025-11-20T16:33:00 <fanquake> I assume so. Asking somewhat in the context of wether we have a build option to disable this feature. I imagine we might want that, if someone want to be able to compile with having to use this data, which they can't actually recreate
3102025-11-20T16:33:01 <fjahr> The raw data that is downloaded by each participant could be shared somewhere too, this is about 2G and it will be slightly different for each participant so we would have again decide who should upload it and where.
3112025-11-20T16:34:06 <fjahr> It's a snapshot of the internet routing table, I think to some degree it will be that we are working with data that some group at some point generated.
3122025-11-20T16:34:34 <fjahr> The process we are doing is trying to match the level of scrutiny of a core PR.
3132025-11-20T16:34:50 <fanquake> Sure, I am just trying to keep things trust minimized, and introducing new blobs, which can't be recreated after the fact, is moving in the other direction
3142025-11-20T16:35:15 <sipa> i think that's inevitable because it's ultimately based on non-verifiable data
3152025-11-20T16:36:27 <sipa> even if we save the source data gathered during the process, to enable re-creating the asmap.dat determinstically from that data, it's just moving the trust question elsewhere: was this dump created honestly?
3162025-11-20T16:37:08 <vasild> is the dump easier to inspect than asmap.dat?
3172025-11-20T16:37:17 <darosior> Could it be something that is shipped separately from the binary?
3182025-11-20T16:37:20 <fjahr> We can inspect the data and do checks to make sure the data is reasonably realistic but fully validating it would be unresable
3192025-11-20T16:38:09 <sipa> i doubt it's easier
3202025-11-20T16:38:23 <vasild> if I do fetch myself and create my own asmap.dat from my dump, can I diff it against the shipped asmap.dat with the diff tools or do they run on the dumps?
3212025-11-20T16:38:25 <fanquake> Yea, I agree, but having the data at least lets anyone that wants too, not have to take a blob, that they can re-create it themselves. Maybe if we have more of the group involved in the creation of these inputs, it's also better
3222025-11-20T16:38:31 <fjahr> A manipulated map where all peers are in one bucket is easy to detect for example
3232025-11-20T16:39:31 <sipa> fanquake: but in what way is the kartograf fetched data dump different from "have to take a blob", it's still a blob you have to trust, just a much bigger one, in multiple formats, with a ton of information that's irrelevant for us
3242025-11-20T16:39:32 <TheCharlatan> darosior I don't think that would significantly improve things.
3252025-11-20T16:39:34 <l0rinc> fjahr: are the automatic (statistical?) validations for that?
3262025-11-20T16:40:11 *** nanotube <nanotube!~nanotube@user/nanotube> has quit IRC (Ping timeout: 244 seconds)
3272025-11-20T16:40:14 <instagibbs> sipa having regular process with more than 1 person is good to stave off process rot if not a security enhancement
3282025-11-20T16:40:15 <sipa> l0rinc: we report the asn variety in addrman, according to the provided asmap data
3292025-11-20T16:40:26 <sipa> instagibbs: there is
3302025-11-20T16:40:33 <fjahr> You mean the health check? Yeah, that's information that is printed though there is no threshold where it sets of an alarm or so
3312025-11-20T16:40:35 <fanquake> sipa: sure, but if everyone who signed off on the smaller blob, also dumps there data, I can atleast recreate the thing they are all attestign too, using the same tools
3322025-11-20T16:41:01 <instagibbs> sipa ð (it tried to have me pick ship emoji, telling)
3332025-11-20T16:41:46 <darosior> TheCharlatan: why? It's separating concerns. Keep the binary entirely reproducible. Have the semi-reproducible data alongside, which can be discarded if desired (but still shipped and enabled by default).
3342025-11-20T16:42:01 *** Emc99 <Emc99!~Emc99@212.129.75.24> has joined #bitcoin-core-dev
3352025-11-20T16:42:01 <sipa> darosior: 2G per participant is a lot of data
3362025-11-20T16:43:26 <darosior> sipa: not sure i follow. I'm just asking why not shipping the compressed data alongside the binary. For instance in /usr/share, in the same way we ship the multiprocess binaries in /usr/libexec
3372025-11-20T16:44:23 <sipa> darosior: as i understand it, the source data is gigabytes per participant, and it won't be the same for everything - it's just the resulting asmap data that doesn't change
3382025-11-20T16:44:28 <sipa> (mostly)
3392025-11-20T16:44:38 <sipa> *for everyone
3402025-11-20T16:44:49 <darosior> Yes i'm talking about the data that would be embedded in the binary
3412025-11-20T16:44:51 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
3422025-11-20T16:44:56 <TheCharlatan> darosior, not sure that is really relevant, I would treat this similarly to any other chainparams data. But thinking aloud here, it might still be nice to do that in case people would like to udpate it without having to either change their configs, or their binary.
3432025-11-20T16:45:29 <sipa> darosior: the asmap.dat file? you can just extract it from bitcoind (i think there was a plan of adding an RPC to dump it out)
3442025-11-20T16:45:54 <sipa> i think the rest of the discussion is here about the source material from which the asmap.dat file is built
3452025-11-20T16:45:59 <sipa> which is routing table dumps
3462025-11-20T16:48:51 <vasild> is it easier to compare two routing table dumps VS compare two asmap.dat?
3472025-11-20T16:49:21 <vasild> compare = see how many % difference there is
3482025-11-20T16:49:37 <fjahr> the two asmap, the dump has even more data we don't care about so we don't need to look at that because we don't use it anyway
3492025-11-20T16:50:06 <fanquake> (I'll follow up in https://github.com/asmap/asmap-data / the relevant PRs)
3502025-11-20T16:50:21 <abubakarsadiq> Anything else to discuss?
3512025-11-20T16:50:47 <fjahr> The tracking issue could also be a venue for discussion, fwiw.
3522025-11-20T16:50:47 <vasild> ok, so if I do not trust the binary blob asmap.dat and if I want to "verify" it, I can generate my own and diff it and if the diff % is below some number, then it is ok.
3532025-11-20T16:51:24 <abubakarsadiq> thanks fjahr link here https://github.com/bitcoin/bitcoin/issues/33879
3542025-11-20T16:52:17 <BlueMatt[m]> ha cool my flight got diverted and it reset the wifi and made me buy it again, sorry if some messages got delivered late
3552025-11-20T16:52:53 <fjahr> vasild: maybe :) a low diff is a good indication there is nothing completely wrong but there would still be manipulation which targets a specific subset of nodes. So we need to look at coverage of nodes and that there asn distribution is still feasible at least.
3562025-11-20T16:54:03 <vasild> fjahr: have a built in asmap.dat diff tool which does that against the own addrman ;)
3572025-11-20T16:54:24 <fjahr> Happy to answer more questions after the meeting or in the tracking issue or whereever
3582025-11-20T16:54:35 <abubakarsadiq> novo__: mentioned to me that he has no update this week on silent payments wg
3592025-11-20T16:54:41 <abubakarsadiq> with that
3602025-11-20T16:54:46 <abubakarsadiq> #endmeeting
3612025-11-20T16:54:46 <corebot> abubakarsadiq: Meeting ended at 2025-11-20T16:54+0000
3622025-11-20T16:54:47 <corebot> abubakarsadiq: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-11-20_16_02.log.json
3632025-11-20T16:54:48 <corebot> abubakarsadiq: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-11-20_16_02.log.html
3642025-11-20T16:54:49 <corebot> abubakarsadiq: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-11-20_16_02.html
3652025-11-20T16:55:04 <sipa> vasild: i think that'd be a cool idea, we could have an RPC which you provide a prospective asmap.dat file, and it gives you a diff, restricted to your own addrman contents, between the loaded asmap data and the one you provide
3662025-11-20T16:55:26 <vasild> yes
3672025-11-20T16:55:33 *** enochazariah81 <enochazariah81!~enochazar@user/enochazariah> has quit IRC (Quit: Client closed)
3682025-11-20T16:55:50 *** enochazariah <enochazariah!~enochazar@user/enochazariah> has joined #bitcoin-core-dev
3692025-11-20T16:56:13 <fjahr> We have a tool that let's you do that with a list of addresses that you export and two asmaps, it's just not an RPC
3702025-11-20T16:56:42 <fjahr> asmap_tool.py diff_addrs, unless I am misunderstand what you are thinking of
3712025-11-20T16:57:27 *** enochazariah <enochazariah!~enochazar@user/enochazariah> has quit IRC (Client Quit)
3722025-11-20T16:57:28 *** Emc99 <Emc99!~Emc99@212.129.75.24> has quit IRC (Quit: Client closed)
3732025-11-20T16:57:41 *** enochazariah <enochazariah!~enochazar@user/enochazariah> has joined #bitcoin-core-dev
3742025-11-20T16:57:42 <vasild> "list of addresses that you export" -- that would be your entire addrman, right?
3752025-11-20T16:57:43 *** Emc99 <Emc99!~Emc99@212.129.75.24> has joined #bitcoin-core-dev
3762025-11-20T16:57:43 <instagibbs> was hoping we'd get cluster mempool PR in soon, various other testing/behavior improvements are in holding pattern to not force rebase. gentle prod
3772025-11-20T16:57:58 <fjahr> vasild: that's what I have been doing, yepp
3782025-11-20T16:58:08 <vasild> ok, so it exists
3792025-11-20T16:59:44 *** Emc99 <Emc99!~Emc99@212.129.75.24> has quit IRC (Client Quit)
3802025-11-20T16:59:51 <darosior> Ok so for what it's worth my confusion was whether it was an issue of trust in our source code or an issue of reproducible builds. I assumed it was the latter, but it is the former: the data is committed in our repository https://github.com/bitcoin/bitcoin/pull/28792/commits/8102128cbc2511ea767651d060843284b99c3788
3812025-11-20T17:00:22 <fanquake> darosior: my issue is the later
3822025-11-20T17:01:14 <sipa> fanquake: the bitcoin core build is and remains reproducible, it just uses the asmap.dat file in our repo, added in the commit darosior links to
3832025-11-20T17:01:20 <fanquake> It will be reproducible, but we should aim to minimize trust in binary inputs as much as possible, and this is introducing a situation, where you can't actually recreate the inputs
3842025-11-20T17:01:29 <sipa> fanquake: right
3852025-11-20T17:01:43 *** stringintech <stringintech!~stringint@user/stringintech> has joined #bitcoin-core-dev
3862025-11-20T17:02:06 <sipa> my point is that this is an unsolvable problem, because no matter how far you go back, and include the source material instead of the result, you end up with binary blobs you need to trust are correct
3872025-11-20T17:02:41 <fjahr> But this is fundamentally the same with the seeds, right? The main difference is that they are easier to reason about.
3882025-11-20T17:02:49 <sipa> indeed
3892025-11-20T17:03:07 <fanquake> A mitigation is to ensure that as many contributors are generating this data, and attesting to it, as possible
3902025-11-20T17:03:14 <sipa> fanquake: absolutely!
3912025-11-20T17:03:29 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has quit IRC (Quit: Client closed)
3922025-11-20T17:04:04 <TheCharlatan> could commit to a hard threshold of individuals that have to contribute it.
3932025-11-20T17:04:25 <sipa> fjahr: how do i subscribe to notifications for the next collaborative build?
3942025-11-20T17:04:26 <fjahr> I agree, that would be great!
3952025-11-20T17:04:38 <darosior> It's also reassuring that malicious malleations would be obvious, as fjahr underlined during the meeting
3962025-11-20T17:04:40 <fanquake> With at least some % crossover of active Guix builders
3972025-11-20T17:04:43 <sipa> i've wanted to for a while, but i always just hear about them after the fact
3982025-11-20T17:05:07 <fanquake> (or just active Core contributors)
3992025-11-20T17:05:38 <darosior> fanquake: it seems to be more the realm of Core contributors, if we treat it as "source"?
4002025-11-20T17:05:51 <sipa> should i Watch https://github.com/asmap/asmap-data ?
4012025-11-20T17:06:06 <darosior> Guix builders are supposed to just take whatever source Core contributors vouched and ensure it matches the binary output?
4022025-11-20T17:06:11 <fjahr> I guess subscribe to https://github.com/asmap/asmap-data/? We have been tagging people that have participated in the past in the issue and we are experimenting with a team to notify people easier because github notifications are terrible. I can tag you and announce the next one here as well.
4032025-11-20T17:06:18 <fjahr> sipa: ^
4042025-11-20T17:06:20 <fanquake> darosior: possibly, I just think it's more likely that someone regularly guix building, will be aware, and able to contribute to doing another process
4052025-11-20T17:06:33 <darosior> Yeah fiar
4062025-11-20T17:07:03 <sipa> right, guix building is attesting to the compilation process from source to executable
4072025-11-20T17:07:27 <TheCharlatan> there's usually an issue for a collaborative launch posted a few weeks before, e.g. https://github.com/asmap/asmap-data/issues/34
4082025-11-20T17:07:46 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has joined #bitcoin-core-dev
4092025-11-20T17:08:01 <sipa> asmap building is attesting to the fetching of route tables at a particular point in time, ultimately (and for pragmatic reasons, the conversion of it to asmap.dat too, because that makes the attestation much more exact and small)
4102025-11-20T17:08:07 *** tarotfied <tarotfied!~tarotfied@user/tarotfied> has quit IRC (Ping timeout: 264 seconds)
4112025-11-20T17:08:12 *** dviola <dviola!~diego@user/dviola> has quit IRC (Ping timeout: 256 seconds)
4122025-11-20T17:08:19 *** justache- <justache-!~justache@user/justache> has joined #bitcoin-core-dev
4132025-11-20T17:08:21 *** cfields <cfields!~cfields@user/cfields> has quit IRC (Read error: Connection reset by peer)
4142025-11-20T17:08:26 *** jerryf_ <jerryf_!~jerryf@user/jerryf> has joined #bitcoin-core-dev
4152025-11-20T17:08:43 *** justache <justache!~justache@user/justache> has quit IRC (Ping timeout: 264 seconds)
4162025-11-20T17:08:48 *** f321x <f321x!~f321x@user/f321x> has quit IRC (Quit: f321x)
4172025-11-20T17:08:49 *** enochazariah <enochazariah!~enochazar@user/enochazariah> has quit IRC (Quit: Client closed)
4182025-11-20T17:09:07 <sipa> if only there was some globally trusted Master of the Internet, which published certified routing tables :p
4192025-11-20T17:09:38 <fjahr> on a blockchain!
4202025-11-20T17:09:43 *** phantomcircuit_ <phantomcircuit_!~phantomci@2604:a880:1:20::f2:c001> has joined #bitcoin-core-dev
4212025-11-20T17:09:47 *** tarotfied <tarotfied!~tarotfied@user/tarotfied> has joined #bitcoin-core-dev
4222025-11-20T17:09:50 *** diego <diego!~diego@189.35.235.21> has joined #bitcoin-core-dev
4232025-11-20T17:09:51 <darosior> :)
4242025-11-20T17:10:15 <instagibbs> on blockchain* fjahr
4252025-11-20T17:10:17 *** diego is now known as Guest6935
4262025-11-20T17:10:31 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has quit IRC (Ping timeout: 264 seconds)
4272025-11-20T17:11:04 <darosior> on The Blockchain
4282025-11-20T17:11:07 *** phantomcircuit <phantomcircuit!~phantomci@192.241.205.97> has quit IRC (Ping timeout: 264 seconds)
4292025-11-20T17:11:14 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
4302025-11-20T17:12:12 <instagibbs> https://github.com/asmap/kartograf?tab=readme-ov-file#coordinated-launch-for-building-ip-prefix-to-asn-maps coordinated launch description relating to that issue above
4312025-11-20T17:13:06 *** jerryf <jerryf!~jerryf@user/jerryf> has quit IRC (Ping timeout: 272 seconds)
4322025-11-20T17:14:23 <fjahr> There is also a delving post here: https://delvingbitcoin.org/t/asmap-creation-process/548 not much has changed since then so it should be up to date as well
4332025-11-20T17:17:00 *** enochazariah <enochazariah!~enochazar@user/enochazariah> has joined #bitcoin-core-dev
4342025-11-20T17:17:29 <bitcoin-git> [bitcoin] fanquake merged pull request #33905: ci: Consistenly only cache on the default branch (master...2511-ci-cache-branch) https://github.com/bitcoin/bitcoin/pull/33905
4352025-11-20T17:19:36 <bitcoin-git> [bitcoin] fanquake merged pull request #33880: test: Fix race condition in IPC interface block progation test (master...2025-11-ipc-test) https://github.com/bitcoin/bitcoin/pull/33880
4362025-11-20T17:22:32 <bitcoin-git> [bitcoin] fanquake merged pull request #33887: doc: Improve CI docs on env and qemu-user-static (master...2025/11/issue_31199_ci_docs) https://github.com/bitcoin/bitcoin/pull/33887
4372025-11-20T17:23:35 <bitcoin-git> [bitcoin] hebasto opened pull request #33918: depends: Update Qt download link (master...251120-qt-link) https://github.com/bitcoin/bitcoin/pull/33918
4382025-11-20T17:23:45 *** Guest53 <Guest53!~Guest53@103.26.109.20> has joined #bitcoin-core-dev
4392025-11-20T17:25:05 <bitcoin-git> [bitcoin] hebasto closed pull request #31724: cmake: Fix `-pthread` flags presentation in summary (master...250123-cmake-pthread) https://github.com/bitcoin/bitcoin/pull/31724
4402025-11-20T17:25:07 *** Guest53 <Guest53!~Guest53@103.26.109.20> has quit IRC (Client Quit)
4412025-11-20T17:25:53 *** pablomartin is now known as pablomartin4btc
4422025-11-20T17:27:54 <bitcoin-git> [bitcoin] fanquake merged pull request #33870: refactor: remove incorrect lifetimebounds (master...remove-incorrect-lifetimebounds) https://github.com/bitcoin/bitcoin/pull/33870
4432025-11-20T17:30:07 <bitcoin-git> [bitcoin] fanquake merged pull request #33888: ci: Re-enable LINT_CI_SANITY_CHECK_COMMIT_SIG (master...2511-ci-lint-stuff) https://github.com/bitcoin/bitcoin/pull/33888
4442025-11-20T17:31:31 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e55c49f85143...32368cd3e9f3
4452025-11-20T17:31:32 <bitcoin-git> bitcoin/master fa411f9 MarcoFalke: ci: Consistenly only cache on the default branch
4462025-11-20T17:31:32 <bitcoin-git> bitcoin/master 32368cd merge-script: Merge bitcoin/bitcoin#33905: ci: Consistenly only cache on the default bra...
4472025-11-20T17:32:01 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/32368cd3e9f3...29c37651c74b
4482025-11-20T17:32:02 <bitcoin-git> bitcoin/master 2578e6f Fabian Jahr: test: Fix race condition in IPC interface block propagation test
4492025-11-20T17:32:02 <bitcoin-git> bitcoin/master 29c3765 merge-script: Merge bitcoin/bitcoin#33880: test: Fix race condition in IPC interface blo...
4502025-11-20T17:32:40 <fanquake> I'm hearing murmurs that cluster is getting close(r)
4512025-11-20T17:32:56 <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/29c37651c74b...6cdb51c14eba
4522025-11-20T17:32:57 <bitcoin-git> bitcoin/master 2afbbdd Hodlinator: doc: CI - Clarify how important `env -i` is and why
4532025-11-20T17:32:57 <bitcoin-git> bitcoin/master 552eb90 Hodlinator: doc: CI - Describe qemu-user-static usage
4542025-11-20T17:32:57 <bitcoin-git> bitcoin/master 6cdb51c merge-script: Merge bitcoin/bitcoin#33887: doc: Improve CI docs on env and qemu-user-sta...
4552025-11-20T17:32:59 <fanquake> and if that's the case, we should defer #32587 and #33862 for now
4562025-11-20T17:33:07 <corebot> fanquake: Error: That URL raised <Connection timed out.>
4572025-11-20T17:33:09 <corebot> fanquake: Error: That URL raised <HTTP Error 503: Service Unavailable>
4582025-11-20T17:33:17 <fanquake> to avoid a reorg, if cluster if going to get pushed to again, then they could both go in now
4592025-11-20T17:33:28 <fanquake> *to avoid a rebase
4602025-11-20T17:33:32 <fanquake> #32587
4612025-11-20T17:33:37 <corebot> https://github.com/bitcoin/bitcoin/issues/32587 | test: Fix reorg patterns in tests to use proper fork-based approach by yuvicc · Pull Request #32587 · bitcoin/bitcoin · GitHub
4622025-11-20T17:33:40 <fanquake> #33862
4632025-11-20T17:33:43 <corebot> fanquake: Error: That URL raised <HTTP Error 503: Service Unavailable>
4642025-11-20T17:34:02 <fanquake> https://github.com/bitcoin/bitcoin/pull/33862
4652025-11-20T17:34:28 <bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/6cdb51c14eba...ac71df43383a
4662025-11-20T17:34:29 <bitcoin-git> bitcoin/master 141117f Andrew Toth: refactor: remove incorrect LIFETIMEBOUND annotations
4672025-11-20T17:34:29 <bitcoin-git> bitcoin/master f743e6c Andrew Toth: refactor: add missing LIFETIMEBOUND annotation for parameter
4682025-11-20T17:34:29 <bitcoin-git> bitcoin/master 99d012e Andrew Toth: refactor: return reference instead of pointer
4692025-11-20T17:34:34 <bitcoin-git> [bitcoin] fanquake pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/ac71df43383a...6b2d17b13220
4702025-11-20T17:34:34 <bitcoin-git> bitcoin/master fa1daca MarcoFalke: ci: Move lint exec snippet to stand-alone py file
4712025-11-20T17:34:35 <bitcoin-git> bitcoin/master faa0973 MarcoFalke: ci: [refactor] Rename CIRRUS_PR env var to LINT_CI_IS_PR
4722025-11-20T17:34:35 <bitcoin-git> bitcoin/master fa0ce4c MarcoFalke: ci: Re-enable LINT_CI_SANITY_CHECK_COMMIT_SIG
4732025-11-20T17:35:00 *** saturday- <saturday-!~saturday7@206.83.105.196> has joined #bitcoin-core-dev
4742025-11-20T17:36:05 *** saturday7 <saturday7!~saturday7@168.140.254.137> has quit IRC (Ping timeout: 264 seconds)
4752025-11-20T17:39:24 *** szkl <szkl!uid110435@id-110435.uxbridge.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
4762025-11-20T17:40:30 <instagibbs> #33862 try try again
4772025-11-20T17:40:33 <corebot> https://github.com/bitcoin/bitcoin/issues/33862 | txgraph: drop move assignment operator by sipa · Pull Request #33862 · bitcoin/bitcoin · GitHub
4782025-11-20T17:41:53 *** Talkless <Talkless!~Talkless@138.199.6.197> has joined #bitcoin-core-dev
4792025-11-20T17:57:16 *** stringintech <stringintech!~stringint@user/stringintech> has quit IRC (Quit: Client closed)
4802025-11-20T17:59:26 *** jerryf_ <jerryf_!~jerryf@user/jerryf> has quit IRC (Remote host closed the connection)
4812025-11-20T17:59:49 *** jerryf <jerryf!~jerryf@user/jerryf> has joined #bitcoin-core-dev
4822025-11-20T17:59:58 *** cotsuka <cotsuka!~cotsuka@user/cotsuka> has quit IRC (Remote host closed the connection)
4832025-11-20T18:01:50 *** cotsuka <cotsuka!~cotsuka@user/cotsuka> has joined #bitcoin-core-dev
4842025-11-20T18:01:52 *** PaperSword <PaperSword!~Thunderbi@securemail.qrsnap.io> has quit IRC (Quit: PaperSword)
4852025-11-20T18:05:55 *** PaperSword <PaperSword!~Thunderbi@securemail.qrsnap.io> has joined #bitcoin-core-dev
4862025-11-20T18:11:05 <PaperSword> Is there any reason why Bitcoin Core does not have an RPC to view debug.log or logging of any kind?
4872025-11-20T18:21:30 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
4882025-11-20T18:43:13 <bitcoin-git> [bitcoin] Sjors closed pull request #33890: mining: add requestedOutputs field, e.g. for merged mining (master...2025/11/requested-outputs) https://github.com/bitcoin/bitcoin/pull/33890
4892025-11-20T18:59:38 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
4902025-11-20T19:00:05 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
4912025-11-20T19:04:59 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has quit IRC (Quit: Client closed)
4922025-11-20T19:16:35 <sipa> PaperSword: "nobody added one"... but i think part of why not is probably a long-standing desire not to put functionality in RPCs that can be implemented outside Bitcoin Core entirely
4932025-11-20T19:18:07 <PaperSword> Okay here is my reasoning.
4942025-11-20T19:18:08 <PaperSword> Lets say I have a node where I do not have user access to the file system (docker) but want to introspect poor block acceptance performance.
4952025-11-20T19:18:27 <PaperSword> It would be very nice to call an RPC that would dump my logs
4962025-11-20T19:18:32 *** justache- is now known as justache
4972025-11-20T19:24:09 <sliv3r__> PaperSword: Why you would not have access to the docker file system?
4982025-11-20T19:31:21 *** enochazariah <enochazariah!~enochazar@user/enochazariah> has quit IRC (Quit: Client closed)
4992025-11-20T19:44:41 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
5002025-11-20T20:01:10 *** Talkless <Talkless!~Talkless@138.199.6.197> has quit IRC (Quit: Konversation terminated!)
5012025-11-20T20:03:47 <instagibbs> printtoconsole=1, docker logs?
5022025-11-20T20:46:10 <laanwj> it's just a text file, there's tons of browsers and analyzers for that. also the idea has been floated in the past to store a circular buffer of log messages in memory which could be queried, this could also give access to messages that are too low prio to get written to disk (for more detailed troubleshooting in the case of a problem). but it's never been implemented and i'm not sure the complexity is worth it
5032025-11-20T20:47:03 *** jerryf <jerryf!~jerryf@user/jerryf> has quit IRC (Remote host closed the connection)
5042025-11-20T20:47:21 *** jerryf <jerryf!~jerryf@user/jerryf> has joined #bitcoin-core-dev
5052025-11-20T20:47:50 <bitcoin-git> [bitcoin] willcl-ark reopened pull request #33514: Clear out space on CentOS, depends, gui GHA job (master...centos-space-fix) https://github.com/bitcoin/bitcoin/pull/33514
5062025-11-20T20:55:35 *** dzxzg <dzxzg!~dzxzg@user/dzxzg> has joined #bitcoin-core-dev
5072025-11-20T20:57:44 *** justache <justache!~justache@user/justache> has quit IRC (Quit: ZNC 1.9.1 - https://znc.in)
5082025-11-20T21:00:08 *** justache <justache!~justache@user/justache> has joined #bitcoin-core-dev
5092025-11-20T21:14:49 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
5102025-11-20T21:15:17 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
5112025-11-20T21:22:15 *** choochaa <choochaa!~choocha@user/choochaa> has quit IRC (Quit: The Lounge - https://thelounge.chat)
5122025-11-20T21:26:42 *** choochaa <choochaa!~choocha@user/choochaa> has joined #bitcoin-core-dev
5132025-11-20T21:39:02 <bitcoin-git> [bitcoin] maflcko opened pull request #33919: ci: Run GUI unit tests in cross-Windows task (master...2511-ci-win-cross-gui-unit-test) https://github.com/bitcoin/bitcoin/pull/33919
5142025-11-20T21:44:27 <PaperSword> instagibs: I am not a sudo user on this host and only have access via RPC username:pass
5152025-11-20T21:47:40 <fanquake> PaperSword: it sounds like the admin should surface this for you then. Assuming they want to make it available
5162025-11-20T21:48:41 <bitcoin-git> [bitcoin] hebasto pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6b2d17b13220...17072f70051d
5172025-11-20T21:48:42 <bitcoin-git> bitcoin/master fad0c76 MarcoFalke: clang-format: Set PackConstructorInitializers: CurrentLine
5182025-11-20T21:48:42 <bitcoin-git> bitcoin/master 17072f7 Hennadii Stepanov: Merge bitcoin/bitcoin#33912: clang-format: Set PackConstructorInitializers...
5192025-11-20T21:48:43 <bitcoin-git> [bitcoin] hebasto merged pull request #33912: clang-format: Set PackConstructorInitializers: CurrentLine (master...2511-clang-format-PackConstructorInitializers) https://github.com/bitcoin/bitcoin/pull/33912
5202025-11-20T21:48:59 <PaperSword> it sounds like I should surface a PR for fun
5212025-11-20T21:49:25 <PaperSword> A symlink could work here too
5222025-11-20T22:06:21 <dzxzg> PaperSword: just curious how people are using RPC remotely, are you aware of the issues discussed here: https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md#security / in #32274
5232025-11-20T22:06:22 <corebot> https://github.com/bitcoin/bitcoin/issues/32274 | [RFC] What security expectations does/should the RPC server have from credentialed RPC clients? · Issue #32274 · bitcoin/bitcoin · GitHub
5242025-11-20T22:07:49 <dzxzg> I can't think of anything, but there might be a way to trick a node into spitting out it's debug.log over rpc.
5252025-11-20T22:08:17 <PaperSword> Even a ZMQ stream would be very usefull
5262025-11-20T22:09:16 <PaperSword> @dzxzg, I don't seem to be making any huge mistakes in terms of the security recommendations.
5272025-11-20T22:10:27 <PaperSword> ZMG aggregation would also be nice for setups with multiple nodes like a pool to to have a central monitoring service
5282025-11-20T22:12:56 *** choochaa6 <choochaa6!~choocha@user/choochaa> has joined #bitcoin-core-dev
5292025-11-20T22:13:23 *** choochaa <choochaa!~choocha@user/choochaa> has quit IRC (Remote host closed the connection)
5302025-11-20T22:13:23 *** choochaa6 is now known as choochaa
5312025-11-20T22:14:07 <dzxzg> I just meant that you should assume that a remote RPC user has the same permissions as `bitcoind` on the machine.
5322025-11-20T22:19:53 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
5332025-11-20T22:20:17 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
5342025-11-20T22:29:29 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
5352025-11-20T22:29:47 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
5362025-11-20T22:33:36 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has quit IRC (Quit: Leaving)
5372025-11-20T23:03:07 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
5382025-11-20T23:03:25 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
5392025-11-20T23:27:44 <dzxzg> maybe I don't understand the scenario well enough, but given that, why not provide ssh access to the user that's running bitcoind?
5402025-11-20T23:36:35 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
5412025-11-20T23:41:55 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
5422025-11-20T23:44:42 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Client Quit)
5432025-11-20T23:53:40 <bitcoin-git> [bitcoin] fjahr opened pull request #33920: Export embedded ASMap RPC (master...2025-11-asmap-export) https://github.com/bitcoin/bitcoin/pull/33920
5442025-11-20T23:54:19 <fjahr> ^ created a simple draft of this because it came up in discussion a few times now