12025-12-04T00:23:55 *** nejos97 <nejos97!~nejos97@user/nejos97> has joined #bitcoin-core-dev
22025-12-04T00:25:44 *** adys <adys!~adys@149.106.235.56> has joined #bitcoin-core-dev
32025-12-04T00:25:56 *** szkl <szkl!uid110435@id-110435.uxbridge.irccloud.com> has joined #bitcoin-core-dev
42025-12-04T00:28:13 *** nejos97 <nejos97!~nejos97@user/nejos97> has quit IRC (Ping timeout: 260 seconds)
52025-12-04T00:44:24 *** _flood <_flood!~flooded@154.47.22.66> has quit IRC (Remote host closed the connection)
62025-12-04T00:44:48 *** _flood <_flood!~flooded@154.47.22.66> has joined #bitcoin-core-dev
72025-12-04T01:34:57 *** saturday- <saturday-!~saturday7@65.181.3.125> has quit IRC (Quit: ZNC 1.10.1 - https://znc.in)
82025-12-04T01:40:52 *** saturday7 <saturday7!~saturday7@65.181.3.125> has joined #bitcoin-core-dev
92025-12-04T01:48:09 *** kevkevin_ <kevkevin_!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
102025-12-04T02:05:00 *** nejos97 <nejos97!~nejos97@user/nejos97> has joined #bitcoin-core-dev
112025-12-04T02:12:09 *** nejos97 <nejos97!~nejos97@user/nejos97> has quit IRC (Ping timeout: 252 seconds)
122025-12-04T02:30:24 *** justache <justache!~justache@user/justache> has quit IRC (Read error: Connection reset by peer)
132025-12-04T02:31:06 *** justache <justache!~justache@user/justache> has joined #bitcoin-core-dev
142025-12-04T02:36:14 *** dzxzg2 <dzxzg2!~dzxzg@user/dzxzg> has quit IRC (Remote host closed the connection)
152025-12-04T02:40:52 *** _flood <_flood!~flooded@154.47.22.66> has quit IRC (Remote host closed the connection)
162025-12-04T02:41:16 *** _flood <_flood!~flooded@154.47.22.66> has joined #bitcoin-core-dev
172025-12-04T02:48:49 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
182025-12-04T03:23:45 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
192025-12-04T03:25:13 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
202025-12-04T03:25:18 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
212025-12-04T03:29:37 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has quit IRC (Ping timeout: 246 seconds)
222025-12-04T04:08:43 *** flag <flag!~flag@81.56.46.144> has quit IRC (Ping timeout: 260 seconds)
232025-12-04T04:10:15 *** flag <flag!~flag@81.56.46.144> has joined #bitcoin-core-dev
242025-12-04T04:24:02 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
252025-12-04T04:26:00 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
262025-12-04T04:28:09 *** brunoer__ <brunoer__!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
272025-12-04T04:28:30 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has quit IRC (Ping timeout: 244 seconds)
282025-12-04T04:28:37 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
292025-12-04T04:37:23 *** _flood <_flood!~flooded@154.47.22.66> has quit IRC (Remote host closed the connection)
302025-12-04T04:37:46 *** _flood <_flood!~flooded@154.47.22.66> has joined #bitcoin-core-dev
312025-12-04T04:39:38 *** brunoer__ <brunoer__!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
322025-12-04T04:39:44 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
332025-12-04T04:41:23 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
342025-12-04T04:41:29 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
352025-12-04T04:42:53 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
362025-12-04T04:42:59 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
372025-12-04T04:45:07 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
382025-12-04T04:45:13 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
392025-12-04T04:46:38 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
402025-12-04T04:46:44 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
412025-12-04T04:48:22 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
422025-12-04T04:48:27 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
432025-12-04T04:49:47 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
442025-12-04T04:49:52 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
452025-12-04T04:51:25 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
462025-12-04T04:51:31 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
472025-12-04T04:53:05 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
482025-12-04T04:53:11 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
492025-12-04T04:54:46 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
502025-12-04T04:54:52 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
512025-12-04T04:56:24 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
522025-12-04T04:56:26 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
532025-12-04T04:59:38 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
542025-12-04T05:01:00 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has quit IRC (Ping timeout: 252 seconds)
552025-12-04T05:01:01 *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
562025-12-04T05:01:19 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
572025-12-04T05:01:31 *** cmirror <cmirror!~cmirror@4.53.92.114> has joined #bitcoin-core-dev
582025-12-04T05:01:51 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
592025-12-04T05:03:27 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
602025-12-04T05:03:32 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
612025-12-04T05:07:36 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
622025-12-04T05:07:42 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
632025-12-04T05:08:16 <bitcoin-git> [bitcoin] Ataraxia009 closed pull request #33813: init: Changing the rpcbind argument being ignored to a pop up warning (master...rpc-bind-warning) https://github.com/bitcoin/bitcoin/pull/33813
642025-12-04T05:12:35 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
652025-12-04T05:12:40 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
662025-12-04T05:16:58 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
672025-12-04T05:17:04 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
682025-12-04T05:18:36 *** Guest35 <Guest35!~Guest35@2607:fa49:1940:8200:c958:535b:5462:796d> has joined #bitcoin-core-dev
692025-12-04T05:20:01 *** Guest35 <Guest35!~Guest35@2607:fa49:1940:8200:c958:535b:5462:796d> has quit IRC (Write error: Broken pipe)
702025-12-04T05:24:52 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
712025-12-04T05:24:58 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
722025-12-04T05:26:28 *** brunoerg_ <brunoerg_!~brunoerg@102.117.224.239> has quit IRC (Read error: Connection reset by peer)
732025-12-04T05:26:34 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has joined #bitcoin-core-dev
742025-12-04T05:35:56 *** _flood <_flood!~flooded@154.47.22.66> has quit IRC (Remote host closed the connection)
752025-12-04T05:36:17 *** _flood <_flood!~flooded@154.47.22.66> has joined #bitcoin-core-dev
762025-12-04T05:46:41 *** szarka <szarka!~szarka@2603:3003:4eac:100:1e3:e1ee:cc3b:64cb> has quit IRC (Quit: Leaving)
772025-12-04T05:54:38 *** robobub <robobub!uid248673@id-248673.uxbridge.irccloud.com> has joined #bitcoin-core-dev
782025-12-04T05:55:52 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
792025-12-04T06:12:13 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
802025-12-04T06:16:35 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 240 seconds)
812025-12-04T06:30:19 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
822025-12-04T06:33:52 *** _flood <_flood!~flooded@154.47.22.66> has quit IRC (Remote host closed the connection)
832025-12-04T06:34:16 *** _flood <_flood!~flooded@154.47.22.66> has joined #bitcoin-core-dev
842025-12-04T06:53:02 *** brunoerg <brunoerg!~brunoerg@102.117.224.239> has quit IRC (Remote host closed the connection)
852025-12-04T06:55:07 *** Palaver <Palaver!~Palaver@76.32.213.31> has joined #bitcoin-core-dev
862025-12-04T06:55:48 *** Palaver <Palaver!~Palaver@76.32.213.31> has quit IRC (Remote host closed the connection)
872025-12-04T07:08:20 *** brunoerg <brunoerg!~brunoerg@197.224.203.136> has joined #bitcoin-core-dev
882025-12-04T07:12:42 *** brunoerg <brunoerg!~brunoerg@197.224.203.136> has quit IRC (Ping timeout: 244 seconds)
892025-12-04T07:28:14 *** javi404 <javi404!~quassel@2601:58b:4a81:a8e1:b24f:e2dd:b79f:9c95> has quit IRC (Ping timeout: 260 seconds)
902025-12-04T07:30:48 *** javi404 <javi404!~quassel@2601:58b:4a81:a8e1:b24f:e2dd:b79f:9c95> has joined #bitcoin-core-dev
912025-12-04T07:32:37 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 255 seconds)
922025-12-04T07:39:58 *** brunoerg <brunoerg!~brunoerg@197.224.203.136> has joined #bitcoin-core-dev
932025-12-04T07:44:40 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
942025-12-04T07:45:30 *** brunoerg_ <brunoerg_!~brunoerg@197.224.203.136> has joined #bitcoin-core-dev
952025-12-04T07:45:37 *** brunoerg <brunoerg!~brunoerg@197.224.203.136> has quit IRC (Ping timeout: 264 seconds)
962025-12-04T07:46:53 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
972025-12-04T07:56:33 *** brunoerg <brunoerg!~brunoerg@197.224.203.136> has joined #bitcoin-core-dev
982025-12-04T07:56:49 *** brunoerg_ <brunoerg_!~brunoerg@197.224.203.136> has quit IRC (Ping timeout: 260 seconds)
992025-12-04T07:59:47 *** brunoerg_ <brunoerg_!~brunoerg@197.224.203.136> has joined #bitcoin-core-dev
1002025-12-04T08:01:49 *** brunoerg <brunoerg!~brunoerg@197.224.203.136> has quit IRC (Ping timeout: 264 seconds)
1012025-12-04T08:04:32 *** brunoerg_ <brunoerg_!~brunoerg@197.224.203.136> has quit IRC (Ping timeout: 240 seconds)
1022025-12-04T08:08:19 *** brunoerg <brunoerg!~brunoerg@197.224.203.136> has joined #bitcoin-core-dev
1032025-12-04T08:10:46 *** brunoerg_ <brunoerg_!~brunoerg@197.224.203.136> has joined #bitcoin-core-dev
1042025-12-04T08:12:25 *** brunoerg <brunoerg!~brunoerg@197.224.203.136> has quit IRC (Ping timeout: 245 seconds)
1052025-12-04T08:16:29 *** brunoerg <brunoerg!~brunoerg@197.224.203.136> has joined #bitcoin-core-dev
1062025-12-04T08:16:58 *** brunoerg_ <brunoerg_!~brunoerg@197.224.203.136> has quit IRC (Ping timeout: 246 seconds)
1072025-12-04T08:22:13 *** brunoerg <brunoerg!~brunoerg@197.224.203.136> has quit IRC (Ping timeout: 264 seconds)
1082025-12-04T08:22:33 *** brunoerg <brunoerg!~brunoerg@102.117.230.18> has joined #bitcoin-core-dev
1092025-12-04T08:34:02 *** brunoerg <brunoerg!~brunoerg@102.117.230.18> has quit IRC (Remote host closed the connection)
1102025-12-04T08:41:03 *** f321x <f321x!~f321x@user/f321x> has joined #bitcoin-core-dev
1112025-12-04T08:49:13 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 264 seconds)
1122025-12-04T08:52:38 *** brunoerg <brunoerg!~brunoerg@102.117.230.18> has joined #bitcoin-core-dev
1132025-12-04T08:54:43 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
1142025-12-04T08:57:13 *** brunoerg <brunoerg!~brunoerg@102.117.230.18> has quit IRC (Ping timeout: 255 seconds)
1152025-12-04T09:02:14 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1162025-12-04T09:24:19 *** BGL <BGL!eighty@75.149.171.58> has quit IRC (Ping timeout: 260 seconds)
1172025-12-04T09:31:37 *** janb84 <janb84!~janb84@user/janb84> has quit IRC (Ping timeout: 250 seconds)
1182025-12-04T09:33:27 *** janb84 <janb84!~janb84@user/janb84> has joined #bitcoin-core-dev
1192025-12-04T09:47:46 <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/9a29b2d331ee...ad452a1e655e
1202025-12-04T09:47:47 <bitcoin-git> bitcoin/master e753fad glozow: [wallet] never try to spend from unconfirmed TRUC that already has ancesto...
1212025-12-04T09:47:47 <bitcoin-git> bitcoin/master dcd42d6 glozow: [test] wallet send 3 generation TRUC
1222025-12-04T09:47:47 <bitcoin-git> bitcoin/master ad452a1 merge-script: Merge bitcoin/bitcoin#33528: wallet: don't consider unconfirmed TRUC coins...
1232025-12-04T09:47:48 <bitcoin-git> [bitcoin] fanquake merged pull request #33528: wallet: don't consider unconfirmed TRUC coins with ancestors (master...2025-09-send) https://github.com/bitcoin/bitcoin/pull/33528
1242025-12-04T09:50:46 <bitcoin-git> [bitcoin] rustaceanrob opened pull request #34004: Implementation of SwiftSync (master...swiftsync-v0) https://github.com/bitcoin/bitcoin/pull/34004
1252025-12-04T09:52:34 *** robobub <robobub!uid248673@id-248673.uxbridge.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
1262025-12-04T10:04:49 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 264 seconds)
1272025-12-04T10:06:26 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev (Closing Window)
1282025-12-04T10:11:24 <janb84> Codeberg is having some issues :/ guix builds impacted
1292025-12-04T10:18:52 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1302025-12-04T10:30:30 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
1312025-12-04T10:31:02 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1322025-12-04T10:32:10 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
1332025-12-04T10:32:44 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
1342025-12-04T10:45:30 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
1352025-12-04T10:46:02 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1362025-12-04T10:47:06 <fanquake> dergoegge / maflcko: fyi our oss-fuzz build likely to get moved to 24.04 in https://github.com/google/oss-fuzz/pull/14407
1372025-12-04T10:48:23 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (*.net *.split)
1382025-12-04T10:48:24 *** f321x <f321x!~f321x@user/f321x> has quit IRC (*.net *.split)
1392025-12-04T10:48:24 *** afiore <afiore!~afiore@user/afiore> has quit IRC (*.net *.split)
1402025-12-04T10:48:24 *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has quit IRC (*.net *.split)
1412025-12-04T10:48:24 *** vasild <vasild!~vd@user/vasild> has quit IRC (*.net *.split)
1422025-12-04T10:48:24 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has quit IRC (*.net *.split)
1432025-12-04T10:48:24 *** jerryf <jerryf!~jerryf@user/jerryf> has quit IRC (*.net *.split)
1442025-12-04T10:53:48 <dergoegge> fanquake: I wouldn't expect any issues but let's see...
1452025-12-04T10:58:35 *** BGL <BGL!eighty@75.149.171.58> has joined #bitcoin-core-dev
1462025-12-04T11:05:31 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
1472025-12-04T11:07:30 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
1482025-12-04T11:30:30 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
1492025-12-04T11:36:28 *** brunoerg <brunoerg!~brunoerg@102.117.234.62> has joined #bitcoin-core-dev
1502025-12-04T11:45:31 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1512025-12-04T11:45:31 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
1522025-12-04T12:02:08 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1532025-12-04T12:04:38 <hebasto> laanwj: are you building on your risc-v cloud instance as root, or as a non-privileged user?
1542025-12-04T12:10:25 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 246 seconds)
1552025-12-04T12:23:26 *** _flood <_flood!~flooded@154.47.22.66> has quit IRC (Remote host closed the connection)
1562025-12-04T12:23:48 *** _flood <_flood!~flooded@154.47.22.66> has joined #bitcoin-core-dev
1572025-12-04T12:24:10 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1582025-12-04T12:25:10 *** brunoerg <brunoerg!~brunoerg@102.117.234.62> has quit IRC (Remote host closed the connection)
1592025-12-04T12:35:47 *** brunoerg <brunoerg!~brunoerg@102.117.234.62> has joined #bitcoin-core-dev
1602025-12-04T12:39:41 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
1612025-12-04T12:40:08 *** brunoerg <brunoerg!~brunoerg@102.117.234.62> has quit IRC (Ping timeout: 240 seconds)
1622025-12-04T12:49:27 <laanwj> hebasto: as a non-privileged user, i created a user gitian-build for it
1632025-12-04T12:50:31 <laanwj> sorry, brainfart, guix-build ofc
1642025-12-04T12:51:42 <hebasto> laanwj: so did I; have you experienced system hanging during the build process?
1652025-12-04T12:52:03 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
1662025-12-04T13:00:09 <laanwj> hebasto no hangs, no, but i did have memory corruption(?) at some point (#33873). system hangs could have been a possible outcome too. sadly their RISC-V cluster isn't too stable and reporting it didn't do anything, they just quoted their terms of service for labs that i couldn't sue them :)
1672025-12-04T13:00:10 <corebot> https://github.com/bitcoin/bitcoin/issues/33873 | guix build fails on RISC-V due to python-py-cpuinfo test failure · Issue #33873 · bitcoin/bitcoin · GitHub
1682025-12-04T13:02:29 <laanwj> thinking of getting one of those "T-Head Lichee Pi 4A 16GB Cluster FDT" (which they're, according to the bootloader, using) myself
1692025-12-04T13:03:03 <hebasto> ð
1702025-12-04T13:03:06 *** Earnestly <Earnestly!~earnest@user/earnestly> has quit IRC (Ping timeout: 244 seconds)
1712025-12-04T13:05:13 <hebasto> laanwj: perhaps, it makes sense to look for something that fits RVA23 profile? context: https://www.omgubuntu.co.uk/2025/06/ubuntu-riscv-rva23-support
1722025-12-04T13:08:43 <laanwj> hmm yes, thanks for linking that, i didn't know. that definitely complicates things
1732025-12-04T13:10:32 *** Earnestly <Earnestly!~earnest@user/earnestly> has joined #bitcoin-core-dev
1742025-12-04T13:18:00 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
1752025-12-04T13:22:48 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 265 seconds)
1762025-12-04T13:25:05 <laanwj> as i understand, rv64imafdcsu, as on their server, isn't even RVA20, let alone RVA23 (missing the fancy Zi* extensions)? what kind of devices is ubuntu aiming for, really, they seem to be getting far ahead of themselves
1772025-12-04T13:26:10 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 245 seconds)
1782025-12-04T13:30:07 <Sjors[m]1> Pre-meeting Stratum v2 workgroup update: would be nice to get #33965 reviewed and backported to v30.x.
1792025-12-04T13:30:09 <Sjors[m]1> I tested custom block templates with DMND pool and found some bugs, but they don't seem to be on our end.
1802025-12-04T13:30:11 <corebot> https://github.com/bitcoin/bitcoin/issues/33965 | mining: fix -blockreservedweight shadows IPC option by Sjors · Pull Request #33965 · bitcoin/bitcoin · GitHub
1812025-12-04T13:30:13 <bitcoin-git> [qa-assets] maflcko merged pull request #246: Add Murchâs inputs December 2025 (main...2025-12-murch-inputs) https://github.com/bitcoin-core/qa-assets/pull/246
1822025-12-04T13:30:15 <bitcoin-git> [qa-assets] maflcko pushed 2 commits to main: https://github.com/bitcoin-core/qa-assets/compare/6c8d24b0041e...b5ad78e070e4
1832025-12-04T13:30:15 <bitcoin-git> qa-assets/main ca40856 Murch: Add Murchâs inputs December 2025
1842025-12-04T13:30:16 <bitcoin-git> qa-assets/main b5ad78e maflcko: Merge pull request #246 from murchandamus/2025-12-murch-inputs
1852025-12-04T13:32:05 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1862025-12-04T13:37:15 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 240 seconds)
1872025-12-04T13:41:47 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
1882025-12-04T13:45:28 *** brunoerg <brunoerg!~brunoerg@102.117.234.62> has joined #bitcoin-core-dev
1892025-12-04T13:46:31 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 264 seconds)
1902025-12-04T13:52:12 <bitcoin-git> [bitcoin] hebasto pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/ad452a1e655e...9e02f7808909
1912025-12-04T13:52:13 <bitcoin-git> bitcoin/master ae2e438 Hennadii Stepanov: cmake: Move IPC tests to `ipc/test`
1922025-12-04T13:52:13 <bitcoin-git> bitcoin/master 866bbb9 Hennadii Stepanov: cmake, test: Improve locality of `bitcoin_ipc_test` library description
1932025-12-04T13:52:13 <bitcoin-git> bitcoin/master 9e02f78 Hennadii Stepanov: Merge bitcoin/bitcoin#33774: cmake: Move IPC tests to `ipc/test`
1942025-12-04T13:52:15 <bitcoin-git> [bitcoin] hebasto merged pull request #33774: cmake: Move IPC tests to `ipc/test` (master...251104-ipc-tests) https://github.com/bitcoin/bitcoin/pull/33774
1952025-12-04T14:01:54 <fjahr> Final reminder that the asmap file building will happen in 2 hours, just start it any time until then, there will be a countdown and it will do its thing while you are in the meeting: https://github.com/asmap/asmap-data/issues/36
1962025-12-04T14:06:24 <bitcoin-git> [bitcoin] l0rinc opened pull request #34005: util: generalize `util::Result` to support custom errors (master...l0rinc/generalized-Result-error) https://github.com/bitcoin/bitcoin/pull/34005
1972025-12-04T14:06:44 *** brunoerg <brunoerg!~brunoerg@102.117.234.62> has quit IRC (Remote host closed the connection)
1982025-12-04T14:11:53 <dergoegge> "Coordinated launch mode: Waiting until 1764864000" ð«¡
1992025-12-04T14:20:21 *** _flood <_flood!~flooded@154.47.22.66> has quit IRC (Remote host closed the connection)
2002025-12-04T14:20:47 *** _flood <_flood!~flooded@154.47.22.66> has joined #bitcoin-core-dev
2012025-12-04T14:24:53 *** _flood <_flood!~flooded@154.47.22.66> has quit IRC (Read error: Connection reset by peer)
2022025-12-04T14:25:24 *** _flood <_flood!~flooded@154.47.22.66> has joined #bitcoin-core-dev
2032025-12-04T14:26:45 <l0rinc> CoreCheck seems to be dead (i.e. pending for more than a day: https://corecheck.dev/bitcoin/bitcoin/pulls/33192), how do we fix it?
2042025-12-04T14:29:36 *** brunoerg <brunoerg!~brunoerg@102.117.234.62> has joined #bitcoin-core-dev
2052025-12-04T14:30:50 *** brunoerg <brunoerg!~brunoerg@102.117.234.62> has quit IRC (Read error: Connection reset by peer)
2062025-12-04T14:36:21 <bitcoin-git> [bitcoin] maflcko opened pull request #34006: Add util::Expected (std::expected) (master...2512-exp) https://github.com/bitcoin/bitcoin/pull/34006
2072025-12-04T14:37:58 <darosior> #proposedmeetingtopic an outbound connection selection strategy more resistant to eclipse attacks
2082025-12-04T14:41:58 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
2092025-12-04T14:58:27 *** afiore <afiore!~afiore@user/afiore> has joined #bitcoin-core-dev
2102025-12-04T14:58:49 *** f321x <f321x!~f321x@user/f321x> has joined #bitcoin-core-dev
2112025-12-04T15:00:52 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
2122025-12-04T15:01:01 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
2132025-12-04T15:01:04 *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
2142025-12-04T15:02:01 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has joined #bitcoin-core-dev
2152025-12-04T15:15:00 *** ghost43_ <ghost43_!~ghost43@gateway/tor-sasl/ghost43> has joined #bitcoin-core-dev
2162025-12-04T15:15:39 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has quit IRC (Remote host closed the connection)
2172025-12-04T15:17:03 *** jerryf <jerryf!~jerryf@user/jerryf> has joined #bitcoin-core-dev
2182025-12-04T15:19:55 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has joined #bitcoin-core-dev
2192025-12-04T15:27:52 *** kevkevin <kevkevin!~kevkevin@38.140.4.82> has joined #bitcoin-core-dev
2202025-12-04T15:30:32 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
2212025-12-04T15:34:35 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
2222025-12-04T15:34:57 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
2232025-12-04T15:35:06 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has quit IRC (Quit: Client closed)
2242025-12-04T15:36:30 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has joined #bitcoin-core-dev
2252025-12-04T15:40:34 *** Novo__ <Novo__!uid605808@id-605808.lymington.irccloud.com> has joined #bitcoin-core-dev
2262025-12-04T15:49:07 *** Guest89 <Guest89!~Guest89@73.43.65.14> has joined #bitcoin-core-dev
2272025-12-04T15:55:11 *** Guest89 <Guest89!~Guest89@73.43.65.14> has quit IRC (Ping timeout: 250 seconds)
2282025-12-04T15:58:36 *** Emc99 <Emc99!~Emc99@212.129.84.78> has joined #bitcoin-core-dev
2292025-12-04T15:59:29 *** dzxzg <dzxzg!~dzxzg@user/dzxzg> has joined #bitcoin-core-dev
2302025-12-04T16:00:11 <stickies-v> #startmeeting
2312025-12-04T16:00:11 <corebot> stickies-v: Meeting started at 2025-12-04T16:00+0000
2322025-12-04T16:00:12 <corebot> stickies-v: Current chairs: stickies-v
2332025-12-04T16:00:13 <corebot> stickies-v: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
2342025-12-04T16:00:14 <corebot> stickies-v: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
2352025-12-04T16:00:15 <corebot> stickies-v: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
2362025-12-04T16:00:18 <sedited> hi
2372025-12-04T16:00:20 <sipa> hi
2382025-12-04T16:00:24 <eugenesiegel> hi
2392025-12-04T16:00:24 <hodlinator> hi
2402025-12-04T16:00:29 <yancy> hi
2412025-12-04T16:00:31 <stickies-v> #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
2422025-12-04T16:00:31 <stickies-v> willcl-ark
2432025-12-04T16:00:38 <hebasto> hi
2442025-12-04T16:00:39 <furszy> hi
2452025-12-04T16:00:41 <kevkevin> hi
2462025-12-04T16:00:42 <stringintech> hi
2472025-12-04T16:00:44 <janb84> hi
2482025-12-04T16:00:52 <pinheadmz> hi
2492025-12-04T16:00:58 <instagibbs> hi
2502025-12-04T16:01:00 <dzxzg> hi
2512025-12-04T16:01:02 <stickies-v> There is one pre-proposed meeting topics this week. Any last minute ones to add?
2522025-12-04T16:01:06 <jonatack> hi
2532025-12-04T16:01:09 <fjahr> hi
2542025-12-04T16:01:25 <dergoegge> hi
2552025-12-04T16:01:56 <stickies-v> let's get started with the WG updates, please have your updates (or at least a brief acknowledgement) ready so I can quickly skip to the next group in case of absence
2562025-12-04T16:02:11 <darosior> hi
2572025-12-04T16:02:15 <stickies-v> no fuzzing updates today, so skipping that
2582025-12-04T16:02:22 <stickies-v> #topic Kernel WG Update (sedited)
2592025-12-04T16:02:38 <sedited> A bunch of PRs on the board waiting for review: https://github.com/orgs/bitcoin/projects/3
2602025-12-04T16:03:13 <sedited> that's all for today.
2612025-12-04T16:03:21 <l0rinc> hi
2622025-12-04T16:03:28 <marcofleon> hi
2632025-12-04T16:03:32 <vasild> hi
2642025-12-04T16:03:32 <lightlike> hi
2652025-12-04T16:03:53 <stickies-v> #topic Benchmarking WG Update (l0rinc, andrewtoth)
2662025-12-04T16:03:58 <l0rinc> Continuing the work in #31132, fuzzing and benchmarks now use real LevelDB in the background for extra realism.
2672025-12-04T16:04:03 <corebot> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads >40% faster IBD by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub
2682025-12-04T16:04:08 <l0rinc> We've also measured the peak memory usage during reindex-chainstate: so far, it seems that the memory overhead is measurable (almost 100MB peak extra).
2692025-12-04T16:04:14 *** andrewtoth <andrewtoth!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
2702025-12-04T16:04:15 <l0rinc> Once we're close to the finish line, we can discuss whether we should do anything about it (e.g., we could lower the default dbcache size or try to reduce memory usage in other ways to compensate).
2712025-12-04T16:04:22 <andrewtoth> hi
2722025-12-04T16:04:24 <l0rinc> We still have to gather thorough flame graphs to understand the new usage patterns and see where the new bottlenecks will be after the change. We're also comparing how SSD and HDD are affected by different concurrency levels - these take really long, we don't have definitive results yet.
2732025-12-04T16:04:35 <l0rinc> We've also investigated whether we could avoid complete memory reallocations during IBD (after sync we need to fully release the memory), but it seems to slow down IBD so much (up to 3x on some platforms). Most likely this is because it forces each block to flush after the first one, since we're in a constant critical memory state if we don't reallocate (it behaves the same if we completely remove the reallocation). We will investigate if this is
2742025-12-04T16:04:35 <l0rinc> because of the Pool Allocator introduced in #25325 and if it's still optimal to have it after the input fetching optimizations above.
2752025-12-04T16:04:37 <corebot> https://github.com/bitcoin/bitcoin/issues/25325 | Add pool based memory resource by martinus · Pull Request #25325 · bitcoin/bitcoin · GitHub
2762025-12-04T16:04:44 <l0rinc> Reviews and fuzzing are still welcome, and in the meantime #30442 and #33602 would help make some progress on the above.
2772025-12-04T16:04:46 <corebot> https://github.com/bitcoin/bitcoin/issues/30442 | precalculate SipHash constant salt XORs by l0rinc · Pull Request #30442 · bitcoin/bitcoin · GitHub
2782025-12-04T16:04:49 <corebot> https://github.com/bitcoin/bitcoin/issues/33602 | [IBD] coins: reduce lookups in dbcache layer propagation by l0rinc · Pull Request #33602 · bitcoin/bitcoin · GitHub
2792025-12-04T16:05:06 <l0rinc> andrewtoth: anything else I left out?
2802025-12-04T16:05:10 <Murch[m]> Is sedited the artist formerly known as TheCharlatan?
2812025-12-04T16:05:33 <sipa> Murch[m]: what would you expect from a definitive Charlatan?
2822025-12-04T16:06:09 <l0rinc> that's it from me
2832025-12-04T16:06:11 <andrewtoth> any review is welcome. I think it's in a good spot right now.
2842025-12-04T16:06:14 <abubakarsadiq> hi
2852025-12-04T16:06:19 *** cfields <cfields!~cfields@user/cfields> has joined #bitcoin-core-dev
2862025-12-04T16:06:22 <darosior> Murch[m]: looks like it yes :)
2872025-12-04T16:06:28 <stickies-v> nice, thank you for the comprehensive overview and continued work on this!
2882025-12-04T16:06:29 *** Guest89 <Guest89!~Guest89@73.43.65.14> has joined #bitcoin-core-dev
2892025-12-04T16:06:33 <stickies-v> #topic Silent Payments WG Update (Novo__)
2902025-12-04T16:07:27 <sipa> not really a workgroup member, but i note this relevant ML discussion: https://groups.google.com/g/bitcoindev/c/bP6ktUyCOJI
2912025-12-04T16:07:30 *** brunoerg <brunoerg!~brunoerg@102.117.234.62> has joined #bitcoin-core-dev
2922025-12-04T16:08:16 <brunoerg> hi
2932025-12-04T16:08:35 <stickies-v> thanks sipa! we haven't had updates from the SP WG in quite a while so I suggest archiving this WG until one of the champions requests to activate again. lmk if anyone doesn't agree with this
2942025-12-04T16:08:44 <stickies-v> #topic Cluster Mempool WG Update (sdaftuar, sipa)
2952025-12-04T16:08:47 <sipa> Cluster mempool followups (33591) were merged, i'd encourage anyone to run with it, play around with the new RPCs, see if logging makes sense, etc. Next up for review is my #32545, which may end up being split into multiple PRs based on review.
2962025-12-04T16:08:50 <corebot> https://github.com/bitcoin/bitcoin/issues/32545 | Replace cluster linearization algorithm with SFL by sipa · Pull Request #32545 · bitcoin/bitcoin · GitHub
2972025-12-04T16:09:15 <abubakarsadiq> From Novo__I have rebased https://github.com/bitcoin/bitcoin/pull/32966 so it now tracks https://github.com/bitcoin-core/secp256k1/pull/1765. https://github.com/bitcoin-core/secp256k1/pull/1765 still needs review. The biggest issue is the worst case scanning performance, theStack and W0xlt have produced working solutions with tradeoffs that are being verified by benchmarks. Reviews are welcome!
2982025-12-04T16:09:18 <Murch[m]> Congrats!
2992025-12-04T16:10:13 *** andrewtoth <andrewtoth!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
3002025-12-04T16:10:18 <stickies-v> whoever's going to write the v31 testing guide should have a lot of fun with cluster mempool stuff
3012025-12-04T16:10:27 <instagibbs> I have a couple PRs I think should be in 31: #33892 and #33616
3022025-12-04T16:10:29 <corebot> https://github.com/bitcoin/bitcoin/issues/33892 | policy: Remove individual transaction <minrelay restriction by instagibbs · Pull Request #33892 · bitcoin/bitcoin · GitHub
3032025-12-04T16:10:31 <corebot> https://github.com/bitcoin/bitcoin/issues/33616 | policy: don't CheckEphemeralSpends on reorg by instagibbs · Pull Request #33616 · bitcoin/bitcoin · GitHub
3042025-12-04T16:10:42 <lightlike> sipa has connection problems, but that's it from him.
3052025-12-04T16:11:06 <stickies-v> I don't have permissions to set milestones but hopefully someone who does can update that for instagibbs ?
3062025-12-04T16:11:37 <stickies-v> sorry, i've been told milestones are already on there.
3072025-12-04T16:11:49 <dergoegge> #proposedmeetingtopic why is #33723 not merged yet
3082025-12-04T16:11:49 <corebot> dergoegge: Unknown command: #proposedmeetingtopic
3092025-12-04T16:11:51 <instagibbs> :) just speaking up in case people want to review smaller prs
3102025-12-04T16:11:51 <corebot> https://github.com/bitcoin/bitcoin/issues/33723 | chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us by SatsAndSports · Pull Request #33723 · bitcoin/bitcoin · GitHub
3112025-12-04T16:11:55 <stickies-v> #topic Stratum v2 WG Update (sjors)
3122025-12-04T16:12:02 *** sipa <sipa!~pw@user/sipa> has quit IRC (Read error: Connection reset by peer)
3132025-12-04T16:12:12 *** sipa <sipa!~pw@user/sipa> has joined #bitcoin-core-dev
3142025-12-04T16:12:25 <darosior> meta point: if stickies-v is going to run meetings regularly it'd make sense that he has triage permission on the Github repo
3152025-12-04T16:12:31 *** jerryf <jerryf!~jerryf@user/jerryf> has quit IRC (Remote host closed the connection)
3162025-12-04T16:12:50 *** jerryf <jerryf!~jerryf@user/jerryf> has joined #bitcoin-core-dev
3172025-12-04T16:13:01 <sipa> hi
3182025-12-04T16:13:21 <cfields> +1
3192025-12-04T16:13:41 <stickies-v> #topic Net Split WG Update (cfields)
3202025-12-04T16:14:02 *** andrewtoth <andrewtoth!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
3212025-12-04T16:14:13 <cfields> Continuing to work on the initial PR to move some things into Peer. Got some nice feedback from AJ on the meta issue (#33958) that I'm working on a response to as well. That's about it, not much to see yet.
3222025-12-04T16:14:14 <corebot> https://github.com/bitcoin/bitcoin/issues/33958 | Net split meta issue · Issue #33958 · bitcoin/bitcoin · GitHub
3232025-12-04T16:15:04 <_aj_> (in working on that response, i finally got the bip324 short message type update idea from 3 years ago implemented which had been in my backlog)
3242025-12-04T16:15:29 <b10c> hi
3252025-12-04T16:15:40 <cfields> ð
3262025-12-04T16:16:13 <stickies-v> #topic A short update on BIP 54 / Consensus Cleanup work (darosior)
3272025-12-04T16:17:17 <darosior> Not a Bitcoin Core specific topic, but one that i think could be interesting to people here. As you know i've been working on the Consensus Cleanup proposal for over two years now. After Matt's previous attempt in 2019, i spent the end of 2023 and much of 2024 researching the best mitigations for each issue. We published a BIP in early 2025, and
3282025-12-04T16:17:17 <darosior> there is now an implementation for review at Bitcoin Inquisition.
3292025-12-04T16:17:56 <darosior> The test vectors were also recently merged in the BIP repository
3302025-12-04T16:17:59 <Murch[m]> Great, what do you see as the next steps?
3312025-12-04T16:18:12 <stickies-v> https://github.com/bitcoin-inquisition/bitcoin/pull/99
3322025-12-04T16:18:24 <darosior> So if anybody is interested in helping moving things forward, this is getting to the stage where i could use more eyes on the implementation
3332025-12-04T16:18:57 <dergoegge> Why in inquisition and not in the main repo?
3342025-12-04T16:19:48 <darosior> Because i want to run it on a test network for a while first, and Bitcoin Inquisition being a testbed for consensus changes seemed the appropriate place for now
3352025-12-04T16:20:23 <darosior> We can get it into inquisition, play with it for a couple months on signet, and possibly then consider a PR to the main Bitcoin Core repo
3362025-12-04T16:20:25 <dergoegge> So if the spec changes due to review on the main repo, we'll have to redo all of that?
3372025-12-04T16:20:46 <darosior> But that's the first stage of an implementation, so feel free to nitpick/bikeshed it to death!
3382025-12-04T16:20:54 <Murch[m]> I am just looking at the Inquisition PR. Somehow I expected it to be less than ~27k lines of code. ;)
3392025-12-04T16:20:54 <Murch[m]> How much of that is tests?
3402025-12-04T16:21:02 <darosior> dergoegge: i very much don't expect the spec to change at this point
3412025-12-04T16:21:08 <fanquake> _aj_: can you approve the CI to run in that PR?
3422025-12-04T16:21:25 <darosior> dergoegge: The spec has been researched / designed / debated to death for more than 2 years now
3432025-12-04T16:21:31 <instagibbs> Murch[m] its also including Simplicity (joke joke)
3442025-12-04T16:21:40 <stickies-v> i also don't think inquisition necessarily needs to be redone if the spec changes, depends on the circumstances if that makes sense?
3452025-12-04T16:21:41 <_aj_> fanquake: done
3462025-12-04T16:21:41 <darosior> Of course it can always happen but i don't think it's likely
3472025-12-04T16:21:56 <darosior> Murch[m]: 99.9%
3482025-12-04T16:22:01 <dergoegge> the code might change in significant ways as well
3492025-12-04T16:22:10 <darosior> The consensus changes are something like 10 lines
3502025-12-04T16:22:24 <Murch[m]> Yeah, thatâs what I was expecting :)
3512025-12-04T16:22:26 <sedited> darosior, is the preparatory PR relevant for the upstream repo too?
3522025-12-04T16:22:26 <dergoegge> I just don't see why or how this became part of the process
3532025-12-04T16:22:35 <darosior> dergoegge: between inquisition and main Core repo? I don't think so
3542025-12-04T16:23:57 <darosior> sedited: i don't expect the relevant code to change much between Inquisition and upstream, so yes it is relevant
3552025-12-04T16:24:06 <dergoegge> I think the review should happen on the main repo, you can still deploy the PR where ever you want
3562025-12-04T16:24:10 <fanquake> How many major versions is inquisition lagging behind master at the moment?
3572025-12-04T16:24:18 <darosior> dergoegge: why?
3582025-12-04T16:24:25 <sedited> would it make sense to PR that then in the meantime?
3592025-12-04T16:24:29 <darosior> fanquake: a single one, it's on 29
3602025-12-04T16:24:55 <fanquake> darosior: right, so 1 version + any current changes (like cluster etc)
3612025-12-04T16:25:01 <darosior> I don't think there is any need to rush anything with a PR to the main repo
3622025-12-04T16:25:28 <dergoegge> I'm not saying merge the PR just review
3632025-12-04T16:25:30 <darosior> fanquake: yes, but that shouldn't be relevant
3642025-12-04T16:25:59 * darosior shrugs
3652025-12-04T16:26:31 <darosior> I can also PR to the main repo, if people really feel so strongly about not coming review stuff in Inquisition
3662025-12-04T16:26:40 <dergoegge> wouldn't you want the visibility of the main repo for review?
3672025-12-04T16:26:52 <dergoegge> I'm not gonna review the inquisition PR
3682025-12-04T16:27:04 <darosior> Ok, does anyone else feel like dergoegge?
3692025-12-04T16:27:17 <darosior> Glad i brought it up, i didn't expect this
3702025-12-04T16:27:43 <_aj_> is there any particular problem with reviewing code in different repos? we already have gui, eg
3712025-12-04T16:27:49 <stickies-v> isn't it fine to merge on inquisition with less review, and then do the actual review on main - just to have some signet data available as extra information?
3722025-12-04T16:27:50 <dergoegge> it's been open for more than a month there and there's been basically no review
3732025-12-04T16:27:58 <darosior> And cmake, which was the main annoyance before the 29 rebase of inquisition
3742025-12-04T16:28:49 <darosior> stickies-v: that's what i'm looking for yes
3752025-12-04T16:29:08 <dergoegge> I don't think consensus changes should be reviewed elsewhere. What would be the reason for that?
3762025-12-04T16:29:42 <_aj_> dergoegge: are you assuming it won't get further review when PRed for core?
3772025-12-04T16:29:46 <darosior> Are we going to go into a discussion about the raison d'etre of Inquisition?
3782025-12-04T16:30:00 <dergoegge> i don speak french
3792025-12-04T16:30:06 <sedited> :D
3802025-12-04T16:30:28 <fjahr> dergoegge: for many changes the rebasing is annoying here, nobody is stopping anyone from reviewing on inquisition
3812025-12-04T16:30:41 <stickies-v> is anyone arguing for less review on the main repo? i don't think so?
3822025-12-04T16:30:52 <darosior> For the record, here is the rationale behind Inquisition https://gnusha.org/pi/bitcoindev/YyQioS3F942wu1HW@erisian.com.au/
3832025-12-04T16:31:13 <jonatack> darosior: je ne vois pas de souci de faire un premier tour de review sur inquistion puis un second tour de review dans le repo de bitcoin core
3842025-12-04T16:31:27 <dergoegge> fjahr: I'm guessing people just aren't aware
3852025-12-04T16:31:28 <jonatack> ca se cumule de toute facon :)
3862025-12-04T16:31:30 <stickies-v> okay let's keep it english on here please
3872025-12-04T16:31:31 <sipa> ah bon baguette
3882025-12-04T16:31:39 <darosior> Alright, i think i got across what i wanted to
3892025-12-04T16:32:02 <darosior> Just a heads up to people that there is code for review at Inquisition, if you are interested in having a look
3902025-12-04T16:32:14 <stickies-v> thanks darosior!
3912025-12-04T16:32:17 <darosior> I may open a PR to the Bitcoin Core main repo later on
3922025-12-04T16:32:23 <darosior> Meanwhile, that's where the action is
3932025-12-04T16:32:40 <darosior> jonatack: yes that's what i'm looking for :)
3942025-12-04T16:33:02 <stickies-v> #topic why is #33723 not merged yet (dergoegge)
3952025-12-04T16:33:04 <corebot> https://github.com/bitcoin/bitcoin/issues/33723 | chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us by SatsAndSports · Pull Request #33723 · bitcoin/bitcoin · GitHub
3962025-12-04T16:33:45 <dergoegge> (topic seems self explanatory)
3972025-12-04T16:34:41 <stickies-v> it does look like there is pretty overwhelming support for the change, and sufficient time for feedback/recourse?
3982025-12-04T16:35:18 <sipa> indeed
3992025-12-04T16:35:21 <sedited> have changes to the seed list been backported historically?
4002025-12-04T16:36:12 <sipa> i haven't commented myself, because as a DNS seed operator myself i feel sort of conflicted, but i do agree it looks like support for the change is overwhelming
4012025-12-04T16:37:09 <fjahr> I guess under normal circumstances the runner of the seed would be contacted and asked for a statement. Did anyone try to reach out? (I haven't looked at this at all)
4022025-12-04T16:37:34 <fanquake> sedited: I think if the rationale for removing it holds, it holds the same for all maintained branchs
4032025-12-04T16:37:43 <instagibbs> Luke hasn't seemed to weigh in, could ping him now that it's unlocked again, and give a timeline?
4042025-12-04T16:37:56 <stickies-v> sedited: it looks like #29691 was backported
4052025-12-04T16:37:59 <corebot> https://github.com/bitcoin/bitcoin/issues/29691 | Change Luke Dashjr seed to dashjr-list-of-p2p-nodes.us by luke-jr · Pull Request #29691 · bitcoin/bitcoin · GitHub
4062025-12-04T16:38:03 <dergoegge> he weighed in on the issue
4072025-12-04T16:38:08 <fjahr> Just like: Are you planning to fix this? And if there is no response this schould really be good to go
4082025-12-04T16:38:24 <fanquake> he already weighed in: https://github.com/bitcoin/bitcoin/issues/33734#issuecomment-3483326655
4092025-12-04T16:38:34 <dergoegge> it's also not about the seed not working properly, it's about trust.
4102025-12-04T16:38:41 <fjahr> ah, thanks
4112025-12-04T16:38:55 <darosior> I don't think the rationale is much about fixing, but about having our software point to a server ran by a person that is actively attacking the project. Just risk mitigation
4122025-12-04T16:40:05 <Murch[m]> Right, I donât think it matters at this point which version of nodes he surfaces
4132025-12-04T16:40:57 <Murch[m]> He is actively attacking Bitcoin Core, we should rely as little as possible on him to act in the interest of Bitcoin Core
4142025-12-04T16:41:34 <instagibbs> to ask a shorter question: why should he care if "malware" is using his seeder
4152025-12-04T16:42:06 <Murch[m]> Well, he said he doesnât, but that it might help Bitcoin Core to have another dnsseed
4162025-12-04T16:42:15 <stickies-v> i think rationale is already discussed in a lot of detail on the PR and issue, not sure that's worth repeating here
4172025-12-04T16:42:25 <stickies-v> (or if anything is missing, that should be added on the PR instead of here)
4182025-12-04T16:42:28 <instagibbs> Ok I retract :)
4192025-12-04T16:42:55 <dergoegge> yea, I was more curious why with all the agreement it hasn't been merged yet. Which is really something the maintainers should answer
4202025-12-04T16:43:14 <stickies-v> agreed, i'll give it another minute for a response otherwise i'll move on
4212025-12-04T16:44:01 *** Guest62 <Guest62!~Guest62@213.209.71.123.dynamic-cablemodem.pop112-arris.ipv4.wtnet.de> has joined #bitcoin-core-dev
4222025-12-04T16:44:27 *** Guest62 <Guest62!~Guest62@213.209.71.123.dynamic-cablemodem.pop112-arris.ipv4.wtnet.de> has quit IRC (Client Quit)
4232025-12-04T16:44:30 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9e02f7808909...9890058b37b8
4242025-12-04T16:44:30 <bitcoin-git> bitcoin/master b0c7067 SatsAndSports: Remove unreliable seed from chainparams.cpp, and the associated README
4252025-12-04T16:44:31 <bitcoin-git> bitcoin/master 9890058 merge-script: Merge bitcoin/bitcoin#33723: chainparams: remove dnsseed.bitcoin.dashjr-li...
4262025-12-04T16:44:32 <bitcoin-git> [bitcoin] fanquake merged pull request #33723: chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us (master...patch-1) https://github.com/bitcoin/bitcoin/pull/33723
4272025-12-04T16:44:37 <cfields> heh
4282025-12-04T16:44:41 <fjahr> there is your response
4292025-12-04T16:44:41 <Murch[m]> I guess then this is just a â33734 looks RFMâ
4302025-12-04T16:44:43 <stickies-v> hah, well that's your answer dergoegge
4312025-12-04T16:44:47 <dergoegge> ð¥°
4322025-12-04T16:44:48 <darosior> lol
4332025-12-04T16:44:58 <pinheadmz> productive meeting !
4342025-12-04T16:45:01 <kevkevin> :0
4352025-12-04T16:45:05 <eugenesiegel> nice
4362025-12-04T16:45:29 <cfields> darosior: apparently you just asked the wrong question about the gcc :p
4372025-12-04T16:45:41 <stickies-v> #topic IRC chair having triage permissions (darosior / stickies-v)
4382025-12-04T16:45:42 <darosior> haha :)
4392025-12-04T16:45:48 <darosior> Our current peer selection algorithm is to sample over all known node addresses and to pick a random one to connect to. The only way in which we enforce netgroup (/16 or, if configured, ASmap) diversity is that after picking an address at random we make sure it does not belong to a netgroup we are already connected to.
4402025-12-04T16:45:48 <darosior> I think this is pretty brittle from the perspective of preventing an attacker from controlling all our outbound connections. They just need to maximize the number of (possibly fake) nodes, as long as those are spread across as many netgroups as we make outbound connections by default. If we were to instead pick a random netgroup to connect to, and
4412025-12-04T16:45:48 <darosior> then pick a node from this netgroup, the probability for an attacker to control all of our outbound connections would be exponentially decreasing in the number of connections we make. So with 10 slots it would be essentially null, even if they control most of the available netgroups.
4422025-12-04T16:45:48 <darosior> Of course there is also a question of how much doing this would change the network graph. Currently the selection is biased towards connecting to netgroups with a large number of nodes, so in effect towards large hosting providers. Using a peer selection that first sample netgroups would remove this bias, and create a lot more connections to more
4432025-12-04T16:45:48 <darosior> "obscure" netgroups. Interestingly this would have a similar effect to turning ASmap on by default. We may not want to go all the way there, but maybe we could use this selection method for half of our outbound connection slots, as a middle ground between protecting from eclipse but still using the inbound connection slots available at large
4442025-12-04T16:45:49 <darosior> hosting providers.
4452025-12-04T16:45:49 <darosior> Aside from the AddrMan refactoring necessary to support this i first wanted to bring it up to discuss it conceptually. Do people think this is a good idea? A bad idea? Any other second-order effect that may be (in)desirable?
4462025-12-04T16:45:57 <darosior> Woops
4472025-12-04T16:46:03 <pinheadmz> oof
4482025-12-04T16:46:10 <stickies-v> darosior mentioned earlier that IRC chair could/should have triage permissions on the repo, so just wanna quickly address that here
4492025-12-04T16:46:11 <darosior> I saw the ping and assumed it was about the AddrMan peer selection
4502025-12-04T16:46:13 <fjahr> trigger happy
4512025-12-04T16:46:14 <instagibbs> prematurely blue yourself
4522025-12-04T16:46:23 <stickies-v> I don't think this is currently necessary, the IRC meeting chairs can do their job while maintainers/triagers do theirs, assuming at least 1 is on the meeting?
4532025-12-04T16:46:24 <darosior> Sorry about that :/
4542025-12-04T16:46:46 <sipa> i see issue with giving either of them triage permissions
4552025-12-04T16:46:46 <stickies-v> also, we have an IRC chair rotation, so it won't be just me going forward, and we shouldn't escalate permissions too much unless really necessary or helpful
4562025-12-04T16:46:54 <sipa> sorry, i see *NO* issue
4572025-12-04T16:46:58 <fanquake> Yea. I think if the idea is to rotate meeting chair, then no need to tie permissions to it
4582025-12-04T16:47:17 <darosior> Yes i must say my comment was specifically for stickies-v
4592025-12-04T16:47:36 <darosior> But if you don't need it, then you shouldn't have it, for sure
4602025-12-04T16:47:40 <sipa> yeah
4612025-12-04T16:48:00 <darosior> Can revisit if you bump into it again in the future?
4622025-12-04T16:48:16 <stickies-v> if maintainers/triager find they need more help doing the triaging i'm happy to consider, but i'm definitely not asking for it
4632025-12-04T16:48:23 <stickies-v> sounds good
4642025-12-04T16:48:30 <stickies-v> Anything else to discuss?
4652025-12-04T16:48:35 <darosior> Yes i had a topic
4662025-12-04T16:48:41 <darosior> About outbound peers selection
4672025-12-04T16:48:49 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
4682025-12-04T16:48:54 <darosior> I proposed it shortly before the meeting, unsure if it got registered
4692025-12-04T16:49:27 <stickies-v> #topic an outbound connection selection strategy more resistant to eclipse attacks (darosior)
4702025-12-04T16:49:38 <darosior> Ok now i'm shooting it
4712025-12-04T16:49:39 <stickies-v> (sorry it doesn't show up in the topics list but i see it in the logs here)
4722025-12-04T16:49:41 <darosior> Our current peer selection algorithm is to sample over all known node addresses and to pick a random one to connect to. The only way in which we enforce netgroup (/16 or, if configured, ASmap) diversity is that after picking an address at random we make sure it does not belong to a netgroup we are already connected to.
4732025-12-04T16:49:41 <darosior> I think this is pretty brittle from the perspective of preventing an attacker from controlling all our outbound connections. They just need to maximize the number of (possibly fake) nodes, as long as those are spread across as many netgroups as we make outbound connections by default. If we were to instead pick a random netgroup to connect to, and
4742025-12-04T16:49:41 <darosior> then pick a node from this netgroup, the probability for an attacker to control all of our outbound connections would be exponentially decreasing in the number of connections we make. So with 10 slots it would be essentially null, even if they control most of the available netgroups.
4752025-12-04T16:49:41 <darosior> Of course there is also a question of how much doing this would change the network graph. Currently the selection is biased towards connecting to netgroups with a large number of nodes, so in effect towards large hosting providers. Using a peer selection that first sample netgroups would remove this bias, and create a lot more connections to more
4762025-12-04T16:49:41 <darosior> "obscure" netgroups. Interestingly this would have a similar effect to turning ASmap on by default. We may not want to go all the way there, but maybe we could use this selection method for half of our outbound connection slots, as a middle ground between protecting from eclipse but still using the inbound connection slots available at large
4772025-12-04T16:49:41 <darosior> hosting providers.
4782025-12-04T16:49:42 <darosior> Aside from the AddrMan refactoring necessary to support this i first wanted to bring it up to discuss it conceptually. Do people think this is a good idea? A bad idea? Any other second-order effect that may be (in)desirable?
4792025-12-04T16:50:01 <Murch[m]> The proposedmeetingtopic thing seems to not work, it also said âunknown commandâ during the meeting
4802025-12-04T16:50:34 <_aj_> it's a separate script that updates a github page, probably on a timer; the # just confuses meetbot
4812025-12-04T16:50:39 <darosior> Of course there is also the question of how much can an attacker controlling all our outbound slots really achieve. For instance since #19858 they probably wouldn't be able to prevent us from seeing the most work chain for an extended period of time. But still i think it should be a goal to prevent an attacker from controlling all outbound
4822025-12-04T16:50:39 <darosior> connections of a node, let alone of a large fraction of nodes on the network.
4832025-12-04T16:50:42 <sipa> darosior: i worry that it cuts both ways: with the proposed modified strategy, an attacker can increase their probability of being connected to by finding an obscure AS or /16 with few bitcoin nodes in it, and just spinning up one in it
4842025-12-04T16:50:45 <corebot> darosior: Error: That URL raised <Connection timed out.>
4852025-12-04T16:51:04 <sipa> i'd like to think/simulate more about this
4862025-12-04T16:51:21 <darosior> sipa: of getting connected to sure, but not of being *exclusively* connected to
4872025-12-04T16:51:28 <Murch[m]> sipa: Good point. Maybe pick some with that strategy and others by randomly sampling from all?
4882025-12-04T16:51:33 <instagibbs> what's the best place to discuss this topic with paper trail for permanence
4892025-12-04T16:51:50 <darosior> I don't think we should worry about making one or two connections to an attacker
4902025-12-04T16:51:53 <lightlike> open an issue maybe?
4912025-12-04T16:51:54 <fjahr> I didn't have enough time to look at this but in Select_ we first pick a bucket and then a peer from it. So I think the netgroup does have a role or am I misunderstanding the code or lookign in the wrong place?
4922025-12-04T16:52:13 <sipa> fjahr: buckets are not netgroups
4932025-12-04T16:52:23 <sipa> (there is a correlation, but it's much more subtle than that)
4942025-12-04T16:52:27 <darosior> Some background for this is that this summer i looked into an entity that was spinning up a large number of fake nodes (see https://antoinep.com/posts/misbehaving_nodes/). I and a few others are now in discussion with the guy running this operation. He has since then scaled up and now controls 3000 reachable nodes, which is about 30% of all
4952025-12-04T16:52:27 <darosior> clearnet reachable nodes. As a result when you spin up a new nodes nowadays it would most of the time have around 3 outbound connections to this guy. We've had multiple reports of this happening. So all this to say my concern is not purely theoretical, there is an entity actively trying to demonstrate it, which is reasonably successful so far. This
4962025-12-04T16:52:27 <darosior> is discussed at b10c's https://bnoc.xyz/ forum. See https://bnoc.xyz/t/increase-in-the-number-of-reachable-ipv4-nodes-bitprojects-io/45/9 and https://bnoc.xyz/t/satoshi-29-1-0-dont-spam-me-bro-nodes/40/18
4972025-12-04T16:52:29 <fjahr> but they are part of forming the bucket?
4982025-12-04T16:52:35 <b10c> some data on this: there's currently an entity we sometimes have 4 outbounds to https://bnoc.xyz/t/satoshi-29-1-0-dont-spam-me-bro-nodes/40/19
4992025-12-04T16:52:42 <_aj_> sipa: why not just pick a /16 that doesn't have any listening nodes in it currently? there's still x000 /16s to choose from
5002025-12-04T16:53:02 *** purpleKarrot <purpleKarrot!~purpleKar@2001:1620:5547:0:fafe:5eff:fe5b:42e9> has joined #bitcoin-core-dev
5012025-12-04T16:53:11 <sipa> _aj_: ?
5022025-12-04T16:53:12 <fjahr> I should spend more time with the code and simulation is definitely needed
5032025-12-04T16:54:17 <sipa> darosior: yes, our goal is being not-exclusively-attacker-connected, and i think this means different behavior is desirable than minimizing attacker connections in general, but i have a hard time grasping how either strategy affects these
5042025-12-04T16:54:37 <darosior> Because the second-order effect on the network graph are similar to switching to ASmap by default i also looked into previous research into that, and Martin had an interesting comment a "ping pong effect" if the result is a network wide shortage of inbound connection slots
5052025-12-04T16:54:39 <darosior> https://github.com/bitcoin/bitcoin/issues/16599#issuecomment-3609099274
5062025-12-04T16:54:56 <_aj_> sipa: your addrman has 10k nodes, split amongst 5k /16s, say. you have a 2k/10k chance of getting picked by node if you operate 2k nodes, but a 1/3k * 1/5 chance if you pick a /16 with 4 other nodes, or a 1/3k * 1/1 chance if you have a dedicated /16
5072025-12-04T16:55:44 <_aj_> sorry, s/3k/5k/
5082025-12-04T16:55:47 <jonatack> darosior: is this the guy who was proposing to change the default outbound connection count to 48-64 peers as a solution?
5092025-12-04T16:56:06 <sipa> _aj_: i'm missing some context, are you talking about what an attacker should do? with or without this proposed change?
5102025-12-04T16:56:34 <Murch[m]> I think AJ is giving probability of having at least one connection to some peer running a lot of nodes
5112025-12-04T16:56:38 <_aj_> sipa: yeah, vs "an attacker can increase their probability of being connected to by finding an obscure AS"
5122025-12-04T16:56:41 <darosior> jonatack: yes, he does seem quite confused about how all of this work, but i must hand it to him that i expected us to be more robust than that and his mainnet experiment demonstrated it to me
5132025-12-04T16:57:18 <_aj_> Murch[m]: probability of the first connection being to a given attacker, i guess
5142025-12-04T16:57:26 <Murch[m]> darosior: So, is your concern that weâd make all our outbound connections to someone sybilling like that?
5152025-12-04T16:57:57 <_aj_> Murch[m]: we somewhat trust outbounds, so if you're trying to spy on transactions being able to have most peers make an outbound connection to you may be helpful
5162025-12-04T16:57:57 <stickies-v> we're coming up to the meeting end - perhaps useful to continue the conversation on an github issue here, anyone volunteer to do that?
5172025-12-04T16:57:57 <darosior> I fail to see how this is a problem. Especially given that the probability that we make a higher number of connections to this one attacker is extremely small
5182025-12-04T16:58:54 <darosior> Murch[m]: yes
5192025-12-04T16:58:59 <eugenesiegel> I think this guy could cause some damage if he withheld blocks, even if only for 10 minutes...
5202025-12-04T16:59:06 <darosior> Definitely
5212025-12-04T16:59:18 <darosior> stickies-v: i can open an issue
5222025-12-04T16:59:31 <stickies-v> superb, thank you darosior
5232025-12-04T16:59:33 <lightlike> maybe a mixed strat could make sense: choose 50% of outbounds sampling by address as status quo, the other 50% sampling by /16 or AS.
5242025-12-04T16:59:35 <jonatack> darosior: yes please (one related thing I've had on my list is to improve awareness of addnode peers and how to use that)
5252025-12-04T16:59:49 <darosior> lightlike: yes exactly
5262025-12-04T17:00:03 <darosior> It would still have network wide effect though, and it's now clear how to anticipate that
5272025-12-04T17:00:11 <_aj_> s/now/not/ ?
5282025-12-04T17:00:13 <instagibbs> s/now/not/
5292025-12-04T17:00:21 <sipa> s/?/!/
5302025-12-04T17:00:42 <stickies-v> thanks for the lively meeting everyone, it's been a pleasure
5312025-12-04T17:00:44 <stickies-v> #endmeeting
5322025-12-04T17:00:44 <corebot> stickies-v: Meeting ended at 2025-12-04T17:00+0000
5332025-12-04T17:00:45 <corebot> stickies-v: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-12-04_16_00.log.json
5342025-12-04T17:00:46 <corebot> stickies-v: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-12-04_16_00.log.html
5352025-12-04T17:00:47 <corebot> stickies-v: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-12-04_16_00.html
5362025-12-04T17:00:50 <Murch[m]> If we have multiple connections to someone in the same /16, wouldnât we cycle them out as our feeler connection finds other potential peers?
5372025-12-04T17:01:11 <instagibbs> Murch[m] would love to discuss on hte issue, I need to learn more on it
5382025-12-04T17:01:18 <sipa> Murch[m]: we never make multiple connections to the same netgroup
5392025-12-04T17:01:41 * darosior going afk, will open issue
5402025-12-04T17:02:10 <_aj_> sipa: did you see https://github.com/bitcoin/bips/pull/1378#discussion_r2585766526 ? are the bip324 people still around who'd be interested in a SET324ID message to update the short message type dictionary?
5412025-12-04T17:02:14 <Murch[m]> Then I guess I donât understand how weâd have three connections to the donât-spam-me-bro sybil. Are they across multiple netgroups?
5422025-12-04T17:02:25 <_aj_> *are there any bip324 people
5432025-12-04T17:02:38 <_aj_> Murch[m]: exactly
5442025-12-04T17:02:51 <sipa> darosior's observation is that netgroups with many peers still get more connections to them (in aggregate) than netgroups with few peers, because addrman selection picks uniformly random peers, not random netgroups - and then filter by not-have-connection-to-group-already
5452025-12-04T17:02:54 <Murch[m]> I see
5462025-12-04T17:03:04 <sipa> Murch[m]: yes, they have a number of netgroups
5472025-12-04T17:03:07 <instagibbs> Murch[m] they have access to making many "nodes" on at least 4 AS's too
5482025-12-04T17:03:30 <Murch[m]> I see, I missed that earlier
5492025-12-04T17:03:42 *** phantomcircuit_ is now known as phantomcircuit
5502025-12-04T17:04:21 <_aj_> darosior: i would have thought any global effect the change has in rearranging how the p2p graph is interconnected would be beneficial rather than detrimental, fwiw
5512025-12-04T17:04:57 <Murch[m]> So basically right now, we sample randomly and only connect if itâs a new netgroup, but obviously having a lot of nodes in some groups makes them more likely to be picked. If we randomly sampled netgroups and then picked one node in them, weâd instead be much more likely to pick obscure groups, but those nodes would be much more likely to have no inbound slots left, and weâd get more cycling?
5522025-12-04T17:05:21 <sipa> Murch[m]: seems like a good summary
5532025-12-04T17:06:13 <Murch[m]> Might be interesting to flip a coin and use one or the other strategy for each connection attempt.
5542025-12-04T17:06:25 <_aj_> cf #28463
5552025-12-04T17:06:30 <corebot> https://github.com/bitcoin/bitcoin/issues/28463 | p2p: Increase inbound capacity for block-relay only connections by mzumsande · Pull Request #28463 · bitcoin/bitcoin · GitHub
5562025-12-04T17:06:58 <Murch[m]> Also, sr_gi when erlay, so we can have 12 connections? 0:-)
5572025-12-04T17:07:16 <Murch[m]> *outbound connections
5582025-12-04T17:09:22 *** Emc99 <Emc99!~Emc99@212.129.84.78> has quit IRC (Quit: Client closed)
5592025-12-04T17:11:34 <bitcoin-git> [bitcoin] wnqqnw19 opened pull request #34007: Wnqqnw19 (master...wnqqnw19) https://github.com/bitcoin/bitcoin/pull/34007
5602025-12-04T17:12:06 <bitcoin-git> [bitcoin] fanquake closed pull request #34007: Wnqqnw19 (master...wnqqnw19) https://github.com/bitcoin/bitcoin/pull/34007
5612025-12-04T17:14:36 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has quit IRC (Quit: Ping timeout (120 seconds))
5622025-12-04T17:14:37 <fanquake> FYI. Probably going to cut a 30.1rc1 soon. Have a decent collection of bugfixes / backports in there (#33997) and in #33609.
5632025-12-04T17:14:38 <corebot> https://github.com/bitcoin/bitcoin/issues/33997 | [30.x] Backports & 30.1rc1 by fanquake · Pull Request #33997 · bitcoin/bitcoin · GitHub
5642025-12-04T17:14:40 <corebot> https://github.com/bitcoin/bitcoin/issues/33609 | [30.x] Backports by fanquake · Pull Request #33609 · bitcoin/bitcoin · GitHub
5652025-12-04T17:15:10 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has joined #bitcoin-core-dev
5662025-12-04T17:15:24 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
5672025-12-04T17:15:47 *** kevkevin <kevkevin!~kevkevin@38.140.4.82> has quit IRC (Read error: No route to host)
5682025-12-04T17:15:49 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
5692025-12-04T17:16:15 <abubakarsadiq> re: stratumV2 I was with the stratumV2 irl today discussing the current mining interface issue of memory management of blocktemplates and crash during IBD, the crash has an issue opened which has a couple of discussion already. I prefer a LIFO approach from the node side other contributors prefer that we provide a mechanism for the client to be able to know memory usage or notify the tha client when the memory
5702025-12-04T17:16:15 <abubakarsadiq> limit is reached and they evict a candidate, The SRI guys said there eviction strategy is LIFO, so it makes sense to just evict LIFO on the node side. I think I provide more info here https://github.com/bitcoin/bitcoin/pull/33922 could appreciate more eyes
5712025-12-04T17:16:18 *** kevkevin <kevkevin!~kevkevin@38.140.4.82> has joined #bitcoin-core-dev
5722025-12-04T17:19:46 *** kevkevin_ <kevkevin_!~kevkevin@38.140.4.82> has joined #bitcoin-core-dev
5732025-12-04T17:19:46 *** kevkevin <kevkevin!~kevkevin@38.140.4.82> has quit IRC (Read error: Connection reset by peer)
5742025-12-04T17:22:11 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
5752025-12-04T17:22:17 *** kevkevin_ <kevkevin_!~kevkevin@38.140.4.82> has quit IRC (Remote host closed the connection)
5762025-12-04T17:22:30 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
5772025-12-04T17:23:17 <ryanofsky> abubakarsadiq, my understanding is that the node will be able to delete templates using the memory tracking added in #33922. 33922 doesn't change memory managerment it just adds tracking
5782025-12-04T17:23:19 <corebot> https://github.com/bitcoin/bitcoin/issues/33922 | mining: add getMemoryLoad() and track template non-mempool memory footprint by Sjors · Pull Request #33922 · bitcoin/bitcoin · GitHub
5792025-12-04T17:23:29 *** f321x <f321x!~f321x@user/f321x> has quit IRC (Quit: f321x)
5802025-12-04T17:25:47 <abubakarsadiq> yes. I asked them how the are going evict when the limit reached they mentioned LIFO as well so why not do it ourself? My concern is when the client don't do it correctly and we run out of memory?
5812025-12-04T17:26:11 *** Guest89 <Guest89!~Guest89@73.43.65.14> has quit IRC (Ping timeout: 250 seconds)
5822025-12-04T17:26:58 <ryanofsky> seems reasonable for the node to do it, especially if that's what clients want. i was just unsure if they wanted templates to disappear without being notified, or if they wanted notifications or what
5832025-12-04T17:27:45 *** nejos97 <nejos97!~nejos97@user/nejos97> has joined #bitcoin-core-dev
5842025-12-04T17:31:13 <abubakarsadiq> I agree but there is no realistic scenario where they will want to even be notified before the we evict I think, the miners have long switched to the latest before the limit reached.
5852025-12-04T17:33:12 <ryanofsky> All right, that wasn't obvious to me. But sounds good
5862025-12-04T17:35:29 <ryanofsky> I'm reviewing #33922 currently FWIW. I see it as a building block for any memory management scheme, but you can let me know if that's not right
5872025-12-04T17:35:31 <corebot> https://github.com/bitcoin/bitcoin/issues/33922 | mining: add getMemoryLoad() and track template non-mempool memory footprint by Sjors · Pull Request #33922 · bitcoin/bitcoin · GitHub
5882025-12-04T17:36:09 *** Guest89 <Guest89!~Guest89@73.43.65.14> has joined #bitcoin-core-dev
5892025-12-04T17:36:56 <abubakarsadiq> Sure ð
5902025-12-04T17:40:38 *** Guest89 <Guest89!~Guest89@73.43.65.14> has quit IRC (Client Quit)
5912025-12-04T17:45:22 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
5922025-12-04T17:45:44 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev
5932025-12-04T17:51:22 <bitcoin-git> [bitcoin] 0xB10C opened pull request #34008: log: don't rate-limit "new peer" with -debug=net (master...2025-12-dont-ratelimit-new-inbound-peer-connected-with-debug=net) https://github.com/bitcoin/bitcoin/pull/34008
5942025-12-04T17:53:45 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has quit IRC (Quit: Client closed)
5952025-12-04T18:02:29 *** dzxzg2 <dzxzg2!~dzxzg@user/dzxzg> has joined #bitcoin-core-dev
5962025-12-04T18:08:22 *** vasild <vasild!~vd@user/vasild> has quit IRC (Remote host closed the connection)
5972025-12-04T18:08:34 *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
5982025-12-04T18:13:49 *** nejos97 <nejos97!~nejos97@user/nejos97> has quit IRC (Ping timeout: 264 seconds)
5992025-12-04T18:20:11 *** Novo__ <Novo__!uid605808@id-605808.lymington.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
6002025-12-04T18:22:01 *** nejos97 <nejos97!~nejos97@user/nejos97> has joined #bitcoin-core-dev
6012025-12-04T18:25:36 *** xFFFC0000 <xFFFC0000!uid629468@id-629468.ilkley.irccloud.com> has joined #bitcoin-core-dev
6022025-12-04T18:29:23 *** afiore <afiore!~afiore@user/afiore> has quit IRC (Remote host closed the connection)
6032025-12-04T18:30:04 *** nejos97 <nejos97!~nejos97@user/nejos97> has quit IRC (Remote host closed the connection)
6042025-12-04T18:30:12 *** afiore <afiore!~afiore@user/afiore> has joined #bitcoin-core-dev
6052025-12-04T18:30:15 *** nejos97 <nejos97!~nejos97@user/nejos97> has joined #bitcoin-core-dev
6062025-12-04T18:30:57 *** nejos97 <nejos97!~nejos97@user/nejos97> has quit IRC (Client Quit)
6072025-12-04T18:31:09 *** nejos97 <nejos97!~nejos97@user/nejos97> has joined #bitcoin-core-dev
6082025-12-04T18:31:10 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has joined #bitcoin-core-dev
6092025-12-04T18:44:24 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
6102025-12-04T18:49:52 *** ___nick___ <___nick___!~quassel@82-132-220-252.dab.02.net> has joined #bitcoin-core-dev
6112025-12-04T18:50:38 *** ___nick___ <___nick___!~quassel@82-132-220-252.dab.02.net> has quit IRC (Client Quit)
6122025-12-04T18:52:48 *** ___nick___ <___nick___!~quassel@82-132-220-252.dab.02.net> has joined #bitcoin-core-dev
6132025-12-04T19:01:35 *** adys <adys!~adys@149.106.235.56> has quit IRC (Ping timeout: 240 seconds)
6142025-12-04T19:05:17 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
6152025-12-04T19:08:20 *** Guest71 <Guest71!~Guest71@bras-base-jkvlon0513w-grc-27-74-14-8-64.dsl.bell.ca> has joined #bitcoin-core-dev
6162025-12-04T19:11:21 *** _flood <_flood!~flooded@154.47.22.66> has quit IRC (Remote host closed the connection)
6172025-12-04T19:11:49 *** _flood <_flood!~flooded@154.47.22.66> has joined #bitcoin-core-dev
6182025-12-04T19:13:00 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
6192025-12-04T19:18:10 <sipa> _aj_: seems conceptually easy enough, but i'd say it warrants a new (small) bip
6202025-12-04T19:25:47 *** Guest71 <Guest71!~Guest71@bras-base-jkvlon0513w-grc-27-74-14-8-64.dsl.bell.ca> has quit IRC (Ping timeout: 250 seconds)
6212025-12-04T19:32:49 *** iSiUp <iSiUp!~isi@user/iSiUp> has quit IRC (Ping timeout: 246 seconds)
6222025-12-04T19:34:03 *** iSiUp <iSiUp!~isi@user/iSiUp> has joined #bitcoin-core-dev
6232025-12-04T20:03:37 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 264 seconds)
6242025-12-04T20:20:00 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
6252025-12-04T20:22:32 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
6262025-12-04T20:38:15 *** nejos97 <nejos97!~nejos97@user/nejos97> has quit IRC (Ping timeout: 240 seconds)
6272025-12-04T20:38:39 *** nejos97 <nejos97!~nejos97@user/nejos97> has joined #bitcoin-core-dev
6282025-12-04T21:03:44 *** ___nick___ <___nick___!~quassel@82-132-220-252.dab.02.net> has quit IRC (Ping timeout: 240 seconds)
6292025-12-04T21:18:49 *** nejos97 <nejos97!~nejos97@user/nejos97> has quit IRC (Ping timeout: 255 seconds)
6302025-12-04T21:19:56 *** nejos97 <nejos97!~nejos97@user/nejos97> has joined #bitcoin-core-dev
6312025-12-04T21:20:27 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has quit IRC (Quit: Client closed)
6322025-12-04T21:37:13 <midnight> just wanted to say thank you for continuing to hold meetings in here where folks like myself can read too. \o
6332025-12-04T21:37:33 <midnight> also thanks for all your continuing efforts, sincerely.
6342025-12-04T21:44:12 *** nejos97 <nejos97!~nejos97@user/nejos97> has quit IRC (Read error: Connection reset by peer)
6352025-12-04T21:44:35 *** sliv3r__ <sliv3r__!~sliv3r__@user/sliv3r-:76883> has quit IRC (Ping timeout: 240 seconds)
6362025-12-04T21:45:36 *** sliv3r__ <sliv3r__!~sliv3r__@user/sliv3r-:76883> has joined #bitcoin-core-dev
6372025-12-04T21:48:40 *** nejos97 <nejos97!~nejos97@user/nejos97> has joined #bitcoin-core-dev
6382025-12-04T21:51:37 *** adys <adys!~adys@149.106.235.56> has joined #bitcoin-core-dev
6392025-12-04T21:52:26 *** adys <adys!~adys@149.106.235.56> has quit IRC (Read error: Connection reset by peer)
6402025-12-04T21:53:57 *** adys <adys!~adys@149.106.235.56> has joined #bitcoin-core-dev
6412025-12-04T21:55:59 *** nintendo1889 <nintendo1889!~nintendo1@148.59.171.204> has joined #bitcoin-core-dev
6422025-12-04T22:01:21 *** nintendo1889 <nintendo1889!~nintendo1@148.59.171.204> has quit IRC (Ping timeout: 250 seconds)
6432025-12-04T22:07:17 *** ___nick___ <___nick___!~quassel@82-132-220-252.dab.02.net> has joined #bitcoin-core-dev
6442025-12-04T22:19:46 *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has joined #bitcoin-core-dev
6452025-12-04T22:25:27 *** vasild <vasild!~vd@user/vasild> has quit IRC (Remote host closed the connection)
6462025-12-04T22:25:37 *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
6472025-12-04T22:25:55 *** ___nick___ <___nick___!~quassel@82-132-220-252.dab.02.net> has quit IRC (Ping timeout: 240 seconds)
6482025-12-04T22:39:37 *** aleggg <aleggg!~aleggg@201-0-25-210.dsl.telesp.net.br> has joined #bitcoin-core-dev
6492025-12-04T23:00:05 *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has quit IRC (Remote host closed the connection)
6502025-12-04T23:00:23 *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has joined #bitcoin-core-dev
6512025-12-04T23:04:21 *** _flood <_flood!~flooded@154.47.22.66> has quit IRC (Remote host closed the connection)
6522025-12-04T23:04:57 *** _flood <_flood!~flooded@154.47.22.66> has joined #bitcoin-core-dev
6532025-12-04T23:34:45 *** nejos97 <nejos97!~nejos97@user/nejos97> has quit IRC (Ping timeout: 252 seconds)
6542025-12-04T23:38:13 *** nejos97 <nejos97!~nejos97@user/nejos97> has joined #bitcoin-core-dev
6552025-12-04T23:46:50 *** memset <memset!~memset@gateway/tor-sasl/memset> has quit IRC (Remote host closed the connection)
6562025-12-04T23:47:12 *** memset <memset!~memset@gateway/tor-sasl/memset> has joined #bitcoin-core-dev