12025-09-18T00:17:03 *** thelounge496669 <thelounge496669!~thelounge@149.106.235.56> has quit IRC (Read error: Connection reset by peer)
22025-09-18T00:17:15 *** thelounge496669 <thelounge496669!~thelounge@149.106.235.56> has joined #bitcoin-core-dev
32025-09-18T00:31:49 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
42025-09-18T00:52:35 *** thelounge496669 <thelounge496669!~thelounge@149.106.235.56> has quit IRC (Read error: Connection reset by peer)
52025-09-18T00:52:50 *** thelounge496669 <thelounge496669!~thelounge@149.106.235.56> has joined #bitcoin-core-dev
62025-09-18T00:57:37 *** Cory30 <Cory30!~Cory44@user/pasha> has joined #bitcoin-core-dev
72025-09-18T01:01:11 *** Cory44 <Cory44!~Cory44@user/pasha> has quit IRC (Ping timeout: 250 seconds)
82025-09-18T01:02:51 *** nanotube <nanotube!~nanotube@user/nanotube> has quit IRC (Ping timeout: 252 seconds)
92025-09-18T01:07:02 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:a908:7546:dcc7:a00b> has joined #bitcoin-core-dev
102025-09-18T01:09:19 *** Earnestly <Earnestly!~earnest@user/earnestly> has quit IRC (Ping timeout: 260 seconds)
112025-09-18T01:09:53 *** helo_ <helo_!~helo@user/helo> has quit IRC (Ping timeout: 260 seconds)
122025-09-18T01:10:27 *** rszarka <rszarka!~szarka@2603:3003:4eac:100:a908:7546:dcc7:a00b> has quit IRC (Ping timeout: 260 seconds)
132025-09-18T01:11:18 *** helo <helo!~helo@user/helo> has joined #bitcoin-core-dev
142025-09-18T01:12:10 *** Earnestly <Earnestly!~earnest@user/earnestly> has joined #bitcoin-core-dev
152025-09-18T01:13:37 *** Cory44 <Cory44!~Cory30@user/pasha> has joined #bitcoin-core-dev
162025-09-18T01:16:47 *** Cory30 <Cory30!~Cory44@user/pasha> has quit IRC (Ping timeout: 250 seconds)
172025-09-18T01:17:21 *** nanotube <nanotube!~nanotube@user/nanotube> has joined #bitcoin-core-dev
182025-09-18T01:20:45 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
192025-09-18T01:21:21 *** PaperSword1 <PaperSword1!~Thunderbi@securemail.qrsnap.io> has joined #bitcoin-core-dev
202025-09-18T01:23:46 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has quit IRC (Quit: Christoph_)
212025-09-18T01:23:59 *** PaperSword <PaperSword!~Thunderbi@securemail.qrsnap.io> has quit IRC (Ping timeout: 244 seconds)
222025-09-18T01:23:59 *** l0rinc_ <l0rinc_!~l0rinc@user/l0rinc> has quit IRC (Ping timeout: 244 seconds)
232025-09-18T01:23:59 *** _durandal <_durandal!~durandal@148.252.129.224> has quit IRC (Ping timeout: 244 seconds)
242025-09-18T01:24:00 *** dzxzg2 <dzxzg2!~dzxzg@user/dzxzg> has quit IRC (Ping timeout: 244 seconds)
252025-09-18T01:24:00 *** nanotube <nanotube!~nanotube@user/nanotube> has quit IRC (Ping timeout: 244 seconds)
262025-09-18T01:24:00 *** PaperSword1 is now known as PaperSword
272025-09-18T01:24:00 *** nanotube_ <nanotube_!~nanotube@user/nanotube> has joined #bitcoin-core-dev
282025-09-18T01:27:23 *** purpleKarrot <purpleKarrot!~purpleKar@user/purpleKarrot> has joined #bitcoin-core-dev
292025-09-18T01:27:24 *** purpleKarrot <purpleKarrot!~purpleKar@user/purpleKarrot> has quit IRC (Remote host closed the connection)
302025-09-18T01:27:34 *** purpleKarrot <purpleKarrot!~purpleKar@user/purpleKarrot> has joined #bitcoin-core-dev
312025-09-18T01:28:29 *** twistedline_ <twistedline_!~bitcoin@c-76-100-108-154.hsd1.md.comcast.net> has quit IRC ()
322025-09-18T01:29:43 *** twistedline <twistedline!~bitcoin@1tbit.com> has joined #bitcoin-core-dev
332025-09-18T01:30:12 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
342025-09-18T01:34:38 *** Cory47 <Cory47!~Cory44@user/pasha> has joined #bitcoin-core-dev
352025-09-18T01:35:01 *** _durandal <_durandal!~durandal@148.252.129.224> has joined #bitcoin-core-dev
362025-09-18T01:36:20 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
372025-09-18T01:38:27 *** Cory44 <Cory44!~Cory30@user/pasha> has quit IRC (Ping timeout: 250 seconds)
382025-09-18T01:57:43 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
392025-09-18T01:58:39 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
402025-09-18T02:04:08 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
412025-09-18T02:05:07 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
422025-09-18T02:06:07 *** jon_atack <jon_atack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 250 seconds)
432025-09-18T02:06:55 *** Cory51 <Cory51!~Cory47@user/pasha> has joined #bitcoin-core-dev
442025-09-18T02:10:31 *** Cory47 <Cory47!~Cory44@user/pasha> has quit IRC (Ping timeout: 250 seconds)
452025-09-18T02:17:50 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
462025-09-18T02:17:58 *** thelounge496669 <thelounge496669!~thelounge@149.106.235.56> has quit IRC (Read error: Connection reset by peer)
472025-09-18T02:17:58 *** thelounge496669 <thelounge496669!~thelounge@149.106.235.56> has joined #bitcoin-core-dev
482025-09-18T02:20:01 *** _durandal <_durandal!~durandal@148.252.129.224> has quit IRC (Ping timeout: 256 seconds)
492025-09-18T02:33:07 *** _durandal <_durandal!~durandal@148.252.129.224> has joined #bitcoin-core-dev
502025-09-18T02:38:27 *** jon_atack <jon_atack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
512025-09-18T02:39:37 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 244 seconds)
522025-09-18T02:54:54 *** TheRec <TheRec!~toto@user/therec> has quit IRC (Ping timeout: 265 seconds)
532025-09-18T02:59:38 *** TheRec <TheRec!~toto@user/therec> has joined #bitcoin-core-dev
542025-09-18T03:15:23 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
552025-09-18T03:17:59 *** jon_atack <jon_atack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 258 seconds)
562025-09-18T03:32:34 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
572025-09-18T03:44:38 *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has quit IRC (Remote host closed the connection)
582025-09-18T03:44:38 *** jerryf_ <jerryf_!~jerryf@user/jerryf> has quit IRC (Remote host closed the connection)
592025-09-18T03:44:56 *** SpellChecker <SpellChecker!~SpellChec@user/SpellChecker> has joined #bitcoin-core-dev
602025-09-18T03:45:00 *** jerryf <jerryf!~jerryf@user/jerryf> has joined #bitcoin-core-dev
612025-09-18T03:51:28 *** jon_atack <jon_atack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
622025-09-18T03:53:38 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 258 seconds)
632025-09-18T04:01:01 *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
642025-09-18T04:01:31 *** cmirror <cmirror!~cmirror@4.53.92.114> has joined #bitcoin-core-dev
652025-09-18T04:04:14 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
662025-09-18T04:15:38 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Ping timeout: 256 seconds)
672025-09-18T04:17:35 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
682025-09-18T04:19:16 <_aj_> sipa: mostly i'd expect it to reduce the instances where we get a backlog in the first place, which the scaling can't really help with since it only hits when there's already a backlog. in the last couple of days, i see a bit under 60 ten minute blocks with more than 4200 txs received; versus about 8 with more than 8400 reecived (highest was ~11,540 txs between 10:50 and 10:59 on the 16th)
692025-09-18T04:26:57 *** jon_atack <jon_atack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 256 seconds)
702025-09-18T04:46:58 *** phantomcircuit_ is now known as phantomcircuit
712025-09-18T04:47:33 <phantomcircuit> it would be nice if the leveldb background compaction thread got renamed so it doesn't look like there's two msghand threads
722025-09-18T04:47:41 <phantomcircuit> (or whatever it gets duplicated from)
732025-09-18T04:48:02 <phantomcircuit> i've not a clue how to make that happen tho
742025-09-18T05:22:47 *** jackielove4u <jackielove4u!~jackielov@user/jackielove4u> has joined #bitcoin-core-dev
752025-09-18T05:48:37 *** Christoph_ <Christoph_!~Christoph@68.250.227.98> has joined #bitcoin-core-dev
762025-09-18T06:01:37 *** Christoph_ <Christoph_!~Christoph@68.250.227.98> has quit IRC (Quit: Christoph_)
772025-09-18T06:15:39 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
782025-09-18T06:35:43 *** nanotube_ <nanotube_!~nanotube@user/nanotube> has quit IRC (Ping timeout: 256 seconds)
792025-09-18T06:35:55 *** juleeho <juleeho!~juleeho@81.174.12.248> has joined #bitcoin-core-dev
802025-09-18T06:41:38 *** juleeho <juleeho!~juleeho@user/juleeho> has quit IRC (*.net *.split)
812025-09-18T06:41:38 *** thelounge496669 <thelounge496669!~thelounge@149.106.235.56> has quit IRC (*.net *.split)
822025-09-18T06:44:20 *** PaperSword1 <PaperSword1!~Thunderbi@securemail.qrsnap.io> has joined #bitcoin-core-dev
832025-09-18T06:45:56 *** thelounge496669 <thelounge496669!~thelounge@149.106.235.56> has joined #bitcoin-core-dev
842025-09-18T06:46:53 *** nanotube_ <nanotube_!~nanotube@user/nanotube> has joined #bitcoin-core-dev
852025-09-18T06:47:32 *** helo_ <helo_!~helo@user/helo> has joined #bitcoin-core-dev
862025-09-18T06:48:00 *** Earnest <Earnest!~earnest@user/earnestly> has joined #bitcoin-core-dev
872025-09-18T06:52:00 *** jackielove4u <jackielove4u!~jackielov@user/jackielove4u> has quit IRC (*.net *.split)
882025-09-18T06:52:00 *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (*.net *.split)
892025-09-18T06:52:00 *** TheRec <TheRec!~toto@user/therec> has quit IRC (*.net *.split)
902025-09-18T06:52:00 *** purpleKarrot <purpleKarrot!~purpleKar@user/purpleKarrot> has quit IRC (*.net *.split)
912025-09-18T06:52:00 *** PaperSword <PaperSword!~Thunderbi@securemail.qrsnap.io> has quit IRC (*.net *.split)
922025-09-18T06:52:00 *** Earnestly <Earnestly!~earnest@user/earnestly> has quit IRC (*.net *.split)
932025-09-18T06:52:00 *** helo <helo!~helo@user/helo> has quit IRC (*.net *.split)
942025-09-18T06:52:00 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:a908:7546:dcc7:a00b> has quit IRC (*.net *.split)
952025-09-18T06:52:00 *** javi404 <javi404!~quassel@2601:58b:4880:48b1:3beb:fd1f:824f:3caa> has quit IRC (*.net *.split)
962025-09-18T06:52:01 *** hardtotell <hardtotell!~hardtotel@user/hardtotell> has quit IRC (*.net *.split)
972025-09-18T06:52:01 *** pablomartin4btc <pablomartin4btc!~pablomart@2800:2143:2080:328::7f1d> has quit IRC (*.net *.split)
982025-09-18T06:52:01 *** stratospher[m] <stratospher[m]!~stratosph@2620:6e:a000:ce11::1e> has quit IRC (*.net *.split)
992025-09-18T06:52:01 *** cotsuka <cotsuka!~cotsuka@user/cotsuka> has quit IRC (*.net *.split)
1002025-09-18T06:52:01 *** corebot <corebot!~limnoria@user/core-meetbot> has quit IRC (*.net *.split)
1012025-09-18T06:52:02 *** PaperSword1 is now known as PaperSword
1022025-09-18T06:56:03 *** TheRec_ <TheRec_!~toto@84-74-100-31.dclient.hispeed.ch> has joined #bitcoin-core-dev
1032025-09-18T06:56:03 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:a908:7546:dcc7:a00b> has joined #bitcoin-core-dev
1042025-09-18T06:56:03 *** javi404 <javi404!~quassel@2601:58b:4880:48b1:3beb:fd1f:824f:3caa> has joined #bitcoin-core-dev
1052025-09-18T06:56:03 *** hardtotell <hardtotell!~hardtotel@user/hardtotell> has joined #bitcoin-core-dev
1062025-09-18T06:56:03 *** pablomartin4btc <pablomartin4btc!~pablomart@2800:2143:2080:328::7f1d> has joined #bitcoin-core-dev
1072025-09-18T06:56:03 *** stratospher[m] <stratospher[m]!~stratosph@2620:6e:a000:ce11::1e> has joined #bitcoin-core-dev
1082025-09-18T06:56:03 *** cotsuka <cotsuka!~cotsuka@user/cotsuka> has joined #bitcoin-core-dev
1092025-09-18T06:56:03 *** corebot <corebot!~limnoria@user/core-meetbot> has joined #bitcoin-core-dev
1102025-09-18T06:56:07 *** hardtotell <hardtotell!~hardtotel@user/hardtotell> has quit IRC (Max SendQ exceeded)
1112025-09-18T06:56:07 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:a908:7546:dcc7:a00b> has quit IRC (Max SendQ exceeded)
1122025-09-18T06:56:27 *** hardtotell <hardtotell!~hardtotel@user/hardtotell> has joined #bitcoin-core-dev
1132025-09-18T06:56:30 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:a908:7546:dcc7:a00b> has joined #bitcoin-core-dev
1142025-09-18T06:58:32 *** vincenzopalazzo <vincenzopalazzo!~vincenzop@static.14.246.108.65.clients.your-server.de> has quit IRC (Ping timeout: 256 seconds)
1152025-09-18T07:00:44 *** vincenzopalazzo <vincenzopalazzo!~vincenzop@static.14.246.108.65.clients.your-server.de> has joined #bitcoin-core-dev
1162025-09-18T07:16:54 *** f321x <f321x!~f321x@user/f321x> has joined #bitcoin-core-dev
1172025-09-18T07:23:48 *** saturday7 <saturday7!~saturday7@206.83.123.110> has quit IRC (Quit: ZNC 1.10.1 - https://znc.in)
1182025-09-18T07:28:00 *** f321x <f321x!~f321x@user/f321x> has quit IRC (Quit: f321x)
1192025-09-18T07:28:21 *** f321x <f321x!~f321x@user/f321x> has joined #bitcoin-core-dev
1202025-09-18T07:28:22 *** saturday7 <saturday7!~saturday7@206.83.123.110> has joined #bitcoin-core-dev
1212025-09-18T07:29:50 *** f321x <f321x!~f321x@user/f321x> has quit IRC (Client Quit)
1222025-09-18T07:30:07 *** f321x <f321x!~f321x@user/f321x> has joined #bitcoin-core-dev
1232025-09-18T07:39:48 *** saturday7 <saturday7!~saturday7@206.83.123.110> has quit IRC (Ping timeout: 244 seconds)
1242025-09-18T07:40:32 *** saturday7 <saturday7!~saturday7@206.83.123.110> has joined #bitcoin-core-dev
1252025-09-18T07:43:49 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
1262025-09-18T07:45:30 *** janb84 <janb84!~janb84@user/janb84> has quit IRC (Ping timeout: 248 seconds)
1272025-09-18T07:47:37 *** janb84 <janb84!~janb84@user/janb84> has joined #bitcoin-core-dev
1282025-09-18T08:13:22 *** Guyver2_ <Guyver2_!Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
1292025-09-18T08:14:27 *** rszarka <rszarka!~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809> has joined #bitcoin-core-dev
1302025-09-18T08:16:26 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has quit IRC (Ping timeout: 256 seconds)
1312025-09-18T08:16:26 *** thelounge496669 <thelounge496669!~thelounge@149.106.235.56> has quit IRC (Read error: Connection reset by peer)
1322025-09-18T08:17:49 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:a908:7546:dcc7:a00b> has quit IRC (Ping timeout: 260 seconds)
1332025-09-18T08:23:11 *** saturday7 <saturday7!~saturday7@206.83.123.110> has quit IRC (Quit: ZNC 1.10.1 - https://znc.in)
1342025-09-18T08:27:12 *** saturday7 <saturday7!~saturday7@206.83.123.110> has joined #bitcoin-core-dev
1352025-09-18T08:29:54 *** saturday7 <saturday7!~saturday7@206.83.123.110> has quit IRC (Client Quit)
1362025-09-18T08:32:52 *** saturday7 <saturday7!~saturday7@206.83.123.110> has joined #bitcoin-core-dev
1372025-09-18T08:43:47 *** Guyver2_ <Guyver2_!Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev
1382025-09-18T08:49:52 *** saturday7 <saturday7!~saturday7@206.83.123.110> has quit IRC (Quit: ZNC 1.10.1 - https://znc.in)
1392025-09-18T08:50:47 *** Cory51 <Cory51!~Cory47@user/pasha> has quit IRC (Quit: Client closed)
1402025-09-18T08:51:10 *** Cory51 <Cory51!~Cory51@user/pasha> has joined #bitcoin-core-dev
1412025-09-18T08:54:08 *** saturday7 <saturday7!~saturday7@206.83.123.110> has joined #bitcoin-core-dev
1422025-09-18T08:58:59 *** saturday7 <saturday7!~saturday7@206.83.123.110> has quit IRC (Client Quit)
1432025-09-18T09:05:54 *** vincenzopalazzo <vincenzopalazzo!~vincenzop@static.14.246.108.65.clients.your-server.de> has quit IRC (Read error: Connection reset by peer)
1442025-09-18T09:12:48 *** saturday7 <saturday7!~saturday7@206.83.123.110> has joined #bitcoin-core-dev
1452025-09-18T09:20:22 *** sdfgsdfg3d <sdfgsdfg3d!~sdfgsdfg3@2001:4479:5b06:3700:cd4d:e98e:c2c8:4fd1> has joined #bitcoin-core-dev
1462025-09-18T09:53:24 *** f321x <f321x!~f321x@user/f321x> has quit IRC (Quit: f321x)
1472025-09-18T10:22:50 *** f321x <f321x!~f321x@user/f321x> has joined #bitcoin-core-dev
1482025-09-18T10:25:50 *** sdfgsdfg3d <sdfgsdfg3d!~sdfgsdfg3@2001:4479:5b06:3700:cd4d:e98e:c2c8:4fd1> has quit IRC (Quit: Client closed)
1492025-09-18T11:07:58 <sipa> _aj_: hmm, looking at the formula, it's just BASE + (to_send.size() / 1000) * 5, so the adaptive behavior does not kick in until the backlog is 1000 txn
1502025-09-18T11:08:16 <sipa> if we think that's too much, maybe it's just the 1000 constant that should be reduced?
1512025-09-18T11:09:57 *** Christoph_ <Christoph_!~Christoph@68.250.227.98> has joined #bitcoin-core-dev
1522025-09-18T11:12:18 *** Christoph_ <Christoph_!~Christoph@68.250.227.98> has quit IRC (Client Quit)
1532025-09-18T11:14:09 <sipa> any reason not to do (BASE + to_send.size() / 200) ?
1542025-09-18T11:48:52 *** f321x <f321x!~f321x@user/f321x> has quit IRC (Remote host closed the connection)
1552025-09-18T11:49:14 *** f321x <f321x!~f321x@user/f321x> has joined #bitcoin-core-dev
1562025-09-18T11:56:01 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809> has joined #bitcoin-core-dev
1572025-09-18T11:59:10 *** rszarka <rszarka!~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809> has quit IRC (Ping timeout: 256 seconds)
1582025-09-18T12:14:39 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809> has quit IRC (Quit: Leaving)
1592025-09-18T12:14:55 *** szarka <szarka!~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809> has joined #bitcoin-core-dev
1602025-09-18T12:15:25 *** Cory51 <Cory51!~Cory51@user/pasha> has quit IRC (Quit: Client closed)
1612025-09-18T12:15:50 *** Cory51 <Cory51!~Cory51@user/pasha> has joined #bitcoin-core-dev
1622025-09-18T12:19:07 *** abubakarsadiq <abubakarsadiq!uid602234@id-602234.hampstead.irccloud.com> has joined #bitcoin-core-dev
1632025-09-18T12:25:50 <hebasto> #proposedmeetingtopic Support for Ubuntu 22.04 LTS as a build platform
1642025-09-18T12:39:26 <_aj_> sipa: the behaviour i was seeing is more the inv queue spiking to ~5000 then sticking there for a little while for a handful of nodes (presumably spy nodes who neer inv us, or poorly connected 0.1sat/vb nodes who don't have another source for many txs), for which i don't think that alternative would help much. i thought the argument that "7 tx/sec was chosen pre-segwit, and we've doubled capacity
1652025-09-18T12:39:26 <_aj_> since then so should have already switched to 14 tx/sec" made sense though? although i guess that argument was in #27630 but not re-stated in the new pr.
1662025-09-18T12:39:27 <corebot> https://github.com/bitcoin/bitcoin/issues/27630 | p2p: Increase tx relay rate by sdaftuar · Pull Request #27630 · bitcoin/bitcoin · GitHub
1672025-09-18T12:40:42 <_aj_> sipa: iirc i felt like immediately bumping the rate by +1 when the queue was >200 entries was a potential privacy leak, so thought some quantizing was a good idea
1682025-09-18T12:50:36 <sipa> _aj_: yeah, i don't object to raising it 2x, but want to reason through it a bit more
1692025-09-18T12:55:46 *** QUBIT_ABHAY <QUBIT_ABHAY!~QUBIT_ABH@user/QUBIT-ABHAY:31682> has joined #bitcoin-core-dev
1702025-09-18T12:57:19 *** purpleKarrot <purpleKarrot!~purpleKar@user/purpleKarrot> has joined #bitcoin-core-dev
1712025-09-18T13:04:30 *** QUBIT_ABHAY <QUBIT_ABHAY!~QUBIT_ABH@user/QUBIT-ABHAY:31682> has quit IRC (Quit: Client closed)
1722025-09-18T13:08:39 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has joined #bitcoin-core-dev
1732025-09-18T13:14:55 *** Guest73 <Guest73!~Guest73@143.105.151.212> has joined #bitcoin-core-dev
1742025-09-18T13:18:43 *** Guest73 <Guest73!~Guest73@143.105.151.212> has quit IRC (Client Quit)
1752025-09-18T13:29:02 <darosior> Relevant to this discussion: https://mainnet.observer/charts/transactions-per-day/
1762025-09-18T13:30:32 <darosior> The last setting was chosen in April 2016, when there was between 200-220k transactions a day. Nowadays there is between 400k and 600k transactions a day.
1772025-09-18T13:40:17 <darosior> 200k transactions a day is 2.3 tx/s. Why was the value chosen to be thrice as much?
1782025-09-18T13:41:19 <sipa> darosior: well you don't want the rate limit to be set to the expected value, because then you'll always have a backlog
1792025-09-18T13:41:36 <sipa> so you want some overshoot to account for temporary variations around the average
1802025-09-18T13:42:00 <instagibbs> aside: should we hard cap the inv queue size at some count? theoretically hard to hit but unbounded growth (even with fee payers) seems not great
1812025-09-18T13:42:48 <darosior> Ok, i was thinking of it as the default value should roughly match usage, and the temporary increase would kick in for periods of above-average usage.
1822025-09-18T13:45:55 <darosior> instagibbs: can it really be hit? Because the number of transaction you send will also grow arbitrarily large with the size of inv_to_send
1832025-09-18T13:46:55 <sipa> darosior: in the steady state, the size of the queue will be ~200x the number of transactions you receive between any two sends
1842025-09-18T13:47:39 <sipa> for sufficiently large inbound tx rate
1852025-09-18T13:47:41 <instagibbs> Probably impossible in practice due to rate limiting of peers incoming messages or something else I missed? Have a set of 100 peers send tiny high paying fee txns directly, see what happens to inv queues?
1862025-09-18T13:48:20 <darosior> instagibbs: yeah would be interesting to have a functional test for this. I suspect it would just lead you to blast INV messages to your peers.
1872025-09-18T13:48:24 <sipa> per peer you're limited by the roundtrip time of an INV-GETDATA-TX cycle, times the number of transactions permitted in txrequest
1882025-09-18T13:49:27 <instagibbs> I suppose it would be hard for attacker to get their hands on the txs fast enough, be first to send them to you unilaterally
1892025-09-18T13:52:44 <darosior> sipa: sorry could you expand on the ~200x figure? Not sure to follow.
1902025-09-18T13:53:19 <sipa> darosior: the formula for how much to send, approximated, is (invs_to_send.size() / 200)
1912025-09-18T13:53:50 <sipa> in the steady state, the amount of tx you send equals how many transactions get added to the queue in between two sends
1922025-09-18T13:54:32 <sipa> so if you receive say 300 transactions between every two sends, the queue size will tend to grow to a point where invs_to_send.size() / 200 equals 300
1932025-09-18T13:54:48 <sipa> which is when invs_to_send.size() == 200 * 300 = 60000
1942025-09-18T13:55:36 <darosior> Ok it's the "steady state" definition that i was missing. I wasn't seeing how if you receive on average 2.3 tx per second and send 35 every 5 seconds you end up with a queue of size 200 * 5 * 2.3. Thanks.
1952025-09-18T13:56:50 <sipa> darosior: well the steady state is what you end up
1962025-09-18T13:57:12 <sipa> the queue will grow until it hits that point
1972025-09-18T13:59:56 *** Christoph_ <Christoph_!~Christoph@68.250.227.98> has joined #bitcoin-core-dev
1982025-09-18T14:04:47 *** Christoph_ <Christoph_!~Christoph@68.250.227.98> has quit IRC (Client Quit)
1992025-09-18T14:06:50 * darosior clarified with sipa IRL, he was talking about instagibbs' question i was talking about _aj_'s proposal to increase the default rate
2002025-09-18T14:07:11 *** jespada <jespada!~jespada@2800:a4:2204:1500:d939:f1ea:9009:f60> has joined #bitcoin-core-dev
2012025-09-18T14:07:59 <sipa> _aj_: do we actually care about treating the size of the queue as secret for fingerprinting reasons? because an attacker observing it gets to see the actual transactions too, which seems like a much stronger signal anyway
2022025-09-18T14:08:56 <sipa> if not, i'd suggest something simpler like always send the top 20-40% (randomly selected) of the queue?
2032025-09-18T14:09:45 <sipa> darosior points out that that may mean never actually sending the bottom part
2042025-09-18T14:09:48 <instagibbs> darosior ok them I'm confused now
2052025-09-18T14:10:18 <instagibbs> just throwing an idea out there, I've not thought hard about it
2062025-09-18T14:10:34 <sipa> instagibbs: my answer to your question is: in the steady state, queue sizes (with the current formula) will grow proportionally with the incoming transaction rate
2072025-09-18T14:10:52 <instagibbs> sipa ð
2082025-09-18T14:10:57 <sipa> so they can be unbounded, but only if the incoming transaction rate is unbounded, and txgraph prevents that
2092025-09-18T14:11:00 <sipa> eh, txrequest
2102025-09-18T14:11:12 <sipa> but the rate can be pretty high
2112025-09-18T14:11:47 <darosior> txgraph txrequest txdownload
2122025-09-18T14:11:52 <instagibbs> I think it only seems problematic if nodes arent sending invs to you and direct sending
2132025-09-18T14:11:54 <darosior> tx* is the new *man
2142025-09-18T14:12:50 <sipa> needs more "mini"
2152025-09-18T14:13:43 <sipa> minitxman
2162025-09-18T14:14:32 <darosior> if we call it mini it cannot grow unbounded
2172025-09-18T14:15:59 <sipa> right
2182025-09-18T14:16:33 *** Christoph_ <Christoph_!~Christoph@68.250.227.98> has joined #bitcoin-core-dev
2192025-09-18T14:17:20 *** Cory51 <Cory51!~Cory51@user/pasha> has quit IRC (Quit: Client closed)
2202025-09-18T14:17:38 *** jespada <jespada!~jespada@2800:a4:2204:1500:d939:f1ea:9009:f60> has quit IRC (Ping timeout: 244 seconds)
2212025-09-18T14:17:44 *** Cory51 <Cory51!~Cory51@user/pasha> has joined #bitcoin-core-dev
2222025-09-18T14:26:16 <darosior> _aj_: so assuming we keep the same mechanism it makes sense to me to increase the default relay rate. This is because we've observed average transaction rate in the past years that were higher than 7 tx/s. But i'm not sure about doubling it though. We've never witnessed a sustained rate anywhere close to 14 tx/s. According to
2232025-09-18T14:26:16 <darosior> https://mainnet.observer/charts/transactions-per-day/ the highest we've been using a 30-day moving average is ~7.75 tx/s, and using a 7-day moving average 8.6 tx/s. So it seems that using 14 tx/s would not be different from not having any limit 99.9% of the time?
2242025-09-18T14:26:57 <darosior> s/the highest we've been/the highest we've seen/
2252025-09-18T14:31:18 *** Christoph_ <Christoph_!~Christoph@68.250.227.98> has quit IRC (Quit: Christoph_)
2262025-09-18T14:34:35 <sipa> another idea: add insertion time into the to_send queue, and always send everything whose insertion time is more than X seconds ago (which becomes some sort of timeout)
2272025-09-18T14:34:59 <sipa> plus X% of the highest-feerate stuff in the queue that isn't timed out yet
2282025-09-18T14:37:16 <instagibbs> dont have to sort timed out stuff either
2292025-09-18T14:37:19 <instagibbs> iiuc
2302025-09-18T14:38:17 <sipa> we may still want to, to guarantee topology
2312025-09-18T14:38:30 <sipa> and probably better for privacy anyway
2322025-09-18T14:38:31 <instagibbs> ah right
2332025-09-18T14:38:58 <instagibbs> doing stuff before sorting can help if you're *dropping* it for various reasons
2342025-09-18T14:40:18 <sipa> yet another idea is to see where transactions fit in your mempool (in terms of how many MvB from top), and send everything that's up to say 2 MvB from the top, and X% of the rest
2352025-09-18T14:44:59 *** Cory51 <Cory51!~Cory51@user/pasha> has quit IRC (Quit: Client closed)
2362025-09-18T14:45:22 *** Cory51 <Cory51!~Cory51@user/pasha> has joined #bitcoin-core-dev
2372025-09-18T14:48:01 <_aj_> instagibbs: capping the inv queue isn't great, because we sort high-fee child transactions after low-fee txs that only spend confirmed txs. maybe we could sort better with cluster mempool? alternatively, if we had rebroadcast behaviour, dropping some txs would be less of a problem
2382025-09-18T14:49:32 <instagibbs> clearly not optimal, only better than crashing
2392025-09-18T14:52:06 <_aj_> sipa: i suspect we don't care about keeping the queue size secret -- we effectively consider the contents of the mempool at inv-send-time public anyway
2402025-09-18T14:52:18 <sipa> right
2412025-09-18T14:52:51 <sipa> the primary privacy benefit the queueing/batching has is hiding the relative order of transactions
2422025-09-18T14:54:01 <_aj_> darosior: "mini-inf, another name for aleph0 or the cardinality of the integers, ..."
2432025-09-18T14:57:23 <_aj_> darosior: 2024-04-23 on that graph claims 927010 txs per day, which is 10.7/second
2442025-09-18T14:57:31 <sipa> hmmm, i think my conclusion is that we should really set the amount of transaction sent as a function of the time since the last send
2452025-09-18T14:58:24 <sipa> because it's a bandwidth consideration... we have some tx send rate that we think would be harmful for (some?) peers, and when we approach that, and can't send everything anymore, we should prefer higher-feerate things
2462025-09-18T14:59:19 <sipa> but in addition, from a personal DoS protection perspective, we need to limit the size of the queue
2472025-09-18T15:00:34 *** dzxzg <dzxzg!~qualify@user/dzxzg> has joined #bitcoin-core-dev
2482025-09-18T15:01:15 <sipa> what about: send_now = std::min(to_send.size(), time_since_last_send * R + (to_send.size() ** 2) / M)
2492025-09-18T15:01:43 <sipa> where R is the "everyone can handle this tx rate" number, and M is the maximum queue size
2502025-09-18T15:03:47 <sipa> R could be different for outbound and inbound; if not, the number of txn per inv will be lower for outbounds than for inbounds, as they have more frequent sends - but maybe that's ok
2512025-09-18T15:04:21 <_aj_> i think the main benefit of the queue is that it allows the network to prioritise relaying the high-pri/high-fee txs at a rate similar to what can be confirmed, relegating low fee backlog txs to only being relayed when there's a lull. my take is that in that context, just dropping the low fee txs and not relaying them at all would be better, provided there's some way for them to get picked back up
2522025-09-18T15:04:21 <_aj_> when the mempool empties out (which could just be "the sending wallet resubmits")
2532025-09-18T15:05:35 <sipa> _aj_: agreed, but i think dropping would be bad absent mempool retransmission - i'm not sure how reliably the network deals with resubmission on its own
2542025-09-18T15:07:21 <_aj_> sure, bip153/sendtemplate's my answer to that :)
2552025-09-18T15:07:54 <_aj_> anyone remember how many txs were in the mempool back when we had huge backlogs?
2562025-09-18T15:09:34 <_aj_> hmm, i have significantly fewer txs in my mempool than mempool.space reports (87k vs 130k?)
2572025-09-18T15:11:41 <sipa> is there an RPC to get node uptime?
2582025-09-18T15:12:10 <sipa> ah, `uptime` ~!
2592025-09-18T15:12:15 <fanquake> uptime
2602025-09-18T15:12:21 <sipa> that was way too obvious
2612025-09-18T15:12:26 <sipa> why isn't it getnodeuptimeinfo ?
2622025-09-18T15:13:43 <sipa> _aj_: i have 117230 txn right now on my long-running node's mempool (which was recently updated to 0.1 sat/kvB policy ~33 days ago)
2632025-09-18T15:13:44 *** jadi <jadi!~jadi@d75-157-6-90.bchsia.telus.net> has joined #bitcoin-core-dev
2642025-09-18T15:14:43 <sipa> eh
2652025-09-18T15:14:49 <sipa> 100 sat/kvB or 0.1 sat/vB
2662025-09-18T15:17:01 <fanquake> sipa: how long running?
2672025-09-18T15:17:07 <sipa> 33 days
2682025-09-18T15:18:52 <_aj_> #10400 ; could have gone into `getinfo`, but that was already being deprecated
2692025-09-18T15:18:55 <corebot> https://github.com/bitcoin/bitcoin/issues/10400 | [RPC] Add an uptime command that displays the amount of time (in seconds) bitcoind has been running by rvelhote · Pull Request #10400 · bitcoin/bitcoin · GitHub
2702025-09-18T15:23:15 *** dzxzg <dzxzg!~qualify@user/dzxzg> has quit IRC (Quit: Konversation terminated!)
2712025-09-18T15:23:43 *** dzxzg <dzxzg!~qualify@user/dzxzg> has joined #bitcoin-core-dev
2722025-09-18T15:23:49 *** purpleKarrot <purpleKarrot!~purpleKar@user/purpleKarrot> has quit IRC (Quit: purpleKarrot)
2732025-09-18T15:24:17 *** jadi <jadi!~jadi@d75-157-6-90.bchsia.telus.net> has quit IRC (Ping timeout: 256 seconds)
2742025-09-18T15:25:35 <_aj_> ah, a thought i had was that you could: (a) add a relayed_at timestamp to txs in the mempool, with index; (b) add a relayed_upto timestamp for each peer; (c) add txs to a peer's inv_to_send and update relayed_upto correspondingly in order, but stop once the inv_to_send hits 1000 txs; (d) sort and drain inv_to_send as currently. that way lagging peers will just get worse tx info during bursts,
2752025-09-18T15:25:35 <_aj_> without using up extra memory or compute
2762025-09-18T15:32:07 <sipa> the mempool relayed_at index would use memory?
2772025-09-18T15:32:51 <_aj_> whether or not peers lag wouldn't change how much memory was used, i mean
2782025-09-18T15:33:35 <_aj_> i'm not sure why i wanted a timestamp rather than just the mempool seq number? maybe so you could time things out? or maybe i was just confused
2792025-09-18T15:35:26 *** purpleKarrot <purpleKarrot!~purpleKar@185.240.173.188> has joined #bitcoin-core-dev
2802025-09-18T15:36:28 <_aj_> ohhh, i should read my notes. the idea was to have "rebroadcasting" happen by updating the relayed_at timestamp, but that could mean a parent's relayed_at timestamp was later than one of its children
2812025-09-18T15:37:53 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
2822025-09-18T15:38:31 <_aj_> (ie, rebroadcasting via existing methods that currently work such as the wallet or sendrawtransaction)
2832025-09-18T15:39:23 *** Cory44 <Cory44!~Cory51@user/pasha> has joined #bitcoin-core-dev
2842025-09-18T15:40:24 *** dzxzg <dzxzg!~qualify@user/dzxzg> has quit IRC (Quit: Konversation terminated!)
2852025-09-18T15:42:30 *** alvroble <alvroble!~alvroble@user/alvroble> has joined #bitcoin-core-dev
2862025-09-18T15:42:50 *** Cory51 <Cory51!~Cory51@user/pasha> has quit IRC (Quit: Client closed)
2872025-09-18T15:43:04 *** f321x <f321x!~f321x@user/f321x> has quit IRC (Quit: f321x)
2882025-09-18T15:48:01 *** QUBIT_ABHAY <QUBIT_ABHAY!~QUBIT_ABH@user/QUBIT-ABHAY:31682> has joined #bitcoin-core-dev
2892025-09-18T15:48:44 *** BGL <BGL!ninety@75.149.171.58> has quit IRC (Ping timeout: 260 seconds)
2902025-09-18T15:49:07 *** enochazariah <enochazariah!~enochazar@2c0f:f5c0:56e:19c3:8bd4:6340:ed29:c498> has joined #bitcoin-core-dev
2912025-09-18T15:49:11 *** jeremyrubin <jeremyrubin!~jeremyrub@ec2-44-199-24-18.compute-1.amazonaws.com> has joined #bitcoin-core-dev
2922025-09-18T15:49:17 <QUBIT_ABHAY> hi
2932025-09-18T15:49:29 *** dzxzg <dzxzg!~qualify@user/dzxzg> has joined #bitcoin-core-dev
2942025-09-18T15:49:32 *** enochazariah70 <enochazariah70!~enochazar@2c0f:2a80:ed:5010:f66:3de6:494d:87fc> has joined #bitcoin-core-dev
2952025-09-18T15:51:26 *** enochazariah70 <enochazariah70!~enochazar@2c0f:2a80:ed:5010:f66:3de6:494d:87fc> has quit IRC (Client Quit)
2962025-09-18T15:52:02 *** enochazariah89 <enochazariah89!~enochazar@2c0f:2a80:ed:5010:f66:3de6:494d:87fc> has joined #bitcoin-core-dev
2972025-09-18T15:53:03 *** enochazariah24 <enochazariah24!~enochazar@2c0f:2a80:ed:5010:173e:165c:d0f:7cb6> has joined #bitcoin-core-dev
2982025-09-18T15:53:22 *** enochazariah24 <enochazariah24!~enochazar@2c0f:2a80:ed:5010:173e:165c:d0f:7cb6> has quit IRC (Client Quit)
2992025-09-18T15:53:25 *** enochazariah <enochazariah!~enochazar@2c0f:f5c0:56e:19c3:8bd4:6340:ed29:c498> has quit IRC (Ping timeout: 250 seconds)
3002025-09-18T15:54:49 *** enochazariah <enochazariah!uid710351@id-710351.hampstead.irccloud.com> has joined #bitcoin-core-dev
3012025-09-18T15:56:16 *** QUBIT_ABHAY <QUBIT_ABHAY!~QUBIT_ABH@user/QUBIT-ABHAY:31682> has quit IRC (Quit: Client closed)
3022025-09-18T15:56:16 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has joined #bitcoin-core-dev
3032025-09-18T15:56:30 *** QUBIT_ABHAY <QUBIT_ABHAY!~QUBIT_ABH@user/QUBIT-ABHAY:31682> has joined #bitcoin-core-dev
3042025-09-18T15:56:53 *** enochazariah89 <enochazariah89!~enochazar@2c0f:2a80:ed:5010:f66:3de6:494d:87fc> has quit IRC (Ping timeout: 250 seconds)
3052025-09-18T15:57:01 *** Cory90 <Cory90!~Cory44@user/pasha> has joined #bitcoin-core-dev
3062025-09-18T15:59:15 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
3072025-09-18T15:59:40 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has quit IRC (Client Quit)
3082025-09-18T16:00:21 *** Cory44 <Cory44!~Cory51@user/pasha> has quit IRC (Ping timeout: 250 seconds)
3092025-09-18T16:00:32 <achow101> #startmeeting
3102025-09-18T16:00:32 <corebot> achow101: Meeting started at 2025-09-18T16:00+0000
3112025-09-18T16:00:33 <corebot> achow101: Current chairs: achow101
3122025-09-18T16:00:34 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
3132025-09-18T16:00:35 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
3142025-09-18T16:00:36 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
3152025-09-18T16:00:39 <Sjors[m]1> hi
3162025-09-18T16:00:40 <darosior> hi
3172025-09-18T16:00:41 <janb84> hi
3182025-09-18T16:00:42 <hebasto> hi
3192025-09-18T16:00:45 <dzxzg> hi hi
3202025-09-18T16:00:47 <sipa> hi
3212025-09-18T16:00:50 <achow101> #bitcoin-core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs jarolrod jonatack josibake kanzure laanwj LarryRuane lightlike luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
3222025-09-18T16:00:51 <instagibbs> hi
3232025-09-18T16:00:51 <hodlinator> hi
3242025-09-18T16:01:00 <QUBIT_ABHAY> hi
3252025-09-18T16:01:00 <pinheadmz> ðª
3262025-09-18T16:01:00 <TheCharlatan> hi
3272025-09-18T16:01:00 <abubakarsadiq> hi
3282025-09-18T16:01:03 <alvroble> hi
3292025-09-18T16:01:07 <Murch[m]> hi
3302025-09-18T16:01:09 <achow101> There is 1 preproposed meeting topic this week, any last minute ones to add?
3312025-09-18T16:01:20 <brunoerg_> hi
3322025-09-18T16:01:20 <QUBIT_ABHAY> #here
3332025-09-18T16:01:21 <lightlike> hi
3342025-09-18T16:01:49 <laanwj> hi
3352025-09-18T16:02:02 <achow101> #topic Kernel WG Update (TheCharlatan)
3362025-09-18T16:02:59 <kanzure> hi
3372025-09-18T16:03:00 <TheCharlatan> not much to share this week besides wanting to ask for review on the API PR #30595
3382025-09-18T16:03:03 <corebot> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce initial C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
3392025-09-18T16:03:11 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
3402025-09-18T16:03:18 <eugenesiegel> hi
3412025-09-18T16:03:27 <l0rinc> hi
3422025-09-18T16:03:48 <TheCharlatan> a bunch of people and teams are building on top of it now, which led to a bunch of improvements on it the past few months.
3432025-09-18T16:04:39 <TheCharlatan> that's all
3442025-09-18T16:04:46 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
3452025-09-18T16:05:03 <sipa> main PR to review remains sdaftuar's #28676
3462025-09-18T16:05:06 <corebot> https://github.com/bitcoin/bitcoin/issues/28676 | Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
3472025-09-18T16:05:19 <sipa> which has been rebased and is getting reviews addressed
3482025-09-18T16:06:03 <sipa> in parallel, i have a few other PRs; i think #33157 is close (28676 is rebased on top of that one, so it's a dependency)
3492025-09-18T16:06:06 <corebot> https://github.com/bitcoin/bitcoin/issues/33157 | cluster mempool: control/optimize TxGraph memory usage by sipa · Pull Request #33157 · bitcoin/bitcoin · GitHub
3502025-09-18T16:06:24 *** QUBIT_ABHAY <QUBIT_ABHAY!~QUBIT_ABH@user/QUBIT-ABHAY:31682> has quit IRC (Quit: Client closed)
3512025-09-18T16:06:28 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
3522025-09-18T16:07:05 <sipa> we've been talking with glozow and sdaftuar about package RBF, for after cluster mempool
3532025-09-18T16:07:08 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has quit IRC (Client Quit)
3542025-09-18T16:07:09 <jonatack> hi
3552025-09-18T16:07:37 <sipa> that's it from me, i think
3562025-09-18T16:07:43 <instagibbs> sipa I wouldnt mind being included
3572025-09-18T16:08:02 <sipa> #include "instagibbs.h"
3582025-09-18T16:08:03 <corebot> sipa: Unknown command: #include
3592025-09-18T16:08:20 <glozow> from gibbs import insta
3602025-09-18T16:08:44 <achow101> #topic Stratum v2 WG Update (sjors)
3612025-09-18T16:08:46 <Sjors[m]1> Review welcome on #33374. Would be nice to get in v30, but no need to delay the release for it.
3622025-09-18T16:08:46 <Sjors[m]1> There's also a bunch of fixes that have been backported, not sure when we want to cut rc2?
3632025-09-18T16:08:46 <Sjors[m]1> ryanofsky anything you need? Just a subtree update or more?
3642025-09-18T16:08:48 <corebot> https://github.com/bitcoin/bitcoin/issues/33374 | mining: add applySolution() to interface by Sjors · Pull Request #33374 · bitcoin/bitcoin · GitHub
3652025-09-18T16:09:18 <fanquake> sjors: how are you planning to handle version in the multiprocess subtree going forward?
3662025-09-18T16:09:23 <fanquake> *versioning
3672025-09-18T16:09:45 <Sjors[m]1> fanquake: do you mean versioning of the interface or of the multiprocess dependency?
3682025-09-18T16:10:04 <fanquake> I'm guessing release branches to match Core? Otherwise I'm wondering what the plan is if you need to land bugfixes from multiprocess that wont apply to release branches, due to api changes or similar
3692025-09-18T16:10:06 <Sjors[m]1> For the latter we should probably tag whatever is in v30
3702025-09-18T16:10:26 <fanquake> We also don't generally backport subtree updates, so this would also be new for multiprocess
3712025-09-18T16:10:49 <sipa> if a subtree has a bugfix that matters, it does seem reasonable to backport it
3722025-09-18T16:11:21 <fanquake> Sure, but that might have to be selective, rather than a full pull
3732025-09-18T16:11:27 <sipa> yeah, makes sense
3742025-09-18T16:11:28 <fanquake> so by default isn't a clean backport
3752025-09-18T16:12:07 <fanquake> so just wondering what the plan is there, and if anything is going to be done to track things upstream in the multiproess repo
3762025-09-18T16:12:53 <Sjors[m]1> Maybe ryanofsky has a specific plan. I would imagine indeed having a seperate branch to track minimal changes if anything needs to be backported to v30.1+
3772025-09-18T16:13:28 <fanquake> Ok, can leave it up to you and him to figure out going forward
3782025-09-18T16:14:33 <achow101> #topic MuSig2 WG Update (achow101)
3792025-09-18T16:14:54 <achow101> No major updates. PR to review is #29675 and I've been addressing comments.
3802025-09-18T16:14:57 <corebot> https://github.com/bitcoin/bitcoin/issues/29675 | wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys by achow101 · Pull Request #29675 · bitcoin/bitcoin · GitHub
3812025-09-18T16:14:57 *** Cory4 <Cory4!~Cory90@user/pasha> has joined #bitcoin-core-dev
3822025-09-18T16:15:29 <achow101> #topic v30.0
3832025-09-18T16:16:22 <achow101> Any new issues found in testing rc1?
3842025-09-18T16:17:09 <darosior> I think we backported a few issues we found already, any plans on an rc2?
3852025-09-18T16:17:15 <achow101> Anything to add or remove from the milestone? https://github.com/bitcoin/bitcoin/milestone/72
3862025-09-18T16:17:33 <fanquake> rc2 changes in https://github.com/bitcoin/bitcoin/pull/33424
3872025-09-18T16:17:42 <hodlinator> #32132 causes an issue on master and probably rc1 with an extra uninstall entry on Windows.
3882025-09-18T16:17:44 <corebot> https://github.com/bitcoin/bitcoin/issues/32132 | build: Remove bitness suffix from Windows installer by hebasto · Pull Request #32132 · bitcoin/bitcoin · GitHub
3892025-09-18T16:17:51 *** l0rinc_ <l0rinc_!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
3902025-09-18T16:18:07 <fanquake> rc2 backports done so far https://github.com/bitcoin/bitcoin/pull/33356
3912025-09-18T16:18:18 *** Cory21 <Cory21!~Cory4@user/pasha> has joined #bitcoin-core-dev
3922025-09-18T16:18:33 *** Cory90 <Cory90!~Cory44@user/pasha> has quit IRC (Ping timeout: 250 seconds)
3932025-09-18T16:18:41 <darosior> hodlinator: so should #33422 be added to the milestone?
3942025-09-18T16:18:41 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Ping timeout: 256 seconds)
3952025-09-18T16:18:42 <corebot> https://github.com/bitcoin/bitcoin/issues/33422 | build: Remove lingering Windows registry & shortcuts (#32132 follow-up) by hodlinator · Pull Request #33422 · bitcoin/bitcoin · GitHub
3962025-09-18T16:18:43 <achow101> added #33422 to the milestone
3972025-09-18T16:18:44 <corebot> https://github.com/bitcoin/bitcoin/issues/33422 | build: Remove lingering Windows registry & shortcuts (#32132 follow-up) by hodlinator · Pull Request #33422 · bitcoin/bitcoin · GitHub
3982025-09-18T16:18:49 <darosior> ð¤
3992025-09-18T16:19:34 <fanquake> we are so going to be cutting 29.2, 28.3 & maybe 27.3 releases in the near future
4002025-09-18T16:20:06 <darosior> ð¢
4012025-09-18T16:20:15 <hodlinator> Thanks! That or reverting the one-line change which introduced the issue, could get it in the next release.
4022025-09-18T16:21:01 <l0rinc_> Thanks for the reviews of the 2 PRs mentioned last week (#33333 and #33336)
4032025-09-18T16:21:04 <corebot> https://github.com/bitcoin/bitcoin/issues/33333 | coins: warn on oversized `-dbcache` by l0rinc · Pull Request #33333 · bitcoin/bitcoin · GitHub
4042025-09-18T16:21:08 <corebot> https://github.com/bitcoin/bitcoin/issues/33336 | log: always print initial signature verification state by l0rinc · Pull Request #33336 · bitcoin/bitcoin · GitHub
4052025-09-18T16:21:33 <l0rinc_> for the record, I've compared V30 to previous releases (23-29) and it seems V30 is exactly 2x faster than v25 thanks to all the optimization efforts in the past releases, see https://x.com/L0RINC/status/1968392472717033927
4062025-09-18T16:22:01 *** Cory4 <Cory4!~Cory90@user/pasha> has quit IRC (Ping timeout: 250 seconds)
4072025-09-18T16:23:26 <achow101> #topic Support for Ubuntu 22.04 LTS as a build platform (hebasto)
4082025-09-18T16:23:32 <hebasto> Ubuntu 22.04 reaches end of standard support in April 2027. See: https://ubuntu.com/about/release-cycle
4092025-09-18T16:23:40 <hebasto> By the time Bitcoin Core v31.0 is released, Ubuntu 26.04 LTS will be available.
4102025-09-18T16:23:46 *** jon_atack <jon_atack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
4112025-09-18T16:24:10 <hebasto> Ubuntu 22.04âs default repositories provide dependency packages that are outdated and problematic to maintain, such as: CMake 3.22.1, Qt 6.2.4, Cap'n Proto 0.8.0
4122025-09-18T16:24:18 <hebasto> Furthermore, Ubuntu 22.04âs default repositories do not provide the minimum required Clang version.
4132025-09-18T16:24:27 <hebasto> My initial proposed action was to stop considering Ubuntu 22.04 as a build platform starting from the v31 release cycle.
4142025-09-18T16:24:36 <hebasto> However, during conversation on IRC on 2025-09-09, sipa argued that we may end "in a situation where some important user chooses not to upgrade because they want to build from source, and they're stuck on an older platform"
4152025-09-18T16:24:42 <hebasto> And fanquake pointed on such real world case where "a lot of Armory users are stuck on v27 branch".
4162025-09-18T16:24:51 <sipa> do we actually have a "list of build platforms we support"?
4172025-09-18T16:25:03 <hebasto> nope, I guess
4182025-09-18T16:25:03 <fanquake> we've also since heard that a bunch of nodl (box?) users are also stuck on 27.x
4192025-09-18T16:25:20 <achow101> why are they stuck?
4202025-09-18T16:25:21 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 258 seconds)
4212025-09-18T16:25:25 <hebasto> Considering, that every problematic dependency package can be build by our own depends build subsystem, the remaining issue boils down to the minimum supported CMake version, which is 3.22 now.
4222025-09-18T16:25:28 <sipa> my impression is more that for individual upgrades/dependency requirements, we have an ad-hoc discussion for benefits vs. which use/build platforms those would drop
4232025-09-18T16:25:49 <hebasto> The question for my fellow collegues is can we ask users who will build Bitcoin Core v31+ from source on Ubuntu 22.04 to install newer CMake from https://cmake.org/download/ or from some other package manager?
4242025-09-18T16:26:03 <hebasto> If so, we can bump the minimum supported CMake version in the v31 release cycle up to 3.25, same as in Debian Bookworm (oldstable).
4252025-09-18T16:26:03 <darosior> Tangentially, i've had report of people stuck on 27 because of our glibc bump. fanquake also had some. I would suspect there is more. It probably means a lot of people that won't upgrade in case of vulnerability disclosures. I don't know the upsides to breaking support for some platform in this instance, but i'd like to underline there are
4262025-09-18T16:26:03 <darosior> substantial downsides to doing so.
4272025-09-18T16:26:20 <sipa> fanquake, darosior: but that's due to runtime requirements, not build time?
4282025-09-18T16:26:23 *** QUBIT_ABHAY <QUBIT_ABHAY!~QUBIT_ABH@user/QUBIT-ABHAY:31682> has joined #bitcoin-core-dev
4292025-09-18T16:26:25 <fanquake> Why do we need to bump the minimum required CMake version?
4302025-09-18T16:26:30 <hebasto> This gives us a few useful features such as (1) file sets; (2) `COMPILE_WARNING_AS_ERROR`; (3) better support for IPO/LTO; (4) scope management
4312025-09-18T16:26:51 <sipa> hebasto: can we use those feature optionally?
4322025-09-18T16:26:54 <darosior> achow101: the nodl boxes are stuck because of our glibc bump in 28
4332025-09-18T16:26:58 <hebasto> Very useful for ongoing libkernel development
4342025-09-18T16:26:59 <sipa> (i'm guessing no from 1 and 4, yes for 2 and 3)
4352025-09-18T16:27:07 *** jadi <jadi!~jadi@d75-157-6-90.bchsia.telus.net> has joined #bitcoin-core-dev
4362025-09-18T16:27:08 <fanquake> These seem like things that might be mostly nice for cmake devs/
4372025-09-18T16:27:14 <fanquake> *?
4382025-09-18T16:27:44 <achow101> I would prefer that we support platforms that are still in use and supported by upstream
4392025-09-18T16:27:47 <hebasto> sipa: some of them, yes
4402025-09-18T16:28:09 <achow101> if ubuntu 22.04 is supported until 2027, i'd rather not drop support for it until it is eol
4412025-09-18T16:28:17 <darosior> sipa: yes, my examples are runtime, that's why i said it's only tangentially related
4422025-09-18T16:28:46 <sipa> achow101: agreed
4432025-09-18T16:28:57 <darosior> achow101: +1
4442025-09-18T16:29:02 <hebasto> achow101: users still able build on ubuntu 22.04; they will need to install newer cmake
4452025-09-18T16:29:04 <fanquake> It'd atleast be good to see an example of changes that could be made after dropping. Hard to infer the benefits from that list
4462025-09-18T16:29:45 <fanquake> Also, what version are you trying to bump the minimum to?
4472025-09-18T16:29:46 <achow101> hebasto: I don't think asking users to update a dependency from external sources is a reasonable ask
4482025-09-18T16:29:59 <hebasto> fair
4492025-09-18T16:30:05 <sipa> specifically for (2), i think it's not unreasonable to enable it whenever cmake is recent enough, and not otherwise - which will give the benefit for most people who compile, but not break compatibility?
4502025-09-18T16:30:06 <fanquake> Oh, I see 3.25
4512025-09-18T16:30:32 <fanquake> sipa: not that we already also have that feature
4522025-09-18T16:30:35 <fanquake> *note
4532025-09-18T16:30:41 *** QUBIT_ABHAY <QUBIT_ABHAY!~QUBIT_ABH@user/QUBIT-ABHAY:31682> has quit IRC (Ping timeout: 250 seconds)
4542025-09-18T16:30:46 <fanquake> We just aren't using the CMake *thing*
4552025-09-18T16:30:55 <sipa> fanquake: sure, but we can simplify the cmake code with that feature, i assume - which is still possible by using it optionally
4562025-09-18T16:31:28 <fanquake> I'd think that'd be more code, if we retain the old way, and add the new way
4572025-09-18T16:31:37 <hebasto> ^ true
4582025-09-18T16:31:39 <fanquake> unless you mean drop support of the feature for older users
4592025-09-18T16:31:41 <sipa> fanquake: no, i mean use the new way, drop the old way
4602025-09-18T16:32:08 <hebasto> that needs bump the minimum supported version
4612025-09-18T16:32:08 <sipa> because people who care about the feature will almost certainly be on a new platform anyway (they're developers, not builders-on-old-platform-who-just-want-it-to-work)
4622025-09-18T16:32:32 <sipa> hebasto: can you not enable it optionally?
4632025-09-18T16:33:07 <hebasto> features that depends on cmake policy can be enabled optionally
4642025-09-18T16:33:12 <dzxzg> Won't the flag just be ignored if used in a cmake version below 3.24?
4652025-09-18T16:33:34 <hebasto> but also there are language features
4662025-09-18T16:33:52 <l0rinc_> do we need to add a separate CI build with an old cmake version in that case?
4672025-09-18T16:33:54 <hebasto> yes; with more coding
4682025-09-18T16:34:39 <sipa> (if we're done with this topic, i'd like to also discuss the possibility of bringing back runtime compatibility with glibc 2.28 (or whatever it is that causes the reports of people unable to upgrade))
4692025-09-18T16:35:59 <achow101> how difficult would it be to do that?
4702025-09-18T16:36:23 <fanquake> Have to look at undoing a number of changes in Guix
4712025-09-18T16:36:43 <fanquake> If people are trying to run on glibc < 2.28, I'm guessing this is on Ubuntu Bionic. Which shipped with 2.27
4722025-09-18T16:36:45 <hebasto> if I recall correctly, there were issues with qt as well
4732025-09-18T16:37:07 <darosior> One thing they could do to have new-bitcoind compatibility in their old machines would be to dockerize it. It's not impossible, but a bunch more work for them and therefore they're not doing it.
4742025-09-18T16:37:10 <fanquake> Bionic went EOL sometime in 2023 I think
4752025-09-18T16:37:11 <achow101> The bump was #29987
4762025-09-18T16:37:15 <corebot> https://github.com/bitcoin/bitcoin/issues/29987 | guix: build with glibc 2.31 by fanquake · Pull Request #29987 · bitcoin/bitcoin · GitHub
4772025-09-18T16:38:12 <fanquake> Would have to check if our current GCC would compile 2.27
4782025-09-18T16:38:48 <sipa> hebasto: i'm less concerned about that, i assume people stuck on old platforms tend to use bitcoind as a backend, not the gui
4792025-09-18T16:39:38 <fanquake> darosior: or we start shipping a flavour of static musl rel builds
4802025-09-18T16:39:40 <hebasto> I agree, than gui probably should excluded from guix script for that purpose
4812025-09-18T16:40:05 <darosior> fanquake: ðï¸
4822025-09-18T16:40:25 <fanquake> rebased my old branch for doing that earlier today: https://github.com/fanquake/bitcoin/tree/depends_musl_cross_make
4832025-09-18T16:40:38 <fanquake> Athough not sure we'd take that approach
4842025-09-18T16:40:53 <sipa> fanquake: what are the downsides, besides it being less well tested?
4852025-09-18T16:41:05 *** Cory21 <Cory21!~Cory4@user/pasha> has quit IRC (Quit: Client closed)
4862025-09-18T16:41:26 *** Cory21 <Cory21!~Cory21@user/pasha> has joined #bitcoin-core-dev
4872025-09-18T16:41:29 <fanquake> Less tested, would need to check if all the targets we support would work
4882025-09-18T16:41:40 <darosior> sipa: might not be consensus compatible
4892025-09-18T16:41:41 <fanquake> Although I guess if we ship x86_64 and aarch64, that'd probably cover most users
4902025-09-18T16:41:46 * darosior hides
4912025-09-18T16:41:51 <sipa> darosior: only if there are bugs in it :p
4922025-09-18T16:42:30 <sipa> another possibility is having separate static-linux and modern-linux release builds
4932025-09-18T16:42:37 <darosior> Differential fuzzing across libc's is something that came up recently when chatting with external people looking into fuzzing Core
4942025-09-18T16:42:38 <fanquake> would also mean splitting the guix build in two, either to do a lts & the current build, or some sort of static bitcoind + utils & gui separate
4952025-09-18T16:42:44 <sipa> i'm less a fan of that due to splitting testing, though
4962025-09-18T16:42:56 <sipa> fanquake: multiprocess gui lalala
4972025-09-18T16:43:05 <fanquake> we are already shipping releases built against different libc++ flavours
4982025-09-18T16:43:38 <darosior> fanquake: for MacOS, right?
4992025-09-18T16:43:44 <fanquake> I will do a POC in any case
5002025-09-18T16:43:54 <sipa> fanquake: cool, curious about what you find
5012025-09-18T16:44:02 <fanquake> darosior: yea, clang & libc++ for macOS, gcc & libstdc++ for linux
5022025-09-18T16:44:18 <sipa> does libc++ have its own libc?
5032025-09-18T16:44:22 <darosior> im sure nobody mines on macos :p
5042025-09-18T16:44:22 <sipa> or does it use glibc
5052025-09-18T16:44:24 <fanquake> they are working on it
5062025-09-18T16:44:31 <fanquake> https://libc.llvm.org/
5072025-09-18T16:44:33 *** QUBIT_ABHAY <QUBIT_ABHAY!~QUBIT_ABH@user/QUBIT-ABHAY:31682> has joined #bitcoin-core-dev
5082025-09-18T16:44:39 <sipa> of course they are
5092025-09-18T16:44:45 <sipa> what's next, their own kernel?
5102025-09-18T16:44:45 <fanquake> It's getting close to the point where you can bootstrap libc++ against it
5112025-09-18T16:45:08 <fanquake> we'll ship an LLVM OS container with bitcoind entrypoint
5122025-09-18T16:45:30 <darosior> compatibility: solved
5132025-09-18T16:45:48 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has quit IRC (Quit: Client closed)
5142025-09-18T16:46:28 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has joined #bitcoin-core-dev
5152025-09-18T16:46:59 <achow101> Any other topics to discuss?
5162025-09-18T16:48:30 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
5172025-09-18T16:48:31 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
5182025-09-18T16:49:14 <achow101> #endmeeting
5192025-09-18T16:49:14 <corebot> achow101: Meeting ended at 2025-09-18T16:49+0000
5202025-09-18T16:49:15 <corebot> achow101: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-09-18_16_00.log.json
5212025-09-18T16:49:16 <corebot> achow101: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-09-18_16_00.log.html
5222025-09-18T16:49:17 <corebot> achow101: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-09-18_16_00.html
5232025-09-18T16:50:17 <fanquake> For anyone interested, this was a prior look at staticly built bitcoind (with a similar branch): https://github.com/bitcoin/bitcoin/pull/23203
5242025-09-18T16:50:25 *** jon_atack <jon_atack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 256 seconds)
5252025-09-18T16:51:03 *** QUBIT_ABHAY <QUBIT_ABHAY!~QUBIT_ABH@user/QUBIT-ABHAY:31682> has quit IRC (Ping timeout: 250 seconds)
5262025-09-18T16:51:46 *** dzxzg <dzxzg!~qualify@user/dzxzg> has quit IRC (Quit: Konversation terminated!)
5272025-09-18T16:54:59 *** l0rinc_ <l0rinc_!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc_)
5282025-09-18T16:56:14 *** Holz <Holz!~Holz@user/Holz> has joined #bitcoin-core-dev
5292025-09-18T16:57:22 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
5302025-09-18T16:59:02 *** jon_atack <jon_atack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
5312025-09-18T17:00:54 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 244 seconds)
5322025-09-18T17:02:49 *** conman <conman!~con@180-150-21-3.b49615.mel.static.aussiebb.net> has joined #bitcoin-core-dev
5332025-09-18T17:02:50 *** cman <cman!~con@180-150-21-3.b49615.mel.static.aussiebb.net> has quit IRC (Ping timeout: 248 seconds)
5342025-09-18T17:06:56 *** eugenesiegel <eugenesiegel!~eugenesie@user/eugenesiegel> has quit IRC (Quit: Client closed)
5352025-09-18T17:09:56 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
5362025-09-18T17:10:22 *** purpleKarrot <purpleKarrot!~purpleKar@185.240.173.188> has quit IRC (Quit: purpleKarrot)
5372025-09-18T17:13:58 *** BGL <BGL!eighty@75.149.171.58> has joined #bitcoin-core-dev
5382025-09-18T17:24:15 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has quit IRC (Quit: Christoph_)
5392025-09-18T17:31:48 *** jadi <jadi!~jadi@d75-157-6-90.bchsia.telus.net> has quit IRC (Ping timeout: 256 seconds)
5402025-09-18T17:32:00 <darosior> _aj_: re "2024-04-22 on that graph claims 927010 txs per day" -> sure if you use a 1-day moving average but in this case you should rely on the adjustment mechanism, shouldn't you? It seems suboptimal to use the highest, least sustained, transaction rate as the default. Because it means every day of the year except one you will end up not limiting
5412025-09-18T17:32:00 <darosior> anything?
5422025-09-18T17:35:39 *** Talkless <Talkless!~Talkless@138.199.6.197> has joined #bitcoin-core-dev
5432025-09-18T17:43:46 <sipa> darosior: i think the number should be more picked based on what we see averaged over windows of maybe minutes or so?
5442025-09-18T17:44:03 <sipa> which i'm guessing can be many times larger
5452025-09-18T17:44:19 *** jon_atack <jon_atack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 258 seconds)
5462025-09-18T17:44:19 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
5472025-09-18T17:45:01 <darosior> Isn't it more appropriate for short burst to rely on the dynamic relay rate mechanism, and choose the default for what's most commonly observed?
5482025-09-18T17:46:06 <sipa> i think the dynamic rate is to protect against "inv queue growing unbounded", not for normal the this-is-fine rate
5492025-09-18T17:47:32 <sipa> like, i assume the network can deal just fine with a fairly nontrivial multiple of the average rate
5502025-09-18T17:48:04 <sipa> there's no reason to limit anything when the actual rate is below that, if we don't care about the hiding-size-of-queue privacy
5512025-09-18T17:49:27 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
5522025-09-18T17:51:12 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
5532025-09-18T17:54:27 *** dzxzg <dzxzg!~dzxzg@user/dzxzg> has joined #bitcoin-core-dev
5542025-09-18T17:56:07 <darosior> Ok that makes sense to me, thanks.
5552025-09-18T17:56:58 <sipa> 11:01:15 < sipa> what about: send_now = std::min(to_send.size(), time_since_last_send * R + (to_send.size() ** 2) / M)
5562025-09-18T17:57:02 <sipa> i still like this
5572025-09-18T17:57:04 *** alvroble <alvroble!~alvroble@user/alvroble> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
5582025-09-18T18:01:06 <darosior> 11:01 <sipa> where R is the "everyone can handle this tx rate" number, and M is the maximum queue size
5592025-09-18T18:05:29 *** jadi <jadi!~jadi@d75-157-6-90.bchsia.telus.net> has joined #bitcoin-core-dev
5602025-09-18T18:05:51 <darosior> So assuming R would be our current relay rate, time_since_last_send * R is what we do under normal conditions today. So this only differs in how we clear the queue faster when it gets too large, which today is `to_send.size() / M * 5`.
5612025-09-18T18:06:15 <fanquake> Do we want to do this PR for 30? (#28592)
5622025-09-18T18:06:18 <corebot> https://github.com/bitcoin/bitcoin/issues/28592 | p2p: Increase tx relay rate by ajtowns · Pull Request #28592 · bitcoin/bitcoin · GitHub
5632025-09-18T18:06:28 <darosior> fanquake: i was thinking about it.
5642025-09-18T18:06:41 <darosior> It kinda makes sense to go along with reducing the minrelaytxfee
5652025-09-18T18:06:54 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has quit IRC (Quit: Leaving)
5662025-09-18T18:07:02 <fanquake> Will put it on the milestone, can decide
5672025-09-18T18:07:40 <darosior> (re sipa's formula) The real difference is taking the square of the size of the queue rather than multiplying it by 5. That makes sense, but does it make that much of a difference in practice? I guess it gives clearer guarantees we won't OOM instagibbs.
5682025-09-18T18:08:28 <sipa> darosior: at low rates i think it's more consistent too (by scaling with actual time between sends, not just the average)
5692025-09-18T18:08:33 <sipa> but that's a minor point
5702025-09-18T18:08:49 <dzxzg> dumb question: why not just be a function of the queue size? is it to set a floor on the relay rate?
5712025-09-18T18:08:59 <darosior> Ah right time_since_last_send isn't exactly what we do today
5722025-09-18T18:09:04 <sipa> dzxzg: it is a function of the queue size right now
5732025-09-18T18:09:10 <sipa> and yes, i think it should be
5742025-09-18T18:10:08 *** jadi <jadi!~jadi@d75-157-6-90.bchsia.telus.net> has quit IRC (Ping timeout: 244 seconds)
5752025-09-18T18:11:07 <sipa> currently it is std::min(to_send.size(), B + (to_send.size() / 1000) * 5)
5762025-09-18T18:12:13 <darosior> sipa: ACK you formula. I think it makes it easier to reason about the growth of the queue.
5772025-09-18T18:14:46 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Read error: Connection reset by peer)
5782025-09-18T18:14:59 <sipa> dzxzg: i think i don't understand your question
5792025-09-18T18:15:08 <dzxzg> sipa: My question is why use `R` instead of only being a function of `M`
5802025-09-18T18:15:17 <dzxzg> sorry not M I mean queue size
5812025-09-18T18:15:28 <dzxzg> but I guess then the queue would not clear when it gets smal
5822025-09-18T18:15:31 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
5832025-09-18T18:16:12 <sipa> dzxzg: yeah, it'd mean the queue really never completely drains, which seems silly (for propagation speed, etc) when it's low enough that the network can just deal fine with it
5842025-09-18T18:20:58 *** jackielove4u <jackielove4u!~jackielov@user/jackielove4u> has joined #bitcoin-core-dev
5852025-09-18T18:22:49 *** jadi <jadi!~jadi@d75-157-6-90.bchsia.telus.net> has joined #bitcoin-core-dev
5862025-09-18T18:24:13 *** jon_atack <jon_atack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
5872025-09-18T18:26:06 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 258 seconds)
5882025-09-18T18:28:14 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
5892025-09-18T18:28:21 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
5902025-09-18T18:30:43 *** jon_atack <jon_atack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 256 seconds)
5912025-09-18T18:32:28 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
5922025-09-18T18:34:56 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 244 seconds)
5932025-09-18T18:41:12 *** jerryf <jerryf!~jerryf@user/jerryf> has quit IRC (Ping timeout: 272 seconds)
5942025-09-18T18:41:26 *** jerryf <jerryf!~jerryf@user/jerryf> has joined #bitcoin-core-dev
5952025-09-18T18:46:26 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
5962025-09-18T18:53:26 *** Cory21 <Cory21!~Cory21@user/pasha> has quit IRC (Quit: Client closed)
5972025-09-18T18:53:31 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
5982025-09-18T18:53:47 *** Cory21 <Cory21!~Cory21@user/pasha> has joined #bitcoin-core-dev
5992025-09-18T18:54:20 *** enochazariah <enochazariah!uid710351@id-710351.hampstead.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
6002025-09-18T18:56:46 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
6012025-09-18T19:00:03 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has quit IRC (Quit: Christoph_)
6022025-09-18T19:07:48 *** Cory33 <Cory33!~Cory21@user/pasha> has joined #bitcoin-core-dev
6032025-09-18T19:11:27 *** Cory21 <Cory21!~Cory21@user/pasha> has quit IRC (Ping timeout: 250 seconds)
6042025-09-18T19:23:48 *** Talkless <Talkless!~Talkless@138.199.6.197> has quit IRC (Quit: Konversation terminated!)
6052025-09-18T19:42:23 *** conman <conman!~con@180-150-21-3.b49615.mel.static.aussiebb.net> has quit IRC (Ping timeout: 258 seconds)
6062025-09-18T19:43:38 *** hernanmarino <hernanmarino!~hernanmar@2800:2330:2840:4de:6ced:6815:210c:cf51> has joined #bitcoin-core-dev
6072025-09-18T19:54:55 *** enochazariah <enochazariah!uid710351@id-710351.hampstead.irccloud.com> has joined #bitcoin-core-dev
6082025-09-18T20:04:37 *** Cory56 <Cory56!~Cory33@user/pasha> has joined #bitcoin-core-dev
6092025-09-18T20:08:39 *** Cory33 <Cory33!~Cory21@user/pasha> has quit IRC (Ping timeout: 250 seconds)
6102025-09-18T20:11:10 *** thoragh <thoragh!~username@user/thoragh> has joined #bitcoin-core-dev
6112025-09-18T20:18:41 <hodlinator> I've shaped up #33422 (the one added to the v30 milestone today) a bit and added some illustrative/motivating screenshots. Just waiting for fellow Windows fans to review. :)
6122025-09-18T20:18:43 <corebot> https://github.com/bitcoin/bitcoin/issues/33422 | build: Remove lingering Windows registry & shortcuts (#32132 follow-up) by hodlinator · Pull Request #33422 · bitcoin/bitcoin · GitHub
6132025-09-18T20:19:32 *** hernanmarino <hernanmarino!~hernanmar@2800:2330:2840:4de:6ced:6815:210c:cf51> has quit IRC (Ping timeout: 256 seconds)
6142025-09-18T20:21:36 *** hernanmarino <hernanmarino!~hernanmar@181.85.54.57> has joined #bitcoin-core-dev
6152025-09-18T21:14:12 <dzxzg> ah, ok so the reason the current formula is so bad is that the inbound transaction rate (n) required to sustain a queue size of 1000
6162025-09-18T21:14:22 <dzxzg> is n - R = 5
6172025-09-18T21:15:43 <dzxzg> with sipa's formula it's n - R = M
6182025-09-18T21:16:32 <dzxzg> (n = R + 5M/M and n = R + M^2/M)
6192025-09-18T21:21:59 <dzxzg> and the time to clear (when n = 0)for a queue k if no new tx'es arrive is sqrt(M / R) * arctan ( k / sqrt(M * R) ) in sipa's suggested formula and (M / 5) * ln|1 + 5k/MR| in the current formula
6202025-09-18T21:22:00 <dzxzg> with M=1000 and R=7: 11.95 * arctan(k/83.6) in the quadratic formula and 200 * ln|1 + k/1400| in the linear formula, with arctan(inf) = pi/2, the quadratic formula is bounded to never take longer than ~18.77 seconds to clear the queue if there are no inbound transactions
6212025-09-18T21:22:33 <sipa> ... arctan :o
6222025-09-18T21:23:31 <sipa> (i didn't expect that function to show up here, not saying it's wrong!)
6232025-09-18T21:31:29 *** jadi <jadi!~jadi@d75-157-6-90.bchsia.telus.net> has quit IRC (Ping timeout: 256 seconds)
6242025-09-18T21:33:25 <dzxzg> My math could definitely be wrong: I got that from integrating dk / (R + k^2/M) and using â«dx/(a^2 + x^2) = 1/a * arctan(x/a) + C
6252025-09-18T21:38:06 *** conman <conman!~con@180-150-21-3.b49615.mel.static.aussiebb.net> has joined #bitcoin-core-dev
6262025-09-18T21:42:32 *** cman <cman!~con@180-150-21-3.b49615.mel.static.aussiebb.net> has joined #bitcoin-core-dev
6272025-09-18T21:42:49 *** conman <conman!~con@180-150-21-3.b49615.mel.static.aussiebb.net> has quit IRC (Ping timeout: 256 seconds)
6282025-09-18T21:46:48 *** Cory56 <Cory56!~Cory33@user/pasha> has quit IRC (Quit: Client closed)
6292025-09-18T21:47:08 *** jadi <jadi!~jadi@d75-157-6-90.bchsia.telus.net> has joined #bitcoin-core-dev
6302025-09-18T21:47:10 *** Cory56 <Cory56!~Cory56@user/pasha> has joined #bitcoin-core-dev
6312025-09-18T21:50:36 *** kevkevin <kevkevin!~kevkevin@12.161.6.169> has joined #bitcoin-core-dev
6322025-09-18T21:53:45 *** kevkevin <kevkevin!~kevkevin@12.161.6.169> has quit IRC (Remote host closed the connection)
6332025-09-18T21:54:44 *** jadi <jadi!~jadi@d75-157-6-90.bchsia.telus.net> has quit IRC (Ping timeout: 256 seconds)
6342025-09-18T21:58:58 *** thoragh <thoragh!~username@user/thoragh> has quit IRC (Read error: Connection reset by peer)
6352025-09-18T22:00:58 <dzxzg> ah ok, there was a little bit of a mistake in my equilibrium formula above for the current fomula: to sustain a queue size of 1000 you need n - R = 1
6362025-09-18T22:02:16 <dzxzg> a new transaction rate of 8 tx/s would cause the queue to grow until it reached 1000 and then stay there
6372025-09-18T22:03:09 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
6382025-09-18T22:04:20 *** enochazariah <enochazariah!uid710351@id-710351.hampstead.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
6392025-09-18T22:04:57 *** kevkevin <kevkevin!~kevkevin@12.161.6.169> has joined #bitcoin-core-dev
6402025-09-18T22:08:38 *** kevkevin <kevkevin!~kevkevin@12.161.6.169> has quit IRC (Remote host closed the connection)
6412025-09-18T22:15:49 *** kevkevin <kevkevin!~kevkevin@12.161.6.169> has joined #bitcoin-core-dev
6422025-09-18T22:25:39 *** kevkevin_ <kevkevin_!~kevkevin@2607:fb91:bd14:4938:80ac:688:90fb:1d40> has joined #bitcoin-core-dev
6432025-09-18T22:27:50 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
6442025-09-18T22:28:37 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
6452025-09-18T22:29:08 *** kevkevin <kevkevin!~kevkevin@12.161.6.169> has quit IRC (Ping timeout: 258 seconds)
6462025-09-18T22:29:53 *** kevkevin_ <kevkevin_!~kevkevin@2607:fb91:bd14:4938:80ac:688:90fb:1d40> has quit IRC (Remote host closed the connection)
6472025-09-18T22:56:43 *** dzxzg <dzxzg!~dzxzg@user/dzxzg> has quit IRC (Remote host closed the connection)
6482025-09-18T22:57:15 *** aleggg <aleggg!~aleggg@177.188.150.31> has quit IRC (Remote host closed the connection)
6492025-09-18T22:57:44 *** jadi <jadi!~jadi@d75-157-6-90.bchsia.telus.net> has joined #bitcoin-core-dev
6502025-09-18T22:58:26 *** saturday7 <saturday7!~saturday7@206.83.123.110> has quit IRC (Quit: ZNC 1.10.1 - https://znc.in)
6512025-09-18T23:02:14 *** saturday7 <saturday7!~saturday7@206.83.123.110> has joined #bitcoin-core-dev
6522025-09-18T23:02:53 *** aleggg <aleggg!~aleggg@177.188.150.31> has joined #bitcoin-core-dev
6532025-09-18T23:06:58 *** PatBoy <PatBoy!xyz@cryption.cn> has joined #bitcoin-core-dev
6542025-09-18T23:07:08 *** P8tBoy <P8tBoy!xyz@cryption.cn> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in)
6552025-09-18T23:09:51 *** Henry151_ <Henry151_!~Henry151@user/henry151> has quit IRC (Remote host closed the connection)
6562025-09-18T23:09:57 *** zumbi <zumbi!~zumbi@debian/zumbi> has quit IRC (Ping timeout: 260 seconds)
6572025-09-18T23:10:00 *** Henry151 <Henry151!~Henry151@user/henry151> has joined #bitcoin-core-dev
6582025-09-18T23:10:26 *** zumbi <zumbi!~zumbi@debian/zumbi> has joined #bitcoin-core-dev
6592025-09-18T23:12:42 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has quit IRC (Quit: l0rinc)
6602025-09-18T23:19:28 *** l0rinc <l0rinc!~l0rinc@user/l0rinc> has joined #bitcoin-core-dev
6612025-09-18T23:28:54 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has quit IRC (Quit: Christoph_)
6622025-09-18T23:43:38 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
6632025-09-18T23:54:02 *** Christoph_ <Christoph_!~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net> has quit IRC (Quit: Christoph_)