12023-10-19T00:00:00  *** salvatoshi <salvatoshi!~salvatosh@103.100.173.166> has joined #bitcoin-core-dev
  22023-10-19T00:08:20  *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has joined #bitcoin-core-dev
  32023-10-19T00:11:37  *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
  42023-10-19T00:16:05  *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 240 seconds)
  52023-10-19T00:28:40  *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
  62023-10-19T00:33:56  *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 255 seconds)
  72023-10-19T00:42:04  *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has quit IRC (Ping timeout: 258 seconds)
  82023-10-19T00:47:46  *** Guest6 <Guest6!~Guest6@2607:fb90:7555:5379:5469:79f5:10e2:64d4> has joined #bitcoin-core-dev
  92023-10-19T00:55:55  *** Guest6 <Guest6!~Guest6@2607:fb90:7555:5379:5469:79f5:10e2:64d4> has quit IRC (Quit: Client closed)
 102023-10-19T01:20:01  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 112023-10-19T01:24:12  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 240 seconds)
 122023-10-19T01:34:02  *** DarrylTheFiiish <DarrylTheFiiish!~DarrylThe@user/DarrylTheFish> has joined #bitcoin-core-dev
 132023-10-19T01:36:15  *** DarrylTheFiish <DarrylTheFiish!~DarrylThe@user/DarrylTheFish> has quit IRC (Ping timeout: 240 seconds)
 142023-10-19T01:36:41  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 152023-10-19T01:41:36  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 272 seconds)
 162023-10-19T01:53:27  *** salvatoshi <salvatoshi!~salvatosh@103.100.173.166> has quit IRC (Ping timeout: 240 seconds)
 172023-10-19T02:04:18  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 182023-10-19T02:04:54  *** ibiko1 <ibiko1!~ibiko1@170.253.45.108> has joined #bitcoin-core-dev
 192023-10-19T02:09:11  *** ibiko1 <ibiko1!~ibiko1@170.253.45.108> has quit IRC (Ping timeout: 260 seconds)
 202023-10-19T02:09:19  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 264 seconds)
 212023-10-19T02:22:01  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 222023-10-19T02:23:32  *** test_ <test_!flooded@gateway/vpn/protonvpn/flood/x-43489060> has joined #bitcoin-core-dev
 232023-10-19T02:26:35  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 240 seconds)
 242023-10-19T02:27:20  *** flooded <flooded!flooded@gateway/vpn/protonvpn/flood/x-43489060> has quit IRC (Ping timeout: 255 seconds)
 252023-10-19T02:32:55  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 262023-10-19T02:37:34  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 245 seconds)
 272023-10-19T02:39:00  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 282023-10-19T02:43:24  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 248 seconds)
 292023-10-19T02:59:11  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 302023-10-19T03:03:54  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 258 seconds)
 312023-10-19T03:15:37  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 322023-10-19T03:20:23  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 258 seconds)
 332023-10-19T03:26:33  *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
 342023-10-19T03:31:08  *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 255 seconds)
 352023-10-19T03:45:35  *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
 362023-10-19T03:50:08  *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 255 seconds)
 372023-10-19T04:01:01  *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
 382023-10-19T04:01:35  *** cmirror <cmirror!~cmirror@4.53.92.114> has joined #bitcoin-core-dev
 392023-10-19T04:02:07  *** hernanmarino <hernanmarino!~hernanmar@2800:2130:2800:199:4263:2a55:7423:f2c4> has quit IRC (Remote host closed the connection)
 402023-10-19T04:02:25  *** hernanmarino <hernanmarino!~hernanmar@2800:2130:2800:199:a595:a0c1:920c:9f10> has joined #bitcoin-core-dev
 412023-10-19T04:07:31  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 422023-10-19T04:10:18  *** hernanmarino <hernanmarino!~hernanmar@2800:2130:2800:199:a595:a0c1:920c:9f10> has quit IRC (Quit: Leaving)
 432023-10-19T04:12:19  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 264 seconds)
 442023-10-19T04:24:45  *** hernanmarino <hernanmarino!~hernanmar@181.98.56.2> has joined #bitcoin-core-dev
 452023-10-19T04:41:14  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 462023-10-19T04:45:55  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 264 seconds)
 472023-10-19T04:58:35  *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has joined #bitcoin-core-dev
 482023-10-19T05:03:06  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 492023-10-19T05:10:42  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 246 seconds)
 502023-10-19T05:31:04  *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has quit IRC (Ping timeout: 255 seconds)
 512023-10-19T05:31:38  *** u0_a000 <u0_a000!~u0_a000@143.244.44.174> has joined #bitcoin-core-dev
 522023-10-19T05:31:39  *** u0_a000 <u0_a000!~u0_a000@143.244.44.174> has quit IRC (K-Lined)
 532023-10-19T05:39:55  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 542023-10-19T05:44:12  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 240 seconds)
 552023-10-19T05:45:59  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 562023-10-19T05:50:12  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 240 seconds)
 572023-10-19T05:52:20  *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has joined #bitcoin-core-dev
 582023-10-19T05:57:43  *** Guest7 <Guest7!~Guest7@ip-62-245-75-70.bb.vodafone.cz> has joined #bitcoin-core-dev
 592023-10-19T05:58:43  *** Guest7 <Guest7!~Guest7@ip-62-245-75-70.bb.vodafone.cz> has quit IRC (Client Quit)
 602023-10-19T05:58:51  *** Guest7 <Guest7!~Guest7@ip-62-245-75-70.bb.vodafone.cz> has joined #bitcoin-core-dev
 612023-10-19T06:02:38  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 622023-10-19T06:07:31  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 258 seconds)
 632023-10-19T06:24:29  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 642023-10-19T06:27:18  *** someone235 <someone235!uid419897@id-419897.ilkley.irccloud.com> has joined #bitcoin-core-dev
 652023-10-19T06:29:03  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 240 seconds)
 662023-10-19T06:30:35  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 672023-10-19T06:35:13  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 252 seconds)
 682023-10-19T06:42:33  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 692023-10-19T06:45:56  *** vasild_ <vasild_!~vd@user/vasild> has joined #bitcoin-core-dev
 702023-10-19T06:47:03  *** vasild <vasild!~vd@user/vasild> has quit IRC (Remote host closed the connection)
 712023-10-19T06:47:23  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 258 seconds)
 722023-10-19T06:48:02  *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
 732023-10-19T06:51:15  *** salvatoshi <salvatoshi!~salvatosh@103.151.37.100> has joined #bitcoin-core-dev
 742023-10-19T06:52:41  *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 260 seconds)
 752023-10-19T06:58:49  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 762023-10-19T07:03:24  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 240 seconds)
 772023-10-19T07:04:54  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 782023-10-19T07:09:03  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 240 seconds)
 792023-10-19T07:13:23  *** abubakarsadiq <abubakarsadiq!uid602234@id-602234.hampstead.irccloud.com> has joined #bitcoin-core-dev
 802023-10-19T07:13:55  *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has quit IRC (Remote host closed the connection)
 812023-10-19T07:21:16  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 822023-10-19T07:26:07  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 264 seconds)
 832023-10-19T07:34:10  *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
 842023-10-19T07:51:27  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 852023-10-19T07:55:54  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 246 seconds)
 862023-10-19T08:17:03  *** ibiko1 <ibiko1!~ibiko1@170.253.45.108> has joined #bitcoin-core-dev
 872023-10-19T08:20:47  *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has joined #bitcoin-core-dev
 882023-10-19T08:21:52  *** ibiko1 <ibiko1!~ibiko1@170.253.45.108> has quit IRC (Ping timeout: 272 seconds)
 892023-10-19T08:24:29  *** Guest7 <Guest7!~Guest7@ip-62-245-75-70.bb.vodafone.cz> has quit IRC (Quit: Client closed)
 902023-10-19T08:25:31  *** brunoerg <brunoerg!~brunoerg@187.183.43.117> has quit IRC (Ping timeout: 264 seconds)
 912023-10-19T08:37:18  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 922023-10-19T08:42:16  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 252 seconds)
 932023-10-19T08:43:27  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
 942023-10-19T08:48:37  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/655dc716aa60...f4049eaf08b6
 952023-10-19T08:48:38  <bitcoin-git> bitcoin/master fa4c683 MarcoFalke: test: Fix failing time check in rpc_net.py
 962023-10-19T08:48:38  <bitcoin-git> bitcoin/master f4049ea fanquake: Merge bitcoin/bitcoin#28671: test: Fix failing time check in rpc_net.py
 972023-10-19T08:48:56  <fanquake> Reminder that priority project voting finishes up today, if you haven't voted already
 982023-10-19T08:48:56  <bitcoin-git> [bitcoin] fanquake merged pull request #28671: test: Fix failing time check in rpc_net.py (master...2310-test-less-fail-) https://github.com/bitcoin/bitcoin/pull/28671
 992023-10-19T08:49:11  <fanquake> #28642
1002023-10-19T08:49:12  <gribble> https://github.com/bitcoin/bitcoin/issues/28642 | Voting on Priority Projects for 27.0 · Issue #28642 · bitcoin/bitcoin · GitHub
1012023-10-19T08:53:32  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 272 seconds)
1022023-10-19T08:59:58  <glozow> sdaftuar: \o/
1032023-10-19T09:07:16  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f4049eaf08b6...5eb82d5706ea
1042023-10-19T09:07:17  <bitcoin-git> bitcoin/master 8cfa22a fanquake: build: move -fstack-reuse=none to CORE_CXXFLAGS
1052023-10-19T09:07:17  <bitcoin-git> bitcoin/master 5eb82d5 fanquake: Merge bitcoin/bitcoin#28672: build: move `-fstack-reuse=none` to CORE_CXXF...
1062023-10-19T09:07:23  <bitcoin-git> [bitcoin] fanquake merged pull request #28672: build: move `-fstack-reuse=none` to CORE_CXXFLAGS (master...move_stack_reuse_core_flags) https://github.com/bitcoin/bitcoin/pull/28672
1072023-10-19T09:20:26  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
1082023-10-19T09:23:56  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5eb82d5706ea...091d29c49590
1092023-10-19T09:23:57  <bitcoin-git> bitcoin/master 004903e Brandon Odiwuor: test: Add Wallet Unlock Context Manager
1102023-10-19T09:23:57  <bitcoin-git> bitcoin/master 091d29c fanquake: Merge bitcoin/bitcoin#28617: test: Add Wallet Unlock Context Manager
1112023-10-19T09:24:02  <bitcoin-git> [bitcoin] fanquake merged pull request #28617: test: Add Wallet Unlock Context Manager (master...wallet-unlock-context-manager) https://github.com/bitcoin/bitcoin/pull/28617
1122023-10-19T09:24:36  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 240 seconds)
1132023-10-19T09:25:37  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
1142023-10-19T09:28:41  *** gerle <gerle!~quassel@212-186-78-187.static.upcbusiness.at> has joined #bitcoin-core-dev
1152023-10-19T09:29:57  *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev (Closing Window)
1162023-10-19T09:30:19  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 264 seconds)
1172023-10-19T09:32:15  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/091d29c49590...106ab20f121f
1182023-10-19T09:32:16  <bitcoin-git> bitcoin/master 2ce7e31 Greg Sanders: docs: Add reference to total.coverage report
1192023-10-19T09:32:16  <bitcoin-git> bitcoin/master 106ab20 fanquake: Merge bitcoin/bitcoin#28673: docs: Add reference to total.coverage report
1202023-10-19T09:32:21  <bitcoin-git> [bitcoin] fanquake merged pull request #28673: docs: Add reference to total.coverage report (master...cov_docs) https://github.com/bitcoin/bitcoin/pull/28673
1212023-10-19T09:36:06  <fanquake> 25.1 binaries are now available: https://bitcoincore.org/bin/bitcoin-core-25.1/
1222023-10-19T09:36:15  <fanquake> Website post needs a sanity check: https://github.com/bitcoin-core/bitcoincore.org/pull/991
1232023-10-19T09:48:03  *** TallTim <TallTim!~talltim@184-83-238-129-dynamic.midco.net> has quit IRC (Remote host closed the connection)
1242023-10-19T09:48:20  *** TallTim <TallTim!~talltim@184-83-238-129-dynamic.midco.net> has joined #bitcoin-core-dev
1252023-10-19T09:58:54  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
1262023-10-19T10:02:07  <bitcoin-git> [bitcoin] fjahr opened pull request #28685: coinstats, asssumeutxo: fix hash_serialized2 calculation (master...2023-10-au-weird-fix) https://github.com/bitcoin/bitcoin/pull/28685
1272023-10-19T10:03:24  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 240 seconds)
1282023-10-19T10:09:31  *** TallTim_ <TallTim_!~talltim@184-83-238-129-dynamic.midco.net> has joined #bitcoin-core-dev
1292023-10-19T10:09:56  *** salvatoshi_ <salvatoshi_!~salvatosh@103.151.37.100> has joined #bitcoin-core-dev
1302023-10-19T10:10:24  *** salvatoshi <salvatoshi!~salvatosh@103.151.37.100> has quit IRC (Read error: Connection reset by peer)
1312023-10-19T10:12:55  *** TallTim <TallTim!~talltim@184-83-238-129-dynamic.midco.net> has quit IRC (Ping timeout: 255 seconds)
1322023-10-19T10:23:50  <bitcoin-git> [bitcoin] ajtowns opened pull request #28686: refactor: Split per-peer parts of net module into new node/node module (master...202310-nodenode) https://github.com/bitcoin/bitcoin/pull/28686
1332023-10-19T10:27:56  *** realies <realies!~realies@user/realies> has quit IRC (Ping timeout: 260 seconds)
1342023-10-19T10:32:37  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
1352023-10-19T10:33:05  *** someone235 <someone235!uid419897@id-419897.ilkley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
1362023-10-19T10:37:09  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC (Ping timeout: 245 seconds)
1372023-10-19T10:41:00  *** salvatoshi_ <salvatoshi_!~salvatosh@103.151.37.100> has quit IRC (Ping timeout: 240 seconds)
1382023-10-19T10:50:40  *** flooded <flooded!flooded@gateway/vpn/protonvpn/flood/x-43489060> has joined #bitcoin-core-dev
1392023-10-19T10:52:44  *** vasild_ <vasild_!~vd@user/vasild> has quit IRC (Quit: leaving)
1402023-10-19T10:54:15  *** test_ <test_!flooded@gateway/vpn/protonvpn/flood/x-43489060> has quit IRC (Ping timeout: 258 seconds)
1412023-10-19T10:54:38  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has joined #bitcoin-core-dev
1422023-10-19T11:35:42  *** mudsip <mudsip!~mudsip@user/mudsip> has joined #bitcoin-core-dev
1432023-10-19T11:35:52  *** mudsip <mudsip!~mudsip@user/mudsip> has quit IRC (Client Quit)
1442023-10-19T11:47:47  *** salvatoshi_ <salvatoshi_!~salvatosh@103.100.173.166> has joined #bitcoin-core-dev
1452023-10-19T11:48:03  *** salvatoshi_ <salvatoshi_!~salvatosh@103.100.173.166> has quit IRC (Remote host closed the connection)
1462023-10-19T12:05:08  *** TallTim_ is now known as TallTim
1472023-10-19T12:19:05  <fjahr> #proposedmeetingtopic Fix for hash_serialized2 calculation and implications (for context see #28675 and #28685)
1482023-10-19T12:19:06  <gribble> https://github.com/bitcoin/bitcoin/issues/28675 | Assumeutxo: Altered txoutset dump is still valid · Issue #28675 · bitcoin/bitcoin · GitHub
1492023-10-19T12:19:07  <gribble> https://github.com/bitcoin/bitcoin/issues/28685 | coinstats, assumeutxo: fix hash_serialized2 calculation by fjahr · Pull Request #28685 · bitcoin/bitcoin · GitHub
1502023-10-19T12:26:03  <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/106ab20f121f...9e616baec0f2
1512023-10-19T12:26:04  <bitcoin-git> bitcoin/master d90ad5a Hennadii Stepanov: build: Include qt sources for parsing with extract_strings.py
1522023-10-19T12:26:04  <bitcoin-git> bitcoin/master b59b31a Hennadii Stepanov: build: Drop redundant qt/bitcoin.cpp
1532023-10-19T12:26:05  <bitcoin-git> bitcoin/master 9e616ba fanquake: Merge bitcoin/bitcoin#22764: build: Include qt sources for parsing with ex...
1542023-10-19T12:26:13  <bitcoin-git> [bitcoin] fanquake merged pull request #22764: build: Include qt sources for parsing with extract_strings.py (master...210821-translation) https://github.com/bitcoin/bitcoin/pull/22764
1552023-10-19T12:33:55  *** dviola <dviola!~diego@user/dviola> has quit IRC (Ping timeout: 264 seconds)
1562023-10-19T12:35:28  *** diego <diego!~diego@186.222.94.177> has joined #bitcoin-core-dev
1572023-10-19T12:35:57  *** diego is now known as Guest1221
1582023-10-19T12:37:22  <bitcoin-git> [bitcoin] stickies-v opened pull request #28687: [POC][WIP] C++20 std::views::reverse (master...2023-10/cpp20-use-ranges-reverseview) https://github.com/bitcoin/bitcoin/pull/28687
1592023-10-19T12:38:03  *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:8a:bd3e:1d7:f38c:2081> has quit IRC ()
1602023-10-19T12:38:46  <fanquake> moar c++20
1612023-10-19T12:54:22  <jamesob> fjahr theStack: great catch guys
1622023-10-19T13:01:40  <sipa> has there been any thought about distributing UTXO sets over P2P? presumably this will require at least some merkle-structuring to permit validation of individual chunks, or even FEC coding to allow sharding
1632023-10-19T13:01:54  <sipa> because if so, that may inform the kind of UTXO hash that's used?
1642023-10-19T13:01:58  *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
1652023-10-19T13:06:55  *** Guest1221 <Guest1221!~diego@186.222.94.177> has quit IRC (Ping timeout: 255 seconds)
1662023-10-19T13:09:24  *** diego <diego!~diego@186.222.94.177> has joined #bitcoin-core-dev
1672023-10-19T13:09:30  <_aj_> sipa: i thought about https://gist.github.com/ajtowns/4f20d078f8831267fa49625c16ae1921 for partial validation via muhash
1682023-10-19T13:09:54  *** diego is now known as Guest2177
1692023-10-19T13:12:34  <jamesob> sipa: yeah you and I talked about this a little years ago; I think some of that made its way into this document: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal#snapshot-storage-and-distribution
1702023-10-19T13:13:06  <jamesob> I wonder if there is any wisdom in committing to a sha256sum of the snapshot file itself in the source code as a belt and suspenders to avoid the issue that fjahr discovered
1712023-10-19T13:15:44  <_aj_> it's always good to authenticate data before parsing it, imo
1722023-10-19T13:15:46  <sipa> _aj_: what's the point of using muhash?
1732023-10-19T13:16:16  <_aj_> sipa: it's readily available already
1742023-10-19T13:16:28  *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has joined #bitcoin-core-dev
1752023-10-19T13:16:45  <_aj_> sipa: ie, you can verify it against any node that's running coinstatsindex
1762023-10-19T13:16:49  <sipa> _aj_: well, yes, but for the whole set only, not for 50 MB chinjks
1772023-10-19T13:17:55  <sipa> *chunks
1782023-10-19T13:18:29  *** pablomartin4btc <pablomartin4btc!~pablomart@193.160.245.181> has quit IRC (Ping timeout: 255 seconds)
1792023-10-19T13:21:28  <glozow> reminder that #28642 will be locked soon
1802023-10-19T13:21:30  <gribble> https://github.com/bitcoin/bitcoin/issues/28642 | Voting on Priority Projects for 27.0 · Issue #28642 · bitcoin/bitcoin · GitHub
1812023-10-19T13:27:19  <_aj_> sipa: mostly it seemed like a possible way to have the set of hashes available for a height soon after the height was mined, without requiring the node to have any downtime while the utxo set gets rehashed
1822023-10-19T13:27:47  <sipa> _aj_: ah, hmm
1832023-10-19T13:28:02  <sipa> let's talk in the meeting, i guess?
1842023-10-19T13:31:38  <_aj_> sipa: i think you may have already exhausted how much i thought about it :)
1852023-10-19T13:57:11  *** guest-127 <guest-127!~guest-127@212.129.86.235> has joined #bitcoin-core-dev
1862023-10-19T13:58:50  *** SebastianvStaa <SebastianvStaa!~Sebastian@ip-109-43-241-175.web.vodafone.de> has joined #bitcoin-core-dev
1872023-10-19T14:00:25  <achow101> #startmeeting
1882023-10-19T14:00:25  <core-meetingbot> Meeting started Thu Oct 19 14:00:25 2023 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
1892023-10-19T14:00:25  <core-meetingbot> Available commands: action commands idea info link nick
1902023-10-19T14:00:30  <achow101> #bitcoin-core-dev Meeting: achow101 _aj_ amiti ariard aureleoules b10c BlueMatt brunoerg cfields darosior dergoegge dongcarl fanquake fjahr furszy gleb glozow hebasto instagibbs jamesob jarolrod jonatack josibake kallewoof kanzure kouloumos kvaciral laanwj LarryRuane lightlike luke-jr MacroFake Murch phantomcircuit pinheadmz promag provoostenator ryanofsky sdaftuar S3RK stickies-v sipa theStack TheCharlatan vasild
1912023-10-19T14:00:41  <vasild> hi
1922023-10-19T14:00:43  <stickies-v> hi
1932023-10-19T14:00:45  <pinheadmz> hi
1942023-10-19T14:00:47  <glozow> hi
1952023-10-19T14:00:47  <instagibbs> hi
1962023-10-19T14:00:51  <josie> hi
1972023-10-19T14:00:55  <sdaftuar>   hi
1982023-10-19T14:00:56  <theStack> hi
1992023-10-19T14:00:58  <dergoegge> hi
2002023-10-19T14:00:58  <furszy> hi
2012023-10-19T14:01:04  <hebasto> hi
2022023-10-19T14:01:04  <_aj_> hi
2032023-10-19T14:01:05  <achow101> There is 1 pre-proposed meeting topic this week. any last minute ones to add to the list?
2042023-10-19T14:01:07  <gleb> Hi. Poor internet here
2052023-10-19T14:01:18  <fjahr> hi
2062023-10-19T14:01:26  <darosior> Good day
2072023-10-19T14:01:51  <achow101> #topic priority projects
2082023-10-19T14:01:51  <core-meetingbot> topic: priority projects
2092023-10-19T14:02:03  *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Quit: = "")
2102023-10-19T14:02:19  <TheCharlatan> hi
2112023-10-19T14:02:27  <abubakarsadiq> hi
2122023-10-19T14:03:20  <achow101> The final count for the voting is Package relay - 19, Silent payments - 11, Multiprocess - 9, Legacy wallet removal - 9, cmake - 8, erlay - 7 stratum v2 - 4
2132023-10-19T14:03:52  <kanzure> hi
2142023-10-19T14:04:25  <achow101> We decided at CoreDev to go with the top 3 projects instead of 4, so that would be package relay, silent payments, and one of multiprocess or legacy wallet removal.
2152023-10-19T14:04:41  <pinheadmz> ooh a runoff
2162023-10-19T14:05:13  <achow101> i would be happy to have multiprocess as the priority project since legacy wallet removal has a plan to move forward this release anyways
2172023-10-19T14:05:40  <_aj_> i count 9 for cmake?
2182023-10-19T14:05:49  *** SebastianvStaa <SebastianvStaa!~Sebastian@ip-109-43-241-175.web.vodafone.de> has quit IRC (Quit: Client closed)
2192023-10-19T14:05:54  <instagibbs> cmake is happening when it's happening regardless iiuc
2202023-10-19T14:06:01  <_aj_> true :)
2212023-10-19T14:06:03  <instagibbs> Two Weeks(TM) whenever ready
2222023-10-19T14:06:04  <fanquake> Sometime after c++20
2232023-10-19T14:06:13  *** SebastianvStaa <SebastianvStaa!~Sebastian@ip-109-43-241-175.web.vodafone.de> has joined #bitcoin-core-dev
2242023-10-19T14:06:19  <TheCharlatan> ^^
2252023-10-19T14:06:26  <_aj_> fanquake: woah</keanu>
2262023-10-19T14:06:27  <achow101> _aj_: i've not included w0xlt as they aren't in the org, and haven't seemed to be active recently?
2272023-10-19T14:06:42  <_aj_> achow101: ok
2282023-10-19T14:09:07  <achow101> any other thoughts on multiprocess vs. legacy wallet removal?
2292023-10-19T14:09:20  *** guest-127 <guest-127!~guest-127@212.129.86.235> has quit IRC (Quit: Client closed)
2302023-10-19T14:09:38  *** guest-127 <guest-127!~guest-127@212.129.86.235> has joined #bitcoin-core-dev
2312023-10-19T14:10:17  <vasild> which one of mine did you count?
2322023-10-19T14:10:34  <achow101> vasild: the signaling one
2332023-10-19T14:11:05  <instagibbs> legacy wallet removal is your baby, if you think it's fine not being priority it's probably fine?
2342023-10-19T14:11:33  <fjahr> achow101: if you are fine with multiprocessing taking the 3rd spot sounds good to me, I think multiprocess certainly needs more attention to make progress
2352023-10-19T14:11:39  <_aj_> removing code seems easier to rebase than adding code, maybe?
2362023-10-19T14:12:34  <b10c> hi
2372023-10-19T14:12:40  <sipa> hi
2382023-10-19T14:12:42  <achow101> _aj_: you'd think so. but I started rebasing my 2 year old removal branch and it's not a fun time
2392023-10-19T14:13:19  *** VisitingPeer <VisitingPeer!~VisitingP@179.red-2-139-120.dynamicip.rima-tde.net> has joined #bitcoin-core-dev
2402023-10-19T14:14:46  <fjahr> _aj_ I think it's the same, it just depends on how intermingled the change is with the rest of the code.
2412023-10-19T14:14:52  <achow101> is there a tracking issue for multiprocess?
2422023-10-19T14:15:11  <glozow> is ryan here?
2432023-10-19T14:15:16  <instagibbs> ryanofsky ping
2442023-10-19T14:15:24  <sipa> just pinged him IRL
2452023-10-19T14:15:33  <ryanofsky> no, can easily create one
2462023-10-19T14:15:37  <instagibbs> In RimworLd
2472023-10-19T14:15:38  <furszy> I think that people working on the wallet will continue reviewing PRs (or at least I will) vs multiprocess that needs some momentum
2482023-10-19T14:15:43  <fjahr> There are #10102 and https://github.com/bitcoin/bitcoin/projects/10
2492023-10-19T14:15:46  <gribble> https://github.com/bitcoin/bitcoin/issues/10102 | Multiprocess bitcoin by ryanofsky · Pull Request #10102 · bitcoin/bitcoin · GitHub
2502023-10-19T14:16:10  <achow101> https://github.com/orgs/bitcoin/projects/1/views/2 is updated
2512023-10-19T14:16:11  <_aj_> projects/10 is closed/read-only though
2522023-10-19T14:16:22  <stickies-v> there's also https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Process-Separation
2532023-10-19T14:16:43  <ryanofsky> right now all the code is just in 10102, there are many commits that could be split up
2542023-10-19T14:19:11  <achow101> #topic Ad-hoc high priority for review
2552023-10-19T14:19:11  <core-meetingbot> topic: Ad-hoc high priority for review
2562023-10-19T14:19:18  <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
2572023-10-19T14:19:31  <pinheadmz> I wanna shill #27375 again
2582023-10-19T14:19:34  <gribble> https://github.com/bitcoin/bitcoin/issues/27375 | net: support unix domain sockets for -proxy and -onion by pinheadmz · Pull Request #27375 · bitcoin/bitcoin · GitHub
2592023-10-19T14:19:44  <pinheadmz> has 2 ACKs, follwoups will offer unix sockets for rpc and zmq as well
2602023-10-19T14:19:49  <pinheadmz> imagine no more http://localhost!
2612023-10-19T14:21:12  <achow101> cool, will look when we start merging for 27.0
2622023-10-19T14:22:16  <achow101> #topic 26.0 milestone
2632023-10-19T14:22:17  <core-meetingbot> topic: 26.0 milestone
2642023-10-19T14:22:36  <achow101> branching is scheduled for sunday. there's still a bunch of things in the milestone
2652023-10-19T14:22:40  <achow101> https://github.com/bitcoin/bitcoin/milestone/60
2662023-10-19T14:23:00  <achow101> please review them
2672023-10-19T14:23:43  <achow101> #topic Fix for hash_serialized2 calculation and implications (for context see #28675 and #28685) (fjahr)
2682023-10-19T14:23:43  <core-meetingbot> topic: Fix for hash_serialized2 calculation and implications (for context see #28675 and #28685) (fjahr)
2692023-10-19T14:23:43  *** SebastianvStaa <SebastianvStaa!~Sebastian@ip-109-43-241-175.web.vodafone.de> has quit IRC (Ping timeout: 248 seconds)
2702023-10-19T14:23:44  <gribble> https://github.com/bitcoin/bitcoin/issues/28675 | Assumeutxo: Altered txoutset dump is still valid · Issue #28675 · bitcoin/bitcoin · GitHub
2712023-10-19T14:23:45  <gribble> https://github.com/bitcoin/bitcoin/issues/28685 | coinstats, assumeutxo: fix hash_serialized2 calculation by fjahr · Pull Request #28685 · bitcoin/bitcoin · GitHub
2722023-10-19T14:23:46  <gribble> https://github.com/bitcoin/bitcoin/issues/28675 | Assumeutxo: Altered txoutset dump is still valid · Issue #28675 · bitcoin/bitcoin · GitHub
2732023-10-19T14:23:47  <gribble> https://github.com/bitcoin/bitcoin/issues/28685 | coinstats, assumeutxo: fix hash_serialized2 calculation by fjahr · Pull Request #28685 · bitcoin/bitcoin · GitHub
2742023-10-19T14:23:56  <fjahr> tldr; the hash_serialized_2 calculation had a bug as described here by theStack: https://github.com/bitcoin/bitcoin/issues/28675#issuecomment-1770389468 The fix is in #28685 and it will be renamed to hash_serialized_3.
2752023-10-19T14:23:57  <gribble> https://github.com/bitcoin/bitcoin/issues/28685 | coinstats, assumeutxo: fix hash_serialized2 calculation by fjahr · Pull Request #28685 · bitcoin/bitcoin · GitHub
2762023-10-19T14:24:05  <fjahr> This has implications particularly for assumeutxo, the hashes in the chainparams will need to change. But we are also discussing a bunch of additional changes to improve further while we change the resulting hash already.
2772023-10-19T14:24:12  *** SebastianvStaa <SebastianvStaa!~Sebastian@ip-109-43-241-175.web.vodafone.de> has joined #bitcoin-core-dev
2782023-10-19T14:24:37  <fjahr> Particularly dergoegge found another issue with his fuzzer on negative values and proposed to get rid of VARINT completely. I would really like to hear if people would like do that or if we should keep the change more minimal. I have started preparing the change with the VARINTs removed but it would be good to know which one we want now so we only have to change the chainparams once since that causes some significant review
2792023-10-19T14:24:37  <fjahr> effort.
2802023-10-19T14:25:01  <fjahr> To be precise I think we have the choice between getting rid of all VARINTs in kernel/coinstats, getting rid of it just where dergoegge found the issue and leaving it and checking for negative value in deserialization (I guess we will add this check either way).
2812023-10-19T14:25:37  <fjahr> So generally would be good to have a few more eyes on this but particularly looking for feedback on the VARINT question.
2822023-10-19T14:26:01  <sipa> For performance reasons, my guess would be that removing all VARINTs from UTXO hashes is better.
2832023-10-19T14:26:03  <theStack> as commented in the PR, I think removing VARINTs in `ApplyHash` would make sense, but is only an option if that doesn't come with noticable loss in performance
2842023-10-19T14:26:26  <sipa> I suspect that VARINT coding costs per-byte more than SHA256 per-byte.
2852023-10-19T14:26:37  <sipa> But I haven't benchmarked it.
2862023-10-19T14:26:41  <dergoegge> something that also seems weird to me is that the serialization format is different for hashing with muhash
2872023-10-19T14:27:07  <theStack> sipa: oh, interesting, i would have expected it's the other way round. but i don't know too much about sha256 internals TBH
2882023-10-19T14:27:24  <fjahr> I think at the time we already new the muhash one made more sense, just kept the hash_serialized one around for consistency
2892023-10-19T14:27:33  <fjahr> *knew
2902023-10-19T14:27:58  <sipa> SHA256 (without hardware acceleration) is maybe a dozen CPU cycles per byte; varint coding involves lots of branches that can be mispredicted... less work overall, but probably a lot lower ILP
2912023-10-19T14:29:01  <sipa> Does the fact that it may impact chainparams really matter? I can imagine it's likely we want to revisit the actual hashing scheme for assumeutxo before mainnet deployment anyway, depending on how P2P serving would happen.
2922023-10-19T14:29:22  <achow101> was hash_serialized_2 always incorrect?
2932023-10-19T14:29:35  *** VisitingPeer <VisitingPeer!~VisitingP@179.red-2-139-120.dynamicip.rima-tde.net> has quit IRC (Ping timeout: 248 seconds)
2942023-10-19T14:29:36  <fjahr> That would be another option, to apply the MuHash serialization so we are consistent
2952023-10-19T14:29:43  <fjahr> achow101: since 2018
2962023-10-19T14:29:47  <theStack> achow101: i think it's incorrect since v0.17 (see linked commit in the issue)
2972023-10-19T14:30:46  <theStack> at least that's the earliest tag that is shown by `git tag --contains 34ca75032012562d226b06ef9e86a2948d3a8d16`
2982023-10-19T14:30:59  <fjahr> sipa: at least we need to fix the testnet and signet params before the release
2992023-10-19T14:31:45  <sipa> fjahr: that doesn't sound like a big deal
3002023-10-19T14:31:48  <fjahr> not sure when we will even get into p2p distribution, if that's a focus for jamesob for 27
3012023-10-19T14:33:22  <fjahr> sipa: I just would like it if we can come to an agreement now then we don't need another follow-up to 28685
3022023-10-19T14:34:20  <achow101> if we change the serialization, will the coinstatsindex need to be reindexed?
3032023-10-19T14:34:36  <fjahr> no, the hash_serialized is not part of it
3042023-10-19T14:34:55  *** Guest2177 <Guest2177!~diego@186.222.94.177> has quit IRC (Quit: WeeChat 4.1.0)
3052023-10-19T14:35:07  <sipa> i'm happy with either just using the muhash serialization for hash_serialized_3, or keeping VARINT
3062023-10-19T14:35:14  <sipa> but a benchmark would be useful
3072023-10-19T14:35:45  <achow101> why are the serialziations different?
3082023-10-19T14:36:19  <sipa> i suppose because they were designed at different times
3092023-10-19T14:37:15  <fjahr> what I wrote above, I think pieter came up with the one for muhash but we kept the old one for consistency of hash_serialized
3102023-10-19T14:37:36  <sipa> well i think i also came up with the one for hash_serialized
3112023-10-19T14:37:57  <fjahr> :)
3122023-10-19T14:38:11  <sipa> the muhash one is simpler, the hash_serialized one is more compact
3132023-10-19T14:38:17  <achow101> it'd be nice if they were consistent
3142023-10-19T14:38:47  <achow101> but it seems like people don't particularly care?
3152023-10-19T14:39:04  <sipa> for muhash i think performance matters less also, because the serialization cost is probably dwarfed by the muhash math overhead
3162023-10-19T14:39:30  <sipa> can someone benchmark if it matters at all, and if the more compact one is not significantly better, pick the muhash serialization for hash_serialized_3 ?
3172023-10-19T14:39:52  <fjahr> I can run the benchmarks and post them in the PR
3182023-10-19T14:40:27  *** SebastianvStaa <SebastianvStaa!~Sebastian@ip-109-43-241-175.web.vodafone.de> has quit IRC (Quit: Client closed)
3192023-10-19T14:40:30  <sipa> great
3202023-10-19T14:40:32  <achow101> sounds like a plan
3212023-10-19T14:41:01  <achow101> any other topics to discuss?
3222023-10-19T14:41:36  *** pablomartin4btc <pablomartin4btc!~pablomart@193.160.245.175> has joined #bitcoin-core-dev
3232023-10-19T14:42:33  <MacroFake> Is the content hash needed, if the full file hash will be checked in the future?
3242023-10-19T14:42:55  <MacroFake> I guess to protect against the file changing while reading it?
3252023-10-19T14:43:55  <sipa> i could imagine introducing some kind of merkle-structured content hash in the future, that's used as a full file hash too
3262023-10-19T14:44:12  <sipa> but it sounds like there is a lot of design space for that
3272023-10-19T14:45:57  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9e616baec0f2...6e721c923c87
3282023-10-19T14:45:57  <bitcoin-git> bitcoin/master 2338715 fanquake: doc: add historical release notes for 25.1
3292023-10-19T14:45:58  <bitcoin-git> bitcoin/master 6e721c9 fanquake: Merge bitcoin/bitcoin#28667: doc: add historical release notes for 25.1
3302023-10-19T14:46:03  <bitcoin-git> [bitcoin] fanquake merged pull request #28667: doc: add historical release notes for 25.1 (master...add_25_1_rel_notes) https://github.com/bitcoin/bitcoin/pull/28667
3312023-10-19T14:46:04  <MacroFake> Are you saying with your proposal the full file hash would be equal to the content hash?
3322023-10-19T14:46:49  *** pablomartin <pablomartin!~pablomart@193.160.245.176> has joined #bitcoin-core-dev
3332023-10-19T14:46:53  <MacroFake> (With full file hash I mean the dumb hash of the byte file, without parsing the content or looking at it)
3342023-10-19T14:47:01  <fjahr> I think flat file hash might be limiting as a hard requirement when we think about p2p distribution, not sure if it makes sense as temporary belt and suspenders
3352023-10-19T14:47:26  <sipa> no; i'm saying you'd verify the full file by computing its contents hash... which is designed in such a way that it's easy to validate the serialized file (and chunks of it) against
3362023-10-19T14:47:27  *** BlueMatt[m] <BlueMatt[m]!~bluematt@2620:6e:a000:ce11::d> has quit IRC (Ping timeout: 240 seconds)
3372023-10-19T14:47:42  <sipa> and not having a dumb hash of the file at all
3382023-10-19T14:47:51  *** pablomartin4btc <pablomartin4btc!~pablomart@193.160.245.175> has quit IRC (Ping timeout: 240 seconds)
3392023-10-19T14:49:00  <sipa> i guess there could also be a dumb hash of the whole file as a final last-resort check, but for P2P distribution you really need a way to check for incorrect chunks very early anyway
3402023-10-19T14:51:10  <sipa> i guess it could be a tree-structured hash over the serialized file (and not over individual utxo entries in it)?
3412023-10-19T14:52:12  <achow101> seems like something that requires more thought than we can do for a fix for this release
3422023-10-19T14:52:13  <sipa> but this doesn't need to be part of this meeting, i think
3432023-10-19T14:52:30  <achow101> #endmeeting
3442023-10-19T14:52:30  <core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Weekly Meeting Thursday @ 14:00 UTC | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
3452023-10-19T14:52:30  <core-meetingbot> Meeting ended Thu Oct 19 14:52:30 2023 UTC.
3462023-10-19T14:52:30  <core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2023/bitcoin-core-dev.2023-10-19-14.00.moin.txt
3472023-10-19T14:52:35  <MacroFake> [16:51] <sipa> i guess it could be a tree-structured hash over the serialized file (and not over individual utxo entries in it)?
3482023-10-19T14:52:50  *** guest-127 <guest-127!~guest-127@212.129.86.235> has quit IRC (Quit: Client closed)
3492023-10-19T14:52:56  <MacroFake> Yes, that is what I thought, but agree, no need to be part of the meeting
3502023-10-19T14:53:12  <sipa> Well, it's not anymore!
3512023-10-19T14:53:33  <_aj_> if you're generating something, i don't quite see why you wouldn't just make a .torrent file of the serialized utxo set?
3522023-10-19T14:54:16  <sipa> _aj_: and then store a hash of the torrent file as assumeutxo hash?
3532023-10-19T14:54:24  <_aj_> sipa: yeah
3542023-10-19T14:54:34  <sipa> i guess that is a tree-structured hash (with just 2 levels of tree)
3552023-10-19T14:54:38  <_aj_> sipa: along with the hash_serialized_3 or muhash, to verify it
3562023-10-19T14:56:14  <sipa> i was more thinking along the lines of SHA256'ing say 4 KiB chunks of the serialized file, and then build a Merkle tree over those hashes, and make that the file hash
3572023-10-19T14:56:41  <sipa> and then whenever you download a (range of) chunks from someone, they'd give a Merkle path to connect it to the file hash
3582023-10-19T14:57:10  <sipa> this gives a lot of freedom later in how to schedule the downloading
3592023-10-19T14:59:56  <sipa> i picked 4 KiB because it's as small as you can go while retaining the property that the Merkle overhead is negligible in bandwidth/cpu compared to the data itself
3602023-10-19T14:59:57  <_aj_> sipa: i just wonder if there's much overlap between p2p distribution of old chainstate vs keeping a node up to date, and if we'd effectively just be reimplementing bittorrent?
3612023-10-19T15:00:28  *** pablomartin <pablomartin!~pablomart@193.160.245.176> has quit IRC (Ping timeout: 255 seconds)
3622023-10-19T15:00:59  <_aj_> sipa: like where are we storing the old serialized utxo set? block data somehow? ldb snapshot? somewhere else? is that better than just having it dumped to disk as a file?
3632023-10-19T15:01:12  <sipa> that's a fair point... the distribution mechanism (if it's done entirely using file-level hashes) is effectively bittorrent
3642023-10-19T15:02:12  *** BlueMatt[m] <BlueMatt[m]!~bluematt@2620:6e:a000:ce11::d> has joined #bitcoin-core-dev
3652023-10-19T15:02:19  <_aj_> sipa: and especially for "version 0.1", might be worth just getting something that's quick and works?
3662023-10-19T15:02:19  <sipa> how the whole snapshotting happens isn't something i've thought too hard about
3672023-10-19T15:02:40  <sipa> because that's the other side of this... we don't just need easy distribution, but also easy creation
3682023-10-19T15:04:00  <_aj_> it doesn't need to be that easy to create? one person creates -- everyone else downloads, and verifies the muhash against coinstatsindex?
3692023-10-19T15:04:50  <sipa> _aj_: well if we want P2P fetching then you need to be able to fetch from nodes that just have been running, and didn't themself bootstrap from the snapshot
3702023-10-19T15:06:57  <sipa> so for that the snapshotting needs to be efficient and deterministic (at least deterministic w.r.t. whatever hash mechanism is used for validating fetching)
3712023-10-19T15:07:02  <_aj_> sipa: depends if the p2p is over the bitcoin network or over a bittorrent network?
3722023-10-19T15:07:24  <sipa> _aj_: oh you mean *actually* bittorrent
3732023-10-19T15:07:35  <_aj_> sipa: as a strawman at least, yeah
3742023-10-19T15:08:55  <sipa> i think it'd be nice if fetching utxo snapshots can happen from random network nodes, but admittedly it is a very different problem than what's served now
3752023-10-19T15:09:03  <_aj_> sipa: fanquake updates chainparams. stops his bitcoind node. generates the serializaed snapshot at height X. publishes the torrent file. others vet it. ACK the PR. torrent file is published in bitcoincore.org, and seeded by random folks?
3762023-10-19T15:09:48  <sipa> do we ship a bittorrent client inside bitcoin core?
3772023-10-19T15:10:17  <sipa> or do you need to manually run a bittorrent client to get the snapshot file?
3782023-10-19T15:10:22  <_aj_> sipa: i think it'd be nice too; but i think making your node do that would be the exact same resource usage as being a bittorrent seeder of the same data? like, you'd need an extra copy of the utxo set, and have an extra bunch of p2p messages equivalent to the bittorrent protocol?
3792023-10-19T15:10:40  *** mraugust <mraugust!~mraugust@185.199.102.30> has joined #bitcoin-core-dev
3802023-10-19T15:11:13  <_aj_> sipa: presumably it wouldn't be a default config option due to the extra resources? and that selecting the snapshot height is probably a manual thing that code can't automatically adopt?
3812023-10-19T15:11:37  <_aj_> sipa: strawman: manually run a bittorrent client?
3822023-10-19T15:12:32  <sipa> i was imagining that nodes would automatically make snapshots at predetermined heights, and be able to serve the last few - through some sharding mechanism that this doesn't result in storing 3-4 full chainsate copies
3832023-10-19T15:13:08  <_aj_> hmm, is there any recent data about how quickly things cycle through the utxo set?
3842023-10-19T15:13:42  <sipa> _aj_: if users have to run a bittorrent client manually, i worry that someone will just offer chainstates instead, which are just as easy to distribute and faster to load
3852023-10-19T15:14:30  <sipa> so i think if we want to think about any kind of distribution mechanism, the goal is actually to be that it becomes *the* easiest way to bootstrap a node
3862023-10-19T15:16:45  <_aj_> could we structure the snapshot so that it's super fast to import into a chainstate?
3872023-10-19T15:21:55  <sipa> unsure
3882023-10-19T15:25:19  *** gerle <gerle!~quassel@212-186-78-187.static.upcbusiness.at> has quit IRC (Quit: https://quassel-irc.org - Komfortabler Chat. Überall.)
3892023-10-19T15:30:48  <_aj_> presuming we have a hardcoded merkle root, presumably we want to have many peers like bittorrent, rather than only outgoings like IBD, and also relay the chunks we've downloaded and checked to other peers
3902023-10-19T15:33:06  *** brunoerg <brunoerg!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has joined #bitcoin-core-dev
3912023-10-19T15:35:53  *** DarrylTheFiiish <DarrylTheFiiish!~DarrylThe@user/DarrylTheFish> has quit IRC (Remote host closed the connection)
3922023-10-19T15:40:35  *** brunoerg_ <brunoerg_!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has joined #bitcoin-core-dev
3932023-10-19T15:40:51  *** brunoerg <brunoerg!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has quit IRC (Read error: Connection reset by peer)
3942023-10-19T15:41:58  <_aj_> sipa: i find myself fairly convinced by the "why not just bittorrent chainstate/ directly". new strawman: just dumptxoutset every 25000 blocks, and serve that; but only keep the most recent 3 of them? it's an extra 30GB but on a full node that's got 600GB anyway, that's not that terrible?
3952023-10-19T15:44:04  <sipa> _aj_: that's not terrible; i think it'd be nicer if we could let pruned nodes also participate in the serving
3962023-10-19T15:47:15  <sipa> and with FEC, that's not impossible; say you use an 8-bit 255/16 RS code... so now UTXO-serving nodes can choose to store between 18.75% (3/16) of a UTXO set and 300% of a UTXO set (if they keep 3 snapshots)
3972023-10-19T15:48:11  <sipa> and to bootstrap, you need to just find a set of peers that together have 16 distinct shards
3982023-10-19T15:52:01  <sipa> sadly, unless the merkle tree structure commits to all FEC shards, you can't validate individual pieces of coding until you have all 16 for a given chunk
3992023-10-19T15:53:06  <_aj_> i'm not following the shard vs chunk split?
4002023-10-19T15:53:27  <_aj_> if you're 3/16, are you keeping 3 shards of every chunk?
4012023-10-19T15:53:56  <sipa> so the idea is the file is split up in chunks, say 4 KiB each
4022023-10-19T15:54:42  <sipa> these chunks get FEC coded in a way that 16 shards of chunk (each 512 bytes) are sufficient to reconstruct it
4032023-10-19T15:55:23  <sipa> but each chunk has 255 possible shards, and every node would pick between 1 and 16 distinct integers in range 0..255, and keep those shards for each chunk
4042023-10-19T15:56:12  <sipa> so whenever you have 16 distinct shards for a chunk, you can reconstruct the chunk
4052023-10-19T15:58:24  <sipa> but by offering 255 possibilities rather than just 16, you now don't need to find a set of peers that together offer all 16... any 16 out of 255 suffices
4062023-10-19T16:04:58  <_aj_> 512B*16=8KiB not 4KiB? is that a lot of error detection or typo?
4072023-10-19T16:07:15  <_aj_> filling in missing data as a 2d puzzle seems complex, i guess; do i get shards 1-16 for chunk 5 from peer 1, or shard 1 for chunk 10-26? i guess you just throw enough peers at the problem and it's fine though
4082023-10-19T16:08:10  <sipa> brb, lunch
4092023-10-19T16:11:18  <sipa> _aj_: err yes 256B, not 512B
4102023-10-19T16:12:20  *** brunoerg_ <brunoerg_!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has quit IRC (Read error: Connection reset by peer)
4112023-10-19T16:12:42  *** brunoerg <brunoerg!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has joined #bitcoin-core-dev
4122023-10-19T16:16:49  <_aj_> seems like you should rarely need more than 6 peers, even with only 3 shards each
4132023-10-19T16:18:31  *** brunoerg_ <brunoerg_!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has joined #bitcoin-core-dev
4142023-10-19T16:18:33  *** brunoerg <brunoerg!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has quit IRC (Read error: Connection reset by peer)
4152023-10-19T16:22:31  <sipa> _aj_: so one way of looking at it, is it expands every 4 KiB chunk into 255/16 * 4 KiB = 63.75 KiB of data... but you can reconstruct the whole thing with *any* 4 KiB out of those 63.75 KiB; so each node can choose to store some subset of those 63.75 KiB only
4162023-10-19T16:22:39  *** jQrgen <jQrgen!~jQrgen@2001:8c0:ea04:37:fd50:6346:e4a3:11dc> has joined #bitcoin-core-dev
4172023-10-19T16:23:52  <sipa> (but aligned with 256B boundaries(
4182023-10-19T16:26:11  *** preimage <preimage!~halosghos@user/halosghost> has joined #bitcoin-core-dev
4192023-10-19T16:28:07  <_aj_> sipa: so this would kind of be `dumptxoutshards 65 115 252` (which does dumptxoutset but also does FEC calculations but also potentially is 3/16th of the size) every 20k blocks, then you serve those for 20k/40k/60k blocks, then you delete them.
4202023-10-19T16:28:47  *** test_ <test_!flooded@gateway/vpn/protonvpn/flood/x-43489060> has joined #bitcoin-core-dev
4212023-10-19T16:29:55  <_aj_> i guess if we can get pruned nodes to serve the data, there's less need for nodes that are still downloading the data to serve it out to others; that would let you download the data in order, rather than randomly. that might then let you import it into leveldb as you download it?
4222023-10-19T16:30:12  *** ibiko1 <ibiko1!~ibiko1@170.253.45.108> has joined #bitcoin-core-dev
4232023-10-19T16:31:51  *** flooded <flooded!flooded@gateway/vpn/protonvpn/flood/x-43489060> has quit IRC (Ping timeout: 240 seconds)
4242023-10-19T16:34:43  *** ibiko1 <ibiko1!~ibiko1@170.253.45.108> has quit IRC (Ping timeout: 252 seconds)
4252023-10-19T16:46:43  *** brunoerg_ <brunoerg_!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has quit IRC (Remote host closed the connection)
4262023-10-19T16:47:46  *** brunoerg <brunoerg!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has joined #bitcoin-core-dev
4272023-10-19T16:49:04  <bitcoin-git> [bitcoin] achow101 pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/6e721c923c87...0655e9dd92ea
4282023-10-19T16:49:05  <bitcoin-git> bitcoin/master 64d6f77 Vasil Dimov: net: put CJDNS prefix byte in a constant
4292023-10-19T16:49:05  <bitcoin-git> bitcoin/master c42ded3 Vasil Dimov: fuzz: ConsumeNetAddr(): avoid IPv6 addresses that look like CJDNS
4302023-10-19T16:49:05  <bitcoin-git> bitcoin/master 6e30865 Vasil Dimov: net: move IsReachable() code to netbase and encapsulate it
4312023-10-19T16:49:10  <bitcoin-git> [bitcoin] achow101 merged pull request #27071: Handle CJDNS from LookupSubNet() (master...lookup_subnet_cjdns) https://github.com/bitcoin/bitcoin/pull/27071
4322023-10-19T17:04:52  *** brunoerg <brunoerg!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has quit IRC (Remote host closed the connection)
4332023-10-19T17:05:02  *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
4342023-10-19T17:06:40  *** mraugust <mraugust!~mraugust@185.199.102.30> has quit IRC (Quit: Client closed)
4352023-10-19T17:09:01  *** brunoerg <brunoerg!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has joined #bitcoin-core-dev
4362023-10-19T17:14:56  *** brunoerg <brunoerg!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has quit IRC (Remote host closed the connection)
4372023-10-19T17:24:47  *** ___nick___ <___nick___!~quassel@host86-130-0-61.range86-130.btcentralplus.com> has joined #bitcoin-core-dev
4382023-10-19T17:25:01  *** ___nick___ <___nick___!~quassel@host86-130-0-61.range86-130.btcentralplus.com> has quit IRC (Client Quit)
4392023-10-19T17:26:52  *** ___nick___ <___nick___!~quassel@host86-130-0-61.range86-130.btcentralplus.com> has joined #bitcoin-core-dev
4402023-10-19T17:31:34  *** achow101 <achow101!~achow101@user/achow101> has quit IRC (Remote host closed the connection)
4412023-10-19T17:32:12  *** achow101 <achow101!~achow101@user/achow101> has joined #bitcoin-core-dev
4422023-10-19T17:53:50  *** Guest91 <Guest91!~Guest77@adsl-109-200-172-56.dynamic.yemennet.ye> has joined #bitcoin-core-dev
4432023-10-19T17:53:57  *** Guest91 <Guest91!~Guest77@adsl-109-200-172-56.dynamic.yemennet.ye> has quit IRC (Client Quit)
4442023-10-19T18:13:49  *** Evel-Knievel <Evel-Knievel!~Evel-Knie@user/evel-knievel> has quit IRC (Ping timeout: 255 seconds)
4452023-10-19T18:14:43  *** Evel-Knievel <Evel-Knievel!~Evel-Knie@user/evel-knievel> has joined #bitcoin-core-dev
4462023-10-19T18:32:12  *** jQrgen <jQrgen!~jQrgen@2001:8c0:ea04:37:fd50:6346:e4a3:11dc> has quit IRC ()
4472023-10-19T18:47:55  *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
4482023-10-19T18:48:42  *** pablomartin <pablomartin!~pablomart@193.160.245.181> has joined #bitcoin-core-dev
4492023-10-19T19:04:05  *** ibiko1 <ibiko1!~ibiko1@170.253.45.108> has joined #bitcoin-core-dev
4502023-10-19T19:05:38  *** ibiko1_ <ibiko1_!~ibiko1@170.253.45.108> has joined #bitcoin-core-dev
4512023-10-19T19:08:29  *** ibiko1 <ibiko1!~ibiko1@170.253.45.108> has quit IRC (Ping timeout: 255 seconds)
4522023-10-19T19:32:44  *** abubakarsadiq <abubakarsadiq!uid602234@id-602234.hampstead.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
4532023-10-19T19:43:57  *** brunoerg <brunoerg!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has joined #bitcoin-core-dev
4542023-10-19T19:51:01  *** ibiko1_ <ibiko1_!~ibiko1@170.253.45.108> has quit IRC (Ping timeout: 255 seconds)
4552023-10-19T20:03:54  *** ___nick___ <___nick___!~quassel@host86-130-0-61.range86-130.btcentralplus.com> has quit IRC (Ping timeout: 246 seconds)
4562023-10-19T20:08:23  <bitcoin-git> [bitcoin] achow101 pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/0655e9dd92ea...77f0ceb7175d
4572023-10-19T20:08:24  <bitcoin-git> bitcoin/master 762404a Vasil Dimov: i2p: also sleep after errors in Accept()
4582023-10-19T20:08:24  <bitcoin-git> bitcoin/master 5c8e15c Vasil Dimov: i2p: destroy the session if we get an unexpected error from the I2P router
4592023-10-19T20:08:25  <bitcoin-git> bitcoin/master 77f0ceb Andrew Chow: Merge bitcoin/bitcoin#28077: I2P: also sleep after errors in Accept() & de...
4602023-10-19T20:08:30  <bitcoin-git> [bitcoin] achow101 merged pull request #28077: I2P: also sleep after errors in Accept() & destroy the session if we get an unexpected error (master...i2p_accept_issue22759) https://github.com/bitcoin/bitcoin/pull/28077
4612023-10-19T20:13:10  *** realies <realies!~realies@user/realies> has joined #bitcoin-core-dev
4622023-10-19T20:25:12  <theStack> wouldn't it be nice if utxo dumps had magic bytes (probably with a version) at the beginning so they could be easily identified as such? for better error handling ("this is not an UTXO dump"), but also long-term for utilities like file(1)
4632023-10-19T20:41:29  *** VisitingPeer <VisitingPeer!~VisitingP@179.red-2-139-120.dynamicip.rima-tde.net> has joined #bitcoin-core-dev
4642023-10-19T20:41:45  *** VisitingPeer <VisitingPeer!~VisitingP@179.red-2-139-120.dynamicip.rima-tde.net> has quit IRC (Client Quit)
4652023-10-19T20:45:20  *** realies <realies!~realies@user/realies> has quit IRC (Ping timeout: 255 seconds)
4662023-10-19T20:46:40  *** Guest7 <Guest7!~Guest7@2401:f540:7:2010::76ad> has joined #bitcoin-core-dev
4672023-10-19T20:47:47  *** vysn <vysn!~vysn@user/vysn> has joined #bitcoin-core-dev
4682023-10-19T20:50:19  <jamesob> Apologies I missed the meeting today, and great job to all involved diagnosing and fixing. I have no intention of doing p2p distribution of snapshots, so someone else will have to tackle that if it is desired; I'm honestly not sure that juice is worth the squeeze.
4692023-10-19T20:51:20  <jamesob> In any case, it would be a shame to see a very useful feature held up by deciding on what the perfect hash structure is; that can always be changed later afaict
4702023-10-19T20:57:47  *** brunoerg <brunoerg!~brunoerg@2001:12d0:2080:2800:172:26:0:80a> has quit IRC (Remote host closed the connection)
4712023-10-19T21:02:24  *** brunoerg <brunoerg!~brunoerg@143.107.231.30> has joined #bitcoin-core-dev
4722023-10-19T21:12:40  *** p <p!~p@194.195.91.36> has joined #bitcoin-core-dev
4732023-10-19T21:13:04  *** p is now known as Guest7362
4742023-10-19T21:13:12  *** Robotico <Robotico!~101@2a0c:5a84:3200:6400:649d:1d81:c9ce:2a4c> has joined #bitcoin-core-dev
4752023-10-19T21:15:09  *** Guest7362 <Guest7362!~p@194.195.91.36> has quit IRC (Client Quit)
4762023-10-19T21:15:29  *** paddingtonbear <paddingtonbear!~paddingto@194.195.91.33> has joined #bitcoin-core-dev
4772023-10-19T21:18:50  *** Robotiko <Robotiko!~101@2a0c:5a84:3200:6400:866d:6046:f377:313d> has joined #bitcoin-core-dev
4782023-10-19T21:18:55  *** Robotico <Robotico!~101@2a0c:5a84:3200:6400:649d:1d81:c9ce:2a4c> has quit IRC (Quit: Leaving)
4792023-10-19T21:19:00  *** Robotiko <Robotiko!~101@2a0c:5a84:3200:6400:866d:6046:f377:313d> has quit IRC (Remote host closed the connection)
4802023-10-19T21:19:16  *** Robotico <Robotico!~101@2a0c:5a84:3200:6400:866d:6046:f377:313d> has joined #bitcoin-core-dev
4812023-10-19T21:19:25  *** Robotico <Robotico!~101@2a0c:5a84:3200:6400:866d:6046:f377:313d> has quit IRC (Remote host closed the connection)
4822023-10-19T21:20:48  *** realies <realies!~realies@user/realies> has joined #bitcoin-core-dev
4832023-10-19T21:23:02  <paddingtonbear> hey - i can learn more than i can teach here - but was sent by someone to discuss the bitcoind upstream issue
4842023-10-19T21:23:15  <paddingtonbear> this is x.com/123456 (pad)
4852023-10-19T21:23:34  <paddingtonbear> happy to talk in dms or in broad daylight haha
4862023-10-19T21:28:35  *** brunoerg <brunoerg!~brunoerg@143.107.231.30> has quit IRC (Remote host closed the connection)
4872023-10-19T21:34:36  *** realies1 <realies1!~realies@user/realies> has joined #bitcoin-core-dev
4882023-10-19T21:35:51  *** realies <realies!~realies@user/realies> has quit IRC (Ping timeout: 240 seconds)
4892023-10-19T21:35:51  *** realies1 is now known as realies
4902023-10-19T21:50:39  *** realies <realies!~realies@user/realies> has quit IRC (Ping timeout: 240 seconds)
4912023-10-19T21:55:29  *** preimage <preimage!~halosghos@user/halosghost> has quit IRC (Quit: WeeChat 4.1.0)
4922023-10-19T22:02:49  *** realies <realies!~realies@user/realies> has joined #bitcoin-core-dev
4932023-10-19T22:06:55  *** flooded <flooded!flooded@gateway/vpn/protonvpn/flood/x-43489060> has joined #bitcoin-core-dev
4942023-10-19T22:10:36  *** test_ <test_!flooded@gateway/vpn/protonvpn/flood/x-43489060> has quit IRC (Ping timeout: 240 seconds)
4952023-10-19T22:19:39  *** aureleoules <aureleoules!~aureleoul@82-64-162-213.subs.proxad.net> has quit IRC (Ping timeout: 245 seconds)
4962023-10-19T22:32:58  *** aureleoules <aureleoules!~aureleoul@82-64-162-213.subs.proxad.net> has joined #bitcoin-core-dev
4972023-10-19T23:13:17  *** jamesob <jamesob!~jamesob@108.44.248.162> has quit IRC (Ping timeout: 255 seconds)
4982023-10-19T23:29:44  *** Guest7 <Guest7!~Guest7@2401:f540:7:2010::76ad> has quit IRC (Quit: Client closed)
4992023-10-19T23:47:17  *** brunoerg <brunoerg!~brunoerg@2804:14d:5281:8c2e:5d45:8de:e791:79a8> has joined #bitcoin-core-dev
5002023-10-19T23:48:17  *** vysn <vysn!~vysn@user/vysn> has quit IRC (Remote host closed the connection)
5012023-10-19T23:51:55  *** brunoerg <brunoerg!~brunoerg@2804:14d:5281:8c2e:5d45:8de:e791:79a8> has quit IRC (Ping timeout: 264 seconds)