12025-05-14T00:06:09 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 248 seconds)
22025-05-14T00:07:50 *** Cory38 <Cory38!~Cory38@user/pasha> has quit IRC (Quit: Client closed)
32025-05-14T00:08:06 *** Cory38 <Cory38!~Cory38@user/pasha> has joined #bitcoin-core-dev
42025-05-14T00:44:50 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 260 seconds)
52025-05-14T00:45:46 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:682b:a9d9:9b1d:907b> has quit IRC (Quit: Leaving)
62025-05-14T00:46:03 *** pyth <pyth!~pyth@user/pyth> has joined #bitcoin-core-dev
72025-05-14T00:46:24 *** szarka <szarka!~szarka@2603:3003:4eac:100:682b:a9d9:9b1d:907b> has joined #bitcoin-core-dev
82025-05-14T00:56:25 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
92025-05-14T01:00:59 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 260 seconds)
102025-05-14T01:11:49 *** pyth <pyth!~pyth@user/pyth> has quit IRC (Read error: Connection reset by peer)
112025-05-14T01:14:14 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
122025-05-14T01:18:19 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 245 seconds)
132025-05-14T01:18:43 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
142025-05-14T01:33:39 *** MrHAPPY <MrHAPPY!~pxq@user/MrHAPPY> has joined #bitcoin-core-dev
152025-05-14T01:41:37 *** twistedline <twistedline!~bitcoin@185.193.125.44> has quit IRC ()
162025-05-14T02:16:11 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has quit IRC (Quit: leaving)
172025-05-14T02:34:08 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
182025-05-14T03:20:11 *** adil <adil!~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a> has joined #bitcoin-core-dev
192025-05-14T03:42:01 *** MrHAPPY <MrHAPPY!~pxq@user/MrHAPPY> has quit IRC ()
202025-05-14T04:01:01 *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
212025-05-14T04:01:32 *** cmirror <cmirror!~cmirror@4.53.92.114> has joined #bitcoin-core-dev
222025-05-14T04:02:37 *** twistedline <twistedline!~bitcoin@185.193.125.44> has joined #bitcoin-core-dev
232025-05-14T04:13:41 *** jon_atack <jon_atack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 248 seconds)
242025-05-14T04:17:50 *** jimhhq <jimhhq!~jimhhq@srv779079.hstgr.cloud> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)
252025-05-14T04:17:59 *** jimhhq <jimhhq!~jimhhq@srv779079.hstgr.cloud> has joined #bitcoin-core-dev
262025-05-14T04:19:01 *** andytoshi <andytoshi!~apoelstra@user/andytoshi> has quit IRC (Ping timeout: 248 seconds)
272025-05-14T04:21:21 *** andytoshi <andytoshi!~apoelstra@user/andytoshi> has joined #bitcoin-core-dev
282025-05-14T04:44:32 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 276 seconds)
292025-05-14T04:48:42 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has quit IRC (Remote host closed the connection)
302025-05-14T04:48:55 *** ghost43_ <ghost43_!~ghost43@gateway/tor-sasl/ghost43> has joined #bitcoin-core-dev
312025-05-14T04:57:39 *** Christoph_ <Christoph_!~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e> has joined #bitcoin-core-dev
322025-05-14T04:59:45 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
332025-05-14T05:21:05 *** instagibbs7 <instagibbs7!~instagibb@pool-100-15-116-202.washdc.fios.verizon.net> has joined #bitcoin-core-dev
342025-05-14T05:21:22 *** instagibbs <instagibbs!~instagibb@pool-100-15-116-202.washdc.fios.verizon.net> has quit IRC (Ping timeout: 248 seconds)
352025-05-14T05:21:22 *** instagibbs7 is now known as instagibbs
362025-05-14T05:25:41 *** saikasyap <saikasyap!~saikasyap@2601:241:8500:8db0:f4e5:e0d:df17:997c> has joined #bitcoin-core-dev
372025-05-14T05:40:15 *** AtleoS <AtleoS!~AtleoS@user/AtleoS> has joined #bitcoin-core-dev
382025-05-14T05:45:54 *** saikasyap <saikasyap!~saikasyap@2601:241:8500:8db0:f4e5:e0d:df17:997c> has quit IRC (Quit: Client closed)
392025-05-14T05:52:31 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 268 seconds)
402025-05-14T05:55:07 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
412025-05-14T06:06:50 *** seaner <seaner!~sean@203-132-94-86.ip4.superloop.au> has joined #bitcoin-core-dev
422025-05-14T06:10:47 *** ghost43_ <ghost43_!~ghost43@gateway/tor-sasl/ghost43> has quit IRC (Quit: Leaving)
432025-05-14T06:11:07 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has joined #bitcoin-core-dev
442025-05-14T06:16:11 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 276 seconds)
452025-05-14T06:28:19 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
462025-05-14T06:32:53 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 248 seconds)
472025-05-14T06:39:20 *** AtleoS <AtleoS!~AtleoS@user/AtleoS> has quit IRC (Quit: AtleoS)
482025-05-14T07:18:38 *** PaperSword1 <PaperSword1!~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com> has joined #bitcoin-core-dev
492025-05-14T07:20:28 *** PaperSword <PaperSword!~Thunderbi@securemail.qrsnap.io> has quit IRC (Ping timeout: 265 seconds)
502025-05-14T07:20:28 *** PaperSword1 is now known as PaperSword
512025-05-14T07:23:02 *** adil <adil!~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a> has quit IRC (Quit: adil)
522025-05-14T07:23:23 *** adil <adil!~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a> has joined #bitcoin-core-dev
532025-05-14T07:52:13 *** adil <adil!~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a> has quit IRC (Ping timeout: 272 seconds)
542025-05-14T07:54:44 *** adil <adil!~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a> has joined #bitcoin-core-dev
552025-05-14T07:56:23 <bitcoin-git> [bitcoin] maflcko opened pull request #32490: refactor: Remove UB in prevector reverse iterators (master...2505-less-UB) https://github.com/bitcoin/bitcoin/pull/32490
562025-05-14T07:58:47 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
572025-05-14T08:03:19 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 245 seconds)
582025-05-14T08:26:38 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
592025-05-14T08:29:33 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
602025-05-14T08:31:27 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 276 seconds)
612025-05-14T08:34:42 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 276 seconds)
622025-05-14T08:53:49 <bitcoin-git> [bitcoin] fanquake opened pull request #32491: build: document why we check for `std::system` (master...document_std_system) https://github.com/bitcoin/bitcoin/pull/32491
632025-05-14T08:56:09 *** Christoph_ <Christoph_!~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e> has quit IRC (Quit: Christoph_)
642025-05-14T09:01:15 *** Christoph_ <Christoph_!~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e> has joined #bitcoin-core-dev
652025-05-14T09:12:09 *** Christoph_ <Christoph_!~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e> has quit IRC (Ping timeout: 260 seconds)
662025-05-14T09:13:37 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
672025-05-14T09:15:40 *** sliv3r__ <sliv3r__!~sliv3r__@user/sliv3r-:76883> has quit IRC (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in)
682025-05-14T09:16:04 *** sliv3r__ <sliv3r__!~sliv3r__@user/sliv3r-:76883> has joined #bitcoin-core-dev
692025-05-14T09:16:56 *** adil <adil!~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a> has quit IRC (Quit: adil)
702025-05-14T09:17:16 *** adil <adil!~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a> has joined #bitcoin-core-dev
712025-05-14T09:32:35 *** Guest5203 <Guest5203!~diego@177.34.235.126> has left #bitcoin-core-dev
722025-05-14T09:33:17 *** dviola <dviola!~diego@user/dviola> has joined #bitcoin-core-dev
732025-05-14T09:53:50 *** robobub <robobub!uid248673@id-248673.uxbridge.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
742025-05-14T09:58:30 <bitcoin-git> [bitcoin] fanquake opened pull request #32492: test: add skip_if_running_under_valgrind() (master...functional_tracepoints_skip_valgrind) https://github.com/bitcoin/bitcoin/pull/32492
752025-05-14T10:03:38 *** jarthur <jarthur!~jarthur@user/jarthur> has quit IRC (Quit: jarthur)
762025-05-14T10:21:44 *** purpleKarrot <purpleKarrot!~purpleKar@user/purpleKarrot> has joined #bitcoin-core-dev
772025-05-14T10:26:40 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
782025-05-14T10:30:48 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 252 seconds)
792025-05-14T10:33:10 *** antanst <antanst!~antanst@user/antanst> has quit IRC (Quit: The Lounge - https://thelounge.chat)
802025-05-14T10:34:56 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
812025-05-14T10:35:16 *** Cory38 <Cory38!~Cory38@user/pasha> has quit IRC (Quit: Client closed)
822025-05-14T10:35:34 *** Cory38 <Cory38!~Cory38@user/pasha> has joined #bitcoin-core-dev
832025-05-14T10:36:10 *** Cory38 <Cory38!~Cory38@user/pasha> has quit IRC (Client Quit)
842025-05-14T10:36:24 *** Cory38 <Cory38!~Cory38@user/pasha> has joined #bitcoin-core-dev
852025-05-14T10:36:28 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f9d8910539a2...8a65f0389464
862025-05-14T10:36:28 <bitcoin-git> bitcoin/master fa427ff MarcoFalke: fuzz: Properly setup wallet in wallet_fees target
872025-05-14T10:36:29 <bitcoin-git> bitcoin/master 8a65f03 merge-script: Merge bitcoin/bitcoin#32488: fuzz: Properly setup wallet in wallet_fees ta...
882025-05-14T10:36:30 <bitcoin-git> [bitcoin] fanquake merged pull request #32488: fuzz: Properly setup wallet in wallet_fees target (master...2505-fuzz-fix) https://github.com/bitcoin/bitcoin/pull/32488
892025-05-14T10:40:04 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 276 seconds)
902025-05-14T10:44:13 *** antanst <antanst!~antanst@user/antanst> has joined #bitcoin-core-dev
912025-05-14T10:45:35 *** PaperSword1 <PaperSword1!~Thunderbi@securemail.qrsnap.io> has joined #bitcoin-core-dev
922025-05-14T10:45:58 *** Guest1757 <Guest1757!~ubuntu@197.237.108.217> has joined #bitcoin-core-dev
932025-05-14T10:46:57 *** PaperSword <PaperSword!~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com> has quit IRC (Ping timeout: 244 seconds)
942025-05-14T10:46:57 *** PaperSword1 is now known as PaperSword
952025-05-14T10:59:34 *** Holz_ <Holz_!~Holz@user/Holz> has quit IRC (Ping timeout: 244 seconds)
962025-05-14T11:22:02 *** mudsip <mudsip!~mudsip@user/mudsip> has joined #bitcoin-core-dev
972025-05-14T11:24:28 *** mudsip <mudsip!~mudsip@user/mudsip> has quit IRC (Client Quit)
982025-05-14T11:28:06 *** purpleKarrot <purpleKarrot!~purpleKar@user/purpleKarrot> has quit IRC (Quit: purpleKarrot)
992025-05-14T11:31:42 *** adil <adil!~Thunderbi@2402:d000:8134:2f97:fd2b:190:2281:968a> has quit IRC (Quit: adil)
1002025-05-14T11:37:25 *** purpleKarrot <purpleKarrot!~purpleKar@user/purpleKarrot> has joined #bitcoin-core-dev
1012025-05-14T11:45:55 <bitcoin-git> [bitcoin] fanquake opened pull request #32496: depends: add Qt `-ltcg` for Darwin, drop it for Windows (master...depends_qt_ltcg) https://github.com/bitcoin/bitcoin/pull/32496
1022025-05-14T11:51:51 *** Holz <Holz!~Holz@user/Holz> has joined #bitcoin-core-dev
1032025-05-14T11:56:27 *** mudsip <mudsip!~mudsip@user/mudsip> has joined #bitcoin-core-dev
1042025-05-14T11:59:05 *** mudsip <mudsip!~mudsip@user/mudsip> has quit IRC (Client Quit)
1052025-05-14T12:08:11 *** brunoerg <brunoerg!~brunoerg@2804:14d:5285:8318:658c:4bd4:bb3e:dfdb> has quit IRC (Remote host closed the connection)
1062025-05-14T12:17:36 *** BitcoinHobbyist <BitcoinHobbyist!~BitcoinHo@c94-140.i12-24.melita.com> has joined #bitcoin-core-dev
1072025-05-14T12:19:14 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has joined #bitcoin-core-dev
1082025-05-14T12:20:34 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has quit IRC (Client Quit)
1092025-05-14T12:24:06 <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/8a65f0389464...33dfbbdff69d
1102025-05-14T12:24:06 <bitcoin-git> bitcoin/master 07350e2 Martin Zumsande: test: Fix intermittent failure in wallet_basic.py
1112025-05-14T12:24:07 <bitcoin-git> bitcoin/master e7ad86e Martin Zumsande: test: fix another intermittent failure in wallet_basic.py
1122025-05-14T12:24:07 <bitcoin-git> bitcoin/master 33dfbbd merge-script: Merge bitcoin/bitcoin#32483: test: fix two intermittent failures in wallet...
1132025-05-14T12:24:08 <bitcoin-git> [bitcoin] fanquake merged pull request #32483: test: fix two intermittent failures in wallet_basic.py (master...202505_fix_wallet_basic) https://github.com/bitcoin/bitcoin/pull/32483
1142025-05-14T12:25:25 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has joined #bitcoin-core-dev
1152025-05-14T12:40:05 *** pyth <pyth!~pyth@user/pyth> has joined #bitcoin-core-dev
1162025-05-14T12:49:12 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
1172025-05-14T12:53:02 *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad> has joined #bitcoin-core-dev
1182025-05-14T12:53:03 *** mudsip <mudsip!~mudsip@user/mudsip> has joined #bitcoin-core-dev
1192025-05-14T12:55:52 *** mudsip <mudsip!~mudsip@user/mudsip> has quit IRC (Client Quit)
1202025-05-14T12:57:30 *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad> has quit IRC (Ping timeout: 260 seconds)
1212025-05-14T12:59:35 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has joined #bitcoin-core-dev
1222025-05-14T13:00:02 *** seaner <seaner!~sean@203-132-94-86.ip4.superloop.au> has quit IRC (Ping timeout: 252 seconds)
1232025-05-14T13:01:48 <bitcoin-git> [bitcoin] l0rinc opened pull request #32497: merkle: preâreserve leaves to prevent reallocs with odd vtx count (master...l0rinc/preâreserve-merkle-leaves-to-max) https://github.com/bitcoin/bitcoin/pull/32497
1242025-05-14T13:03:33 *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad> has joined #bitcoin-core-dev
1252025-05-14T13:03:39 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
1262025-05-14T13:05:18 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzzâ¦)
1272025-05-14T13:08:05 *** Guest1757 <Guest1757!~ubuntu@197.237.108.217> has quit IRC (Ping timeout: 248 seconds)
1282025-05-14T13:08:24 *** Christoph_ <Christoph_!~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e> has joined #bitcoin-core-dev
1292025-05-14T13:15:04 *** BitcoinHobbyist <BitcoinHobbyist!~BitcoinHo@c94-140.i12-24.melita.com> has quit IRC (Quit: Client closed)
1302025-05-14T13:15:06 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has joined #bitcoin-core-dev
1312025-05-14T13:15:10 *** Guest3748 <Guest3748!~ubuntu@197.237.108.217> has joined #bitcoin-core-dev
1322025-05-14T13:16:25 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has quit IRC (Client Quit)
1332025-05-14T13:17:59 *** PaperSword1 <PaperSword1!~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com> has joined #bitcoin-core-dev
1342025-05-14T13:18:30 *** PaperSword <PaperSword!~Thunderbi@securemail.qrsnap.io> has quit IRC (Ping timeout: 260 seconds)
1352025-05-14T13:18:30 *** PaperSword1 is now known as PaperSword
1362025-05-14T13:19:24 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has joined #bitcoin-core-dev
1372025-05-14T13:21:52 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1382025-05-14T13:26:14 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 245 seconds)
1392025-05-14T13:36:37 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1402025-05-14T13:43:46 *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad> has quit IRC (Remote host closed the connection)
1412025-05-14T13:44:12 *** BitcoinHobbyist <BitcoinHobbyist!~BitcoinHo@c94-140.i12-24.melita.com> has joined #bitcoin-core-dev
1422025-05-14T13:46:12 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
1432025-05-14T13:48:13 *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad> has joined #bitcoin-core-dev
1442025-05-14T13:50:29 *** brunoerg <brunoerg!~brunoerg@2804:14c:3bfb:37:c93d:a1ec:a5ab:a1ad> has quit IRC (Remote host closed the connection)
1452025-05-14T13:50:34 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 252 seconds)
1462025-05-14T14:04:16 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
1472025-05-14T14:04:57 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1482025-05-14T14:05:52 <bitcoin-git> [bitcoin] ryanofsky pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/33dfbbdff69d...f1d78a3087fb
1492025-05-14T14:05:53 <bitcoin-git> bitcoin/master a04f17a Sjors Provoost: doc: warn that CheckBlock() underestimates sigops
1502025-05-14T14:05:53 <bitcoin-git> bitcoin/master f1d78a3 Ryan Ofsky: Merge bitcoin/bitcoin#31624: doc: warn that CheckBlock() underestimates si...
1512025-05-14T14:05:55 <bitcoin-git> [bitcoin] ryanofsky merged pull request #31624: doc: warn that CheckBlock() underestimates sigops (master...2025/01/doc-sigops) https://github.com/bitcoin/bitcoin/pull/31624
1522025-05-14T14:06:07 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
1532025-05-14T14:08:58 *** saturday- <saturday-!~saturday7@59.167.129.22> has quit IRC (Ping timeout: 244 seconds)
1542025-05-14T14:10:16 <bitcoin-git> [bitcoin] fanquake opened pull request #32498: doc: remove Carls substitute server from Guix docs (master...remove_carl_substitute_server) https://github.com/bitcoin/bitcoin/pull/32498
1552025-05-14T14:15:42 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1562025-05-14T14:15:42 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Read error: Connection reset by peer)
1572025-05-14T14:16:34 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
1582025-05-14T14:23:18 *** saturday7 <saturday7!~saturday7@59.167.129.22> has joined #bitcoin-core-dev
1592025-05-14T14:28:35 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
1602025-05-14T14:32:09 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Quit: = "")
1612025-05-14T14:32:26 *** brunoerg <brunoerg!~brunoerg@2804:14d:5285:8318:d4e4:cda8:a7c:8076> has joined #bitcoin-core-dev
1622025-05-14T14:32:35 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev (Closing Window)
1632025-05-14T14:33:34 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 260 seconds)
1642025-05-14T14:41:38 *** TheRec_ <TheRec_!~toto@84-75-225-47.dclient.hispeed.ch> has quit IRC ()
1652025-05-14T14:44:23 *** Cory38 <Cory38!~Cory38@user/pasha> has quit IRC (Quit: Client closed)
1662025-05-14T14:44:37 *** Cory38 <Cory38!~Cory38@user/pasha> has joined #bitcoin-core-dev
1672025-05-14T14:56:58 <bitcoin-git> [bitcoin] hebasto opened pull request #32499: cmake: Restrict MSVC-specific workaround to affected versions (master...250514-msvc-bug) https://github.com/bitcoin/bitcoin/pull/32499
1682025-05-14T14:58:21 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has joined #bitcoin-core-dev
1692025-05-14T14:58:30 *** TheRec <TheRec!~toto@user/therec> has joined #bitcoin-core-dev
1702025-05-14T15:06:04 <bitcoin-git> [bitcoin] fanquake opened pull request #32500: init: drop `-upnp` (master...drop_upnp_opt) https://github.com/bitcoin/bitcoin/pull/32500
1712025-05-14T15:13:37 <PaperSword> @glozow, sorry about X, just saying. None the less back to building.
1722025-05-14T15:15:51 *** BitcoinHobbyist <BitcoinHobbyist!~BitcoinHo@c94-140.i12-24.melita.com> has quit IRC (Quit: Client closed)
1732025-05-14T15:17:53 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
1742025-05-14T15:20:12 *** saikasyap <saikasyap!~saikasyap@131-193-212-63.east.wireless.uic.edu> has joined #bitcoin-core-dev
1752025-05-14T15:21:56 <instagibbs> sipa re:#31553 second commit allows oversized singleton clusters, can you remind me why you/we chose this?
1762025-05-14T15:21:58 <corebot> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
1772025-05-14T15:22:27 <instagibbs> ah right, nvm ofc
1782025-05-14T15:22:38 <instagibbs> reorg adding in stuff blindly
1792025-05-14T15:44:35 *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has quit IRC (Remote host closed the connection)
1802025-05-14T15:44:58 *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has joined #bitcoin-core-dev
1812025-05-14T15:47:02 <gmaxwell> I've still never really understood why reorgs can't be handled by a list of "non-conflicted transactions which were previously confirmed which must be reconfirmed with the highest priority" and absolutely no computational complexity or limits on that list.. and then a mempool of additional never-confirmed transactions which treats everything in that list of deconfirmed as confirmed, and is
1822025-05-14T15:47:08 <gmaxwell> managed as the mempool normally is.
1832025-05-14T15:48:18 <gmaxwell> so then in a reorg a block is filled by trying to stuff back in all the deconfirmed transactions (in their original order from the node's perspective), and then filling in what remains from the mempool.
1842025-05-14T15:50:16 <gmaxwell> And with a disclosed note that in the event of a reorg, the mining logic favors reconfirming transactions over income maximization on the basis that system health is better for the miner's bottom line than scraping out the absoulte highest income...
1852025-05-14T15:50:23 <_aj_> if there's a higher fee(rate) conflict with one of those transactions, a miner will probably prefer to mine that conflict rather than confirming the old one at "highest priority" ?
1862025-05-14T15:51:24 <gmaxwell> _aj_: I don't really think so, particularly given that the reorg is a very rare event... but someone having a significant theft as a result of reorg may be incredibly damaging to the miner. Like great you got 0.001 BTC more but the public drama means all the bitcoin you earned is now worth 10% less.
1872025-05-14T15:53:57 <instagibbs> you'd still have to deal with oversizedness, so I think this is a question about how things are shoved back into txgraph vs the proposed trimming function?
1882025-05-14T15:54:01 <gmaxwell> It might be the case that if the difference was some huge bogon fee they might prefer it but (1) if there is a bogon fee it's probably some theft attempt, and (2) all this is so rare the expected cost of making the pro-social move is negligible, and a lot more could be earned by doing stuff like making template update latency non-terrible (it's very terrible today, high fee txn are often missed
1892025-05-14T15:54:07 <gmaxwell> 10s of seconds after they're well relayed).
1902025-05-14T15:54:29 <gmaxwell> instagibbs: oversizedness in what sense?
1912025-05-14T15:54:55 <instagibbs> cluster size/count (count being most important)
1922025-05-14T15:55:06 <gmaxwell> That's my point. no you shouldn't.
1932025-05-14T15:55:27 <instagibbs> hm
1942025-05-14T15:55:42 <gmaxwell> There should just be a vector of txn that were previously confirmed and non-conflicted (so still consensus value).. and block building logic should just stuff them all back in. Mempool should treat them as confirmed, not a part of clusters.
1952025-05-14T15:56:07 <instagibbs> so you have a bunch of stuff you can't actually tell how good it is, you get a new tx, you'll just ignore that too?
1962025-05-14T15:56:09 <gmaxwell> Perhaps I'm just stupid, would not be the first time. I had this covo with sipa before and got a response like yours, and I don't get it.
1972025-05-14T15:56:18 <instagibbs> ditto hah
1982025-05-14T15:57:40 <gmaxwell> instagibbs: I think mempool should treat previously (non-conflicted) confirmed stuff as confirmed, and mining should work on reconfirming all that stuff. Then you don't have to worry about it violating cluster limits, etc. because it's not part of clusters.
1992025-05-14T15:58:18 <gmaxwell> It's just a list of stuff you'd like to try to get back into blocks before resuming the regularly scheduled programming.
2002025-05-14T15:58:38 <_aj_> had a discussion with luke along similar lines once, but the idea was just to mark previously-confirmed txs as un-replaceable but still in the regular mempool
2012025-05-14T15:59:27 <_aj_> it seems like a good idea to me, especially if it simplifies things/makes them more efficient, but i don't have any confidence we'd be willing to make a "peternalistic" policy like that and stand up against the criticism of it
2022025-05-14T15:59:29 <gmaxwell> Right but now there is a bunch of hairball about putting that stuff in the mempool and having it frequently break cluster limits and how do you handle that particularly because all of those limits are motivated by computational complexity concerns.
2032025-05-14T16:00:13 <gmaxwell> It's justifyable on an entirely or almost enirely non-parternalistic basis, because otherwise you have this cluster limits problem.
2042025-05-14T16:00:46 <gmaxwell> Also it's not like the reinstated transactions are going to be *bad* in terms of income. Particularly in the ordinary case of a 1 block reorg.
2052025-05-14T16:00:48 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
2062025-05-14T16:01:24 <_aj_> last time i looked, the 1-block reorgs had 99.9% the same transactions already anyway
2072025-05-14T16:01:46 <_aj_> sadly, i no longer remember how to look that up
2082025-05-14T16:02:03 <gmaxwell> _aj_: it was previously (years ago) when I looked.
2092025-05-14T16:03:06 <_aj_> yeah, it was at least a year ago when i looked
2102025-05-14T16:03:45 <gmaxwell> Like there is this annoying computational problem, it just so happens that doing the "good for the network health" thing can avoid it. Probably the socially good thing is in the miners selfish self interest, but even if it's against it, probably the loss is very small. But all that aside it solves the limits problem... and does so in a way that doesn't make the network health _worse_ where the
2112025-05-14T16:03:51 <gmaxwell> node evicts perfectly valid already-confirmed txn just because the broke a cluster limit.
2122025-05-14T16:05:37 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 248 seconds)
2132025-05-14T16:05:55 <_aj_> the idea is the ordering is just exactly how it appeared when it was confirmed?
2142025-05-14T16:06:35 <gmaxwell> And it isn't as if the current (or post cluster) mining logic is actually the true income maximizing logic, -- e.g. node won't keep around multiple conflicting pools and decide at the moment of template construction which makes the most money. It's not even particularly hard to do that (like just calling out to MIP solver with a pretty trivial problem gets you the answer), but it doesn't
2152025-05-14T16:06:41 <gmaxwell> result in a sensible "implied relay logic" that makes sense.
2162025-05-14T16:07:24 <gmaxwell> _aj_: yeah or at least the starting point of my suggestion is that, you could apply some sorting (restricted to O(n log n) optimizations) but I think the idea works with just preserving the original order.
2172025-05-14T16:09:22 <gmaxwell> You just can't apply any O(N^2) or worse algorithim to an arbitarily long reorg... without having to potentialy cut transactions out that were confirmed to manage the complexity blowup.
2182025-05-14T16:09:35 *** pablomartin_ <pablomartin_!~pablomart@217.130.254.81> has joined #bitcoin-core-dev
2192025-05-14T16:09:45 *** Guest70 <Guest70!~Guest1@biblio159.dgbiblio.unam.mx> has joined #bitcoin-core-dev
2202025-05-14T16:09:54 *** Guest70 <Guest70!~Guest1@biblio159.dgbiblio.unam.mx> has quit IRC (Client Quit)
2212025-05-14T16:10:34 <gmaxwell> and for system health, I think it's very good and important to restore the 'most confirmed' (greatest depth) transactions first.
2222025-05-14T16:13:01 <gmaxwell> but like even if you don't give a fuck about system health, you got some contract that sells your coins the instant they're mined yadda yadda... *something* has to be done here because just dumping the reorg into the mempool doesn't work because of potential complexity blowup. May well be that what I suggests earns more income directly, anyways, because otherwise you'd drop more profitable txn
2232025-05-14T16:13:07 <gmaxwell> because they violated cluster limits.
2242025-05-14T16:17:03 <_aj_> well, i liked the non-replacable idea, and this is better than that, so +1 fwiw
2252025-05-14T16:17:07 <gmaxwell> And as far as the health argument goes, you can make a lot of very subjective arguments for the merits of things like RBF or filtering or whatever about non-confirmed txn. But all this is pretty subjective and the system can't make any promises about unconfirmed stuff... But "this was already N confirmed" is an extremely unambigious metric and confirmation is the point where
2262025-05-14T16:17:09 <_aj_> maybe worth it do a write up of the approach/implications, getting chinese/etc translations, and consulting miners/pools before implementing it
2272025-05-14T16:17:13 <gmaxwell> we-the-tech-community has always said that expectations ought to start forming there. It's would also be completely technically pratical for the network to relay near-tip orphans and for miners to priortize their distinct txn, though that isn't done today... and probably no one will bother implementing because orphans are rare enough.
2282025-05-14T16:17:58 <_aj_> near-tip stale blocks you mean?
2292025-05-14T16:18:21 <gmaxwell> but unlike "miners should always prioritize FIRST SEEN" ... priortizing stuff that has actually been mined (and particularly was YOUR best tip) is actually reasonable.
2302025-05-14T16:19:29 <gmaxwell> _aj_: Exactly, near-tip stale blocks. To be clear, I'm not suggesting doing that now, but I think it would be reasonable to do (as it's kind of the logical conclusion of the policy I suggest, so if you hated near-tip inclusion as a priority thing then maybe you should hate my suggestion)
2312025-05-14T16:19:30 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
2322025-05-14T16:21:15 <gmaxwell> (and given that stale blocks are relatively rare, it's arguable not worth implementing even if you fully buy my argument that those txn should be prioritized where they are non-conflicted)
2332025-05-14T16:21:37 <_aj_> you lose the "i've already validated this block, so i know the txs are fine" for that code path
2342025-05-14T16:22:12 <gmaxwell> _aj_: yeah but the node is usually pretty idle, validate in background. It's got tip-POW so it's not a DOS vector.
2352025-05-14T16:23:11 <_aj_> validating in the background could make reorging to that block and a new child of it faster (and would certainly make rejecting a child of it faster if the stale block turned out to be invalid)
2362025-05-14T16:23:30 <_aj_> not sure if any of that would also affect the selfish-mining stuff
2372025-05-14T16:23:31 <gmaxwell> _aj_: best counterargument (beyond it not being worth impl complexity) I'm aware of is that there is a harm to consensus to help anyone get *access* to a fork from your tip, but I think it's a pretty thin issue.
2382025-05-14T16:24:35 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 276 seconds)
2392025-05-14T16:24:36 <_aj_> is it a harm to consensus to know that there's an equal-work valid tip out there that may have more hashrate mining on it though?
2402025-05-14T16:25:03 <gmaxwell> _aj_: yes it would, which is at least a theoretical problem, if there is a deep fork bitcoin can stop converging when the cost to switch starts approaching the interblock time. This actually was seen in practice in some shitty altcoin called 'liquid bitcoin' or something like that where it has a fixed difficulty-- the network shattered into a thousand forks once the reorg time exceeded the
2412025-05-14T16:25:09 <gmaxwell> interblock time.
2422025-05-14T16:26:12 <_aj_> (fixed difficulty... why??? :yelling-at-clouds-emoji:)
2432025-05-14T16:26:17 <gmaxwell> _aj_: I think everyone has a self interest in trying to avoid there being any additional hashrate confilicting the tip they're on.
2442025-05-14T16:26:42 *** pyth <pyth!~pyth@user/pyth> has quit IRC (Quit: Leaving)
2452025-05-14T16:27:41 <_aj_> not dealing with an alternative fork that's more than 1 block deep seems fine -- ie, don't disconnect more than 1 block for bg validation of a fork
2462025-05-14T16:28:08 <gmaxwell> _aj_: https://runt-of-the-web.com/wordpress/wp-content/uploads/2012/08/funniest-demotivationals-mistakes.jpg
2472025-05-14T16:28:45 <_aj_> gmaxwell: i've had that thought: logical conclusion is that you should make the most impressive mistakes you can, and document them thoroughly
2482025-05-14T16:29:55 <gmaxwell> _aj_: I mean in terms of theoretical weakness/attacks, lets say that a 50 block reorg takes more than 10 minutes for most nodes to proces. And forever reason (attack, internet cut, etc) such a fork forms in Bitcoin-- the result may be that the system never reconverges to a single new chain without human intervention, or takes a very very long time.
2492025-05-14T16:32:41 <gmaxwell> but I think I'm off in the weeds about pretty theoretical risks.
2502025-05-14T16:34:41 <gmaxwell> To 'solve' that risk it would be sufficient to track multiple near-best chains which have recieved a new block with in n*average_block_time, as in maintain a cloned chainstate for each of them so new blocks in them could be validated without any switching costs.
2512025-05-14T16:35:42 <gmaxwell> But oy, lots of software complexity for a theoretical rather than pratical risk, that in practice would just get resolved by intervention if it ever happened.
2522025-05-14T16:35:48 <glozow> question: If you have the "previously confirmed txns pool" and see a child of one of those, do you put the child in that pool or the mempool?
2532025-05-14T16:36:05 <_aj_> the mempool, unless it was a child in a confirmed block
2542025-05-14T16:36:16 <gmaxwell> glozow: in my thinking, the mempool. The previously confirmed pool is just treated as confirmed from the perspective of the mempool.
2552025-05-14T16:36:35 <gmaxwell> as _aj_ says, unless it was itself previously confirmed.
2562025-05-14T16:36:40 *** Cory38 <Cory38!~Cory38@user/pasha> has quit IRC (Quit: Client closed)
2572025-05-14T16:36:42 <_aj_> the mempool, unless it was a child in a pow-valid block (confirmed or perhaps stale)
2582025-05-14T16:36:54 *** Cory38 <Cory38!~Cory38@user/pasha> has joined #bitcoin-core-dev
2592025-05-14T16:38:05 <glozow> how long would a tx persist in previously confirmed pool?
2602025-05-14T16:38:10 <_aj_> gmaxwell: depends how many new txs were on the other side of the reorg i guess, a simple invalidate/reconsider of 50 blocks seems to take a couple of minutes on not very quick hw
2612025-05-14T16:38:18 <_aj_> until it's mined or conflicted by a confirmed tx
2622025-05-14T16:38:20 <gmaxwell> Essentially I suggest the node behavior is "once confirmed, always confirmed, unless it gets conflicted"
2632025-05-14T16:39:13 <_aj_> i guess if it's mined, technically that's also conflicted by a confirmed tx
2642025-05-14T16:39:20 <glozow> how would we decide on evictions for child-of-previously-confirmed in the mempool? it also gets evicted if it's lower feerate right?
2652025-05-14T16:39:41 <glozow> as in, it's compared with all the other stuff in mempool
2662025-05-14T16:39:46 <gmaxwell> glozow: It might be prudent to time it out, e.g. there is an unknown to you softfork that makes it no longer consensus valid to other participants. But I think my general concept is forever.
2672025-05-14T16:39:47 <_aj_> same as we do for child-of-confirmed-tx in the mempool
2682025-05-14T16:40:08 <gmaxwell> _aj_: right, in my view it's just treated like its confirmed.
2692025-05-14T16:40:54 <_aj_> gmaxwell: wow, that would be horrible -- if you had hashpower, you'd stick it in a block, and everyone would reject your block
2702025-05-14T16:41:31 <gmaxwell> _aj_: I mean thats generally the problem with softforks, if someone does mine something invalid then you end up with multiple rejected blocks-- that already happens.
2712025-05-14T16:42:04 <_aj_> gmaxwell: you'd normaly reject it from your mempool for being non-standard, but maybe you wouldn't reject it here for that reason
2722025-05-14T16:42:07 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
2732025-05-14T16:42:42 <gmaxwell> _aj_: yes but people build on the invalid block. We've seen it in practice in prior softforks, where every time a miner that allowed the consensus invalid blocks there would be several additional blocks that built on it.
2742025-05-14T16:43:57 <gmaxwell> during one softfork 50btc one of the larger pools at the time spent an entire month producing invalid blocks. many of which triggered other miners to produce invalid-because-child. The pool was PPS too so they didn't lose much hashpower...
2752025-05-14T16:44:02 <glozow> would you not still run validation on the disconnected transactions?
2762025-05-14T16:44:21 <gmaxwell> glozow: sure absolutely you're only trying to mine transactions YOU think are valid.
2772025-05-14T16:44:32 <gmaxwell> glozow: aj's point is that the network may have other ideas about their validity.
2782025-05-14T16:45:00 *** pablomartin_ <pablomartin_!~pablomart@217.130.254.81> has quit IRC (Ping timeout: 244 seconds)
2792025-05-14T16:45:52 *** pablomartin_ <pablomartin_!~pablomart@217.130.254.81> has joined #bitcoin-core-dev
2802025-05-14T16:47:48 <gmaxwell> _aj_: of course you could also further restrict any "restoration" transactions to ones that don't violate forward compatiblity standardness rules to reduce that risk. I don't really have a strong opinion one way or another, and could argue it either way.
2812025-05-14T16:47:54 *** Christoph_ <Christoph_!~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e> has quit IRC (Quit: Christoph_)
2822025-05-14T16:50:21 <gmaxwell> _aj_: the principle of FAFO applies to both sides, non-upgraded-miner producing invalid blocks due to not enforcing a newly active consensus rule, or a user relying on confirmation of a transaction that is non-standard due to well understood forward compat rules. I *generally* prefer to screw the miner when those two conflict, because they're the more sophicated party.
2832025-05-14T16:50:25 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 252 seconds)
2842025-05-14T16:51:17 <gmaxwell> _aj_: but otoh the new consensus rule might be some rogue bullshit performed by just a couple mining pools, the smaller miner doesn't even know about the new rule, etc.
2852025-05-14T16:51:52 <gmaxwell> _aj_: but if the majority hashpower is out to get them they can invalidate stuff that isn't blocked by forward compat rules anyways so ::shrugs::
2862025-05-14T16:53:04 <gmaxwell> like right now today two or three miners constuting >>50% hashpower could decide to blacklist some address, maybe belonging to a known bad actor.. and then everyone else is producing blocks that they'll exclude from their chain, and will keep doing so 'forever' (until human intervention).
2872025-05-14T16:53:58 <gmaxwell> so I don't think restoration creates a vulnerablity to attack that doesn't just already exist.
2882025-05-14T16:54:30 <gmaxwell> (restoration being the word I'm using to describe trying hard to confirm deconfirmed transactions, if it wasn't clear)
2892025-05-14T16:57:51 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
2902025-05-14T16:58:43 <gmaxwell> _aj_: as to why I favor restoring transactions you wouldn't mine generally, the biggest reason is because restoring them is necessary to restore their children, which you would have mined. like right now today if I'm not an idiot I don't author transactions that spend unconfirmed non-standard coins. But once they're confirmed I don't care if they're standard at all, and I expect that right
2912025-05-14T16:58:49 <gmaxwell> now a large percentage of the tip-circulating coins have non-standardness somewhere in their recent causual history.
2922025-05-14T16:59:13 <gmaxwell> like someone does some bullshit monkey jpeg crap and the change from that eventually ends up in an exchange wallet, and so on.
2932025-05-14T16:59:21 <_aj_> maybe after some timeout you just start moving restoration-txs back into the mempool (relaying to other peers as you do so, and evicting things that violate cluster limits)
2942025-05-14T16:59:38 *** enochazariah <enochazariah!~enochazar@162.245.239.130> has joined #bitcoin-core-dev
2952025-05-14T17:00:54 <_aj_> like 72 blocks (12h)
2962025-05-14T17:01:29 <gmaxwell> _aj_: yeah I think that is a reasonable backstop. The timeout could also just be some function of their order. like you can assume the network is generally trying to restore and if a txn isn't immediately restored there may be a reason why not. So like if there is a 2 deep reorg, the oldest txn are 2 blocks old and maybe you want to kick them out by the time they're N blocks old. If you
2972025-05-14T17:01:35 <gmaxwell> assume *everyone* is retoring you'd kick them out after litterally the next block, but some slack makes sense.
2982025-05-14T17:02:22 *** saikasyap <saikasyap!~saikasyap@131-193-212-63.east.wireless.uic.edu> has quit IRC (Quit: Client closed)
2992025-05-14T17:03:05 <gmaxwell> _aj_: more than I was thinking. why not just assume miners are restoring, except for some jokers who aren't, and kick stuff out after a couple blocks more than than it would take if everyone was restoring?
3002025-05-14T17:03:13 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 272 seconds)
3012025-05-14T17:04:58 <gmaxwell> Again I'm not strongly opinioned on this one. I think if you don't try to restore forward-compat-vioating txn then it's pretty reasonable to have a long expiration. If you restore litterally everyone you may want to evict fast to minimize risk that you're trying to restore something that is invalid but you don't know its invalid. Of course, the two could be hybridized...
3022025-05-14T17:06:15 <gmaxwell> (and to be clear I mean evict from the restore-pool to the mempool, which may or may not mean dropping entirely due to policy/cluster/etc limits)
3032025-05-14T17:09:27 <_aj_> gmaxwell: i think you'd drop to the mempool in the reverse order to how you'd mine; i think if the main thing we're protecting against is miners who aren't following current consensus rules, then risking up to half a day of lost hashpower isn't going to cause massive angst, and gives plenty of time to catch up any txs for even a long reorg
3042025-05-14T17:10:49 <_aj_> gmaxwell: revalidating previously confirmed txs to see if they follow standardness rules seems annoying, so i dismissed the hybridized approach :(
3052025-05-14T17:14:23 <_aj_> (it seemed especially annoying to try to do it straight away when you want to do a getblocktemplate asap after the reorg, so i think that means "restoring txs you wouldn't mine generally" also makes sense)
3062025-05-14T17:15:13 *** saikasyap <saikasyap!~saikasyap@131-193-237-189.east.wireless.uic.edu> has joined #bitcoin-core-dev
3072025-05-14T17:18:22 <instagibbs> _aj_ I suppose when "evicting" from "restore pool" back into the mempool , one could do essentially the reverse of what I was doing for another purpose. Use known cfr of non-oversized clusters, and remove things backwards until not oversized, then commit
3082025-05-14T17:18:24 <gmaxwell> _aj_: hm I was thinking the forward compat rules were decidable as a pure function of the txn, you don't need the inputs. But I'm not particularly sure about that.
3092025-05-14T17:19:19 <gmaxwell> I don't have a strong opinion but I'm not the greatest fan of handling the eviction that way, just because its an exceptional case that shouldn't happen, so easier to just pretend its newly recieved.
3102025-05-14T17:19:21 <_aj_> gmaxwell: not for OP_SUCCESS and so forth
3112025-05-14T17:19:36 <gmaxwell> _aj_: darn. okay thats a big strike against checking.
3122025-05-14T17:19:53 *** Christoph_ <Christoph_!~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e> has joined #bitcoin-core-dev
3132025-05-14T17:20:38 <_aj_> gmaxwell: yeah :( DISCOURAGE_UPGRADEABLE_PUBKEYTYPE can be conditional on arbitrary script logic too
3142025-05-14T17:21:17 <gmaxwell> But I think restorepool's mission can be achieved even if you evict very quickly, which mitigates harm.
3152025-05-14T17:21:52 <_aj_> so depth of reorg + fudge factor blocks?
3162025-05-14T17:22:16 <gmaxwell> yeah. Basicaly assume that the network is going to try to restore ASAP, and if it fails to do so, too bad so sad, you get back in line.
3172025-05-14T17:23:03 <gmaxwell> also if you didn't get double spent in fudge_factor blocks, good odds you never will be.
3182025-05-14T17:23:36 <_aj_> gmaxwell: "I'm not the greatest fan of handling the eviction that way" -- sorry, which way?
3192025-05-14T17:25:09 <gmaxwell> _aj_: I understood you were suggesting that a restore-evict should be added to a cluster in a priority way, so eg. cluster limits evict something else. I'm not a huge fan simply because it requires processing the whole cluster, means there is a bunch of reorg special case mempool logic. Which this restorepool idea was trying to eliminate.
3202025-05-14T17:25:12 <_aj_> instagibbs: oh, i guess when you evict from the restorepool, you have to take all the descendants in the mempool, and validate them as a package, in case there's cpfp stuff? but you also want to remember you've already done the consensus/standardness validation for the descendants
3212025-05-14T17:26:00 <_aj_> gmaxwell: oh, no, treating it as new sounds fine to me; i just meant cluster limits would apply now and something would get evicted
3222025-05-14T17:26:09 <gmaxwell> ah okay.
3232025-05-14T17:26:45 <gmaxwell> there is some unavoidable complexity I think, like say the evicted txn is the parent of all txn in the cluster.
3242025-05-14T17:26:45 *** pablomartin_ <pablomartin_!~pablomart@217.130.254.81> has quit IRC (Ping timeout: 248 seconds)
3252025-05-14T17:26:59 <instagibbs> _aj_ well, if it's undersized, you'll end up being able to evaluate the new chunks, and we're reyling on PoW for anti DoS. How that's advertised on relay, i havent considered it
3262025-05-14T17:27:03 <gmaxwell> and cluster is overlimits with it in there.
3272025-05-14T17:27:37 <_aj_> gmaxwell: i think package logic might already deal with that (with the only problem be we can't relay it currently, but that's not an issue here). **handwave** **look, a dinosaur!!**
3282025-05-14T17:27:46 *** pablomartin_ <pablomartin_!~pablomart@217.130.254.81> has joined #bitcoin-core-dev
3292025-05-14T17:28:21 <gmaxwell> yeah I'm not too concerned with relay in the sense that assuming the reorged block was well propoagated there doesn't need to be anyone as ~all nodes will just be doing the same operation.
3302025-05-14T17:28:45 <gmaxwell> I mean it's fine to try relaying it.
3312025-05-14T17:28:48 <_aj_> instagibbs: relay is just belts and suspenders / best effort; everyone running this new logic should already have the txs...
3322025-05-14T17:28:56 <gmaxwell> _aj_: jinx
3332025-05-14T17:29:00 <instagibbs> im not worrying too much when big reorgs...
3342025-05-14T17:29:10 <instagibbs> s/big//
3352025-05-14T17:29:39 <_aj_> what are you worrying about then?
3362025-05-14T17:29:56 <instagibbs> you're the one who brought up package relay not me! :)
3372025-05-14T17:30:35 <_aj_> okay, worry about it when there's a spec then!
3382025-05-14T17:35:54 <bitcoin-git> [bitcoin] BrandonOdiwuor opened pull request #32501: RPC: removeprunedfunds should take an array of txids (master...removeprunedfunds-array) https://github.com/bitcoin/bitcoin/pull/32501
3392025-05-14T17:36:58 <_aj_> instagibbs: i just mean if you take X from the restorepool with descendants A B C in the mempool, then remove A,B,C from the mempool and call ProcessNewPackage([X,A,B,C]) maybe that already does 95% of the right thing
3402025-05-14T17:38:05 <instagibbs> ah sure, the CFR would be well-known as long as XABC isn't oversized
3412025-05-14T17:38:26 <instagibbs> (and I think you can use ABC CFR knowledge to trim a bit smarter)
3422025-05-14T17:39:02 <_aj_> well A,B,C might have been in different clusters initially, and bring in whatever else was in those clusters as a result, but yeah
3432025-05-14T17:39:25 <instagibbs> yes
3442025-05-14T17:40:20 <gmaxwell> That would actually be the most common case too, as mempool cluster size is 1+e on average, and many txn are spending outputs in the last block or two. Bringing back in a parent will tend to merge clusters.
3452025-05-14T17:40:46 <_aj_> maybe annoying if your next tx to move from restorepool to mempool is Y which is X's parent
3462025-05-14T17:41:06 <instagibbs> you have to keep backing it out, but I don't see a fundamental issue there
3472025-05-14T17:41:19 <_aj_> yeah, probably so rare in practice that annoying doesn't matter
3482025-05-14T17:41:36 <gmaxwell> well the eviction should be the order of original confirmation I think?
3492025-05-14T17:41:38 <_aj_> annoying-for-the-computer doesn't matter anyway
3502025-05-14T17:41:57 <_aj_> got to evict children before parents
3512025-05-14T17:42:22 <gmaxwell> ah
3522025-05-14T17:42:25 <gmaxwell> right
3532025-05-14T17:42:48 <_aj_> keeping trying to confirm what were the deepest confirmed txs for the longest time also seems okay?
3542025-05-14T17:42:53 <gmaxwell> I mean you can evict parents 'first' but you have to evict all the children with htem if you do.
3552025-05-14T17:43:30 <gmaxwell> _aj_: yeah I guess my thinking was mostly "this one really should be back in already, if it's not, there is an issue with it"
3562025-05-14T17:43:33 <instagibbs> yes, and you'll have to handle that due to conflicts via other blocks
3572025-05-14T17:43:37 <instagibbs> anyways
3582025-05-14T17:43:57 <_aj_> i don't think you want to evict everything at once because you still have to validate standardness for all of them; didn't see any obvious midpoint between 1-by-1 and everything
3592025-05-14T17:44:22 <_aj_> gmaxwell: fair
3602025-05-14T17:44:38 <_aj_> gmaxwell: so maybe 1-by-1 from the front, but grab all its children
3612025-05-14T17:45:11 <gmaxwell> That's what I was thinking (well hadn't thought through the children part, but you're right that its necessary)
3622025-05-14T17:45:14 <_aj_> gmaxwell: then let the package logic discard stuff that's too big and validate everything in the package, because validating a package all at once is fine anyway
3632025-05-14T17:45:22 <instagibbs> in that case, oversized results degenerates to Trim from PR?
3642025-05-14T17:45:34 <instagibbs> (in batch)
3652025-05-14T17:45:54 <_aj_> PR=Package Relay? yeah, i think so
3662025-05-14T17:46:19 <instagibbs> sorry this one #31553 (I still have to review it hence this discussion)
3672025-05-14T17:46:21 <corebot> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
3682025-05-14T17:46:42 <instagibbs> shove everything in, make best-effort undersized txgraph
3692025-05-14T17:46:56 *** Christoph_ <Christoph_!~Christoph@2a02:810d:1399:b700:2460:d743:e26d:2d1e> has quit IRC (Quit: Christoph_)
3702025-05-14T17:47:58 <_aj_> instagibbs: ah, not sure at that detail, but it sounds good
3712025-05-14T17:51:28 *** Talkless <Talkless!~Talkless@138.199.6.197> has joined #bitcoin-core-dev
3722025-05-14T17:58:53 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
3732025-05-14T17:59:44 *** enochazariah <enochazariah!~enochazar@162.245.239.130> has quit IRC (Quit: Client closed)
3742025-05-14T18:09:13 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 276 seconds)
3752025-05-14T18:10:36 *** BlueMoon <BlueMoon!~BlueMoon@biblio159.dgbiblio.unam.mx> has joined #bitcoin-core-dev
3762025-05-14T18:15:27 *** mudsip <mudsip!~mudsip@user/mudsip> has joined #bitcoin-core-dev
3772025-05-14T18:16:04 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
3782025-05-14T18:17:56 *** mudsip <mudsip!~mudsip@user/mudsip> has quit IRC (Client Quit)
3792025-05-14T18:21:04 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 260 seconds)
3802025-05-14T18:23:05 *** BlueMoon <BlueMoon!~BlueMoon@biblio159.dgbiblio.unam.mx> has quit IRC (Quit: Client closed)
3812025-05-14T18:24:53 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
3822025-05-14T18:26:34 <bitcoin-git> [bitcoin] davidgumberg opened pull request #32502: wallet: Drop unused fFromMe from CWalletTx (master...5-14-25-dead-code-removal) https://github.com/bitcoin/bitcoin/pull/32502
3832025-05-14T18:29:49 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 260 seconds)
3842025-05-14T18:30:55 *** pablomartin_ <pablomartin_!~pablomart@217.130.254.81> has quit IRC (Ping timeout: 244 seconds)
3852025-05-14T18:42:11 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzzâ¦)
3862025-05-14T19:07:20 *** saikasyap <saikasyap!~saikasyap@131-193-237-189.east.wireless.uic.edu> has quit IRC (Quit: Client closed)
3872025-05-14T19:14:49 *** saikasyap <saikasyap!~saikasyap@131-193-237-189.east.wireless.uic.edu> has joined #bitcoin-core-dev
3882025-05-14T19:17:40 *** PaperSword1 <PaperSword1!~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com> has joined #bitcoin-core-dev
3892025-05-14T19:18:19 *** PaperSword <PaperSword!~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com> has quit IRC (Ping timeout: 245 seconds)
3902025-05-14T19:18:19 *** PaperSword1 is now known as PaperSword
3912025-05-14T19:21:10 *** PaperSword1 <PaperSword1!~Thunderbi@securemail.qrsnap.io> has joined #bitcoin-core-dev
3922025-05-14T19:22:57 *** PaperSword <PaperSword!~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com> has quit IRC (Ping timeout: 248 seconds)
3932025-05-14T19:22:58 *** PaperSword1 is now known as PaperSword
3942025-05-14T19:26:59 *** PaperSword1 <PaperSword1!~Thunderbi@ec2-3-17-244-63.us-east-2.compute.amazonaws.com> has joined #bitcoin-core-dev
3952025-05-14T19:27:13 *** PaperSword <PaperSword!~Thunderbi@securemail.qrsnap.io> has quit IRC (Ping timeout: 248 seconds)
3962025-05-14T19:27:14 *** PaperSword1 is now known as PaperSword
3972025-05-14T19:29:15 *** Guest3748 <Guest3748!~ubuntu@197.237.108.217> has quit IRC (Ping timeout: 276 seconds)
3982025-05-14T19:29:29 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has joined #bitcoin-core-dev
3992025-05-14T19:40:42 *** Talkless <Talkless!~Talkless@138.199.6.197> has quit IRC (Quit: Konversation terminated!)
4002025-05-14T19:57:45 <bitcoin-git> [bitcoin] achow101 pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/f1d78a3087fb...e7a937237686
4012025-05-14T19:57:46 <bitcoin-git> bitcoin/master 02d4bc7 ismaelsadeeq: interfaces: remove redundant coinbase fee check in `waitNext`
4022025-05-14T19:57:46 <bitcoin-git> bitcoin/master e6c2f4c ismaelsadeeq: interfaces: refactor: move `submitSolution` implementation to miner
4032025-05-14T19:57:46 <bitcoin-git> bitcoin/master 720f201 ismaelsadeeq: interfaces: refactor: move `waitNext` implementation to miner
4042025-05-14T19:57:48 <bitcoin-git> [bitcoin] achow101 merged pull request #32378: interfaces: refactor: move `Mining` and `BlockTemplate` implementation to miner (master...04-2025-refactor-mining-interface) https://github.com/bitcoin/bitcoin/pull/32378
4052025-05-14T20:08:08 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
4062025-05-14T20:12:29 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 245 seconds)
4072025-05-14T20:19:34 <bitcoin-git> [bitcoin] achow101 pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/e7a937237686...53eb5593f0a1
4082025-05-14T20:19:35 <bitcoin-git> bitcoin/master 8ba245c Sebastian Falbesoner: test: add constants for MuSig2 PSBT key types (BIP 373)
4092025-05-14T20:19:35 <bitcoin-git> bitcoin/master 4b24186 Sebastian Falbesoner: test: add test for decoding PSBT with MuSig2 PSBT key types (BIP 373)
4102025-05-14T20:19:35 <bitcoin-git> bitcoin/master 53eb559 Ava Chow: Merge bitcoin/bitcoin#32305: test: add test for decoding PSBT with MuSig2 ...
4112025-05-14T20:19:37 <bitcoin-git> [bitcoin] achow101 merged pull request #32305: test: add test for decoding PSBT with MuSig2 PSBT key types (BIP 373) (master...202504-test-add_musig2_decodepsbt_tests) https://github.com/bitcoin/bitcoin/pull/32305
4122025-05-14T20:27:35 <bitcoin-git> [bitcoin] brunoerg opened pull request #32504: test: descriptor: cover invalid multi/multi_a cases (master...2025-05-descriptor-test-multi) https://github.com/bitcoin/bitcoin/pull/32504
4132025-05-14T20:56:07 *** redstorm <redstorm!~redstorm@2406:e001:2:6400::1> has joined #bitcoin-core-dev
4142025-05-14T20:57:58 *** dzxzg <dzxzg!~dzxzg@user/dzxzg> has joined #bitcoin-core-dev
4152025-05-14T20:59:39 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
4162025-05-14T21:00:01 *** saikasyap <saikasyap!~saikasyap@131-193-237-189.east.wireless.uic.edu> has quit IRC (Quit: Client closed)
4172025-05-14T21:00:38 *** upekkha <upekkha!~Advanced@2a01:4f8:1c0c:49df::1> has quit IRC (Remote host closed the connection)
4182025-05-14T21:00:49 *** SpellChecker_ <SpellChecker_!~SpellChec@user/SpellChecker> has joined #bitcoin-core-dev
4192025-05-14T21:01:15 *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has quit IRC (Remote host closed the connection)
4202025-05-14T21:01:48 *** upekkha <upekkha!~Advanced@2a01:4f8:1c0c:49df::1> has joined #bitcoin-core-dev
4212025-05-14T21:04:09 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 245 seconds)
4222025-05-14T21:05:17 *** saikasyap <saikasyap!~saikasyap@131-193-237-189.east.wireless.uic.edu> has joined #bitcoin-core-dev
4232025-05-14T21:22:20 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has quit IRC (Quit: Leaving)
4242025-05-14T21:22:30 *** saikasyap <saikasyap!~saikasyap@131-193-237-189.east.wireless.uic.edu> has quit IRC (Ping timeout: 240 seconds)
4252025-05-14T21:30:54 *** santiii <santiii!~santiii@209.214.155.50> has joined #bitcoin-core-dev
4262025-05-14T21:34:18 <bitcoin-git> [bitcoin] achow101 pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/53eb5593f0a1...d5786bc19a9f
4272025-05-14T21:34:18 <bitcoin-git> bitcoin/master fa7f04c MarcoFalke: refactor: Remove UB in prevector reverse iterators
4282025-05-14T21:34:19 <bitcoin-git> bitcoin/master faf9082 MarcoFalke: test: Fix whitespace in prevector_tests.cpp
4292025-05-14T21:34:19 <bitcoin-git> bitcoin/master d5786bc Ava Chow: Merge bitcoin/bitcoin#32490: refactor: Remove UB in prevector reverse iter...
4302025-05-14T21:34:20 <bitcoin-git> [bitcoin] achow101 merged pull request #32490: refactor: Remove UB in prevector reverse iterators (master...2505-less-UB) https://github.com/bitcoin/bitcoin/pull/32490
4312025-05-14T21:52:41 *** redstorm <redstorm!~redstorm@2406:e001:2:6400::1> has quit IRC (Quit: Client closed)
4322025-05-14T21:53:43 *** santiii <santiii!~santiii@209.214.155.50> has quit IRC (Quit: Client closed)
4332025-05-14T22:02:47 *** purpleKarrot <purpleKarrot!~purpleKar@user/purpleKarrot> has quit IRC (Quit: purpleKarrot)
4342025-05-14T22:03:33 *** SpellChecker_ <SpellChecker_!~SpellChec@user/SpellChecker> has quit IRC (Quit: bye)
4352025-05-14T22:03:35 *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has joined #bitcoin-core-dev
4362025-05-14T22:05:32 <bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d5786bc19a9f...4b26ca0e2f1e
4372025-05-14T22:05:32 <bitcoin-git> bitcoin/master 5bf91ba David Gumberg: wallet: Drop unused fFromMe from CWalletTx
4382025-05-14T22:05:33 <bitcoin-git> bitcoin/master 4b26ca0 Ava Chow: Merge bitcoin/bitcoin#32502: wallet: Drop unused fFromMe from CWalletTx
4392025-05-14T22:05:34 <bitcoin-git> [bitcoin] achow101 merged pull request #32502: wallet: Drop unused fFromMe from CWalletTx (master...5-14-25-dead-code-removal) https://github.com/bitcoin/bitcoin/pull/32502
4402025-05-14T22:42:32 <bitcoin-git> [bitcoin] theStack opened pull request #32505: depends: bump to latest config.guess and config.sub (master...202505-depends-latest_config_guess_sub) https://github.com/bitcoin/bitcoin/pull/32505
4412025-05-14T22:43:20 *** Cory38 <Cory38!~Cory38@user/pasha> has quit IRC (Quit: Client closed)
4422025-05-14T22:43:35 *** Cory38 <Cory38!~Cory38@user/pasha> has joined #bitcoin-core-dev
4432025-05-14T22:47:54 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 245 seconds)
4442025-05-14T22:50:20 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
4452025-05-14T23:01:28 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:3855:996a:9be1:e359> has joined #bitcoin-core-dev
4462025-05-14T23:01:36 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has joined #bitcoin-core-dev
4472025-05-14T23:04:34 *** szarka <szarka!~szarka@2603:3003:4eac:100:682b:a9d9:9b1d:907b> has quit IRC (Ping timeout: 260 seconds)
4482025-05-14T23:06:07 *** pseudoramdom <pseudoramdom!~pseudoram@user/pseudoramdom> has quit IRC (Ping timeout: 252 seconds)
4492025-05-14T23:14:02 <bitcoin-git> [bitcoin] achow101 pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/4b26ca0e2f1e...31d3eebfb92a
4502025-05-14T23:14:02 <bitcoin-git> bitcoin/master 4f5e04d Luke Dashjr: Revert "remove unneeded close_fds option from cpp-subprocess"
4512025-05-14T23:14:02 <bitcoin-git> bitcoin/master c7c356a Luke Dashjr: cpp-subprocess: Iterate through /proc/self/fd for close_fds option on Linux
4522025-05-14T23:14:02 <bitcoin-git> bitcoin/master a0eed55 Luke Dashjr: run_command: Enable close_fds option to avoid lingering fds
4532025-05-14T23:14:04 <bitcoin-git> [bitcoin] achow101 merged pull request #32343: common: Close non-std fds before exec in RunCommandJSON (master...2025-04-closefds) https://github.com/bitcoin/bitcoin/pull/32343
4542025-05-14T23:24:13 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has quit IRC (Ping timeout: 252 seconds)
4552025-05-14T23:26:45 *** jespada <jespada!~jespada@r167-61-130-171.dialup.adsl.anteldata.net.uy> has joined #bitcoin-core-dev
4562025-05-14T23:46:23 *** Cory38 <Cory38!~Cory38@user/pasha> has quit IRC (Quit: Client closed)
4572025-05-14T23:46:39 *** Cory38 <Cory38!~Cory38@user/pasha> has joined #bitcoin-core-dev
4582025-05-14T23:48:58 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev