12025-01-30T00:06:58 *** PaperSword1 <PaperSword1!~Thunderbi@securemail.qrsnap.io> has joined #bitcoin-core-dev
22025-01-30T00:08:44 *** PaperSword <PaperSword!~Thunderbi@ec2-3-129-110-246.us-east-2.compute.amazonaws.com> has quit IRC (Ping timeout: 260 seconds)
32025-01-30T00:08:49 *** PaperSword1 is now known as PaperSword
42025-01-30T00:40:00 <glozow> sipa instagibbs: hm yeah, there are various places with looping... e.g. what happens if you have 100 inbounds and they each announce 10k of the same small transactions to you. it's going to take a long time to finally evict an orphan because you're removing them as announcers one by one
52025-01-30T00:40:30 <glozow> I'm now quite interested in the idea of having separate orphanages for inbounds and outbounds
62025-01-30T02:13:34 *** PaperSword1 <PaperSword1!~Thunderbi@ec2-3-129-110-246.us-east-2.compute.amazonaws.com> has joined #bitcoin-core-dev
72025-01-30T02:14:59 *** PaperSword <PaperSword!~Thunderbi@securemail.qrsnap.io> has quit IRC (Ping timeout: 245 seconds)
82025-01-30T02:14:59 *** PaperSword1 is now known as PaperSword
92025-01-30T02:17:57 *** PaperSword1 <PaperSword1!~Thunderbi@securemail.qrsnap.io> has joined #bitcoin-core-dev
102025-01-30T02:19:30 *** PaperSword <PaperSword!~Thunderbi@ec2-3-129-110-246.us-east-2.compute.amazonaws.com> has quit IRC (Ping timeout: 248 seconds)
112025-01-30T02:19:30 *** PaperSword1 is now known as PaperSword
122025-01-30T02:58:43 *** greypw149508 <greypw149508!~greypw@user/greypw> has quit IRC (Remote host closed the connection)
132025-01-30T02:58:59 *** greypw149508 <greypw149508!~greypw@user/greypw> has joined #bitcoin-core-dev
142025-01-30T03:08:03 <sipa> glozow: is this with a global (weight) limit, or a per-peer weight limit (ignoring count limit for this)
152025-01-30T03:17:13 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
162025-01-30T03:35:26 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
172025-01-30T03:46:50 *** PaperSword1 <PaperSword1!~Thunderbi@ec2-3-129-110-246.us-east-2.compute.amazonaws.com> has joined #bitcoin-core-dev
182025-01-30T03:48:37 *** PaperSword <PaperSword!~Thunderbi@securemail.qrsnap.io> has quit IRC (Ping timeout: 248 seconds)
192025-01-30T03:48:37 *** PaperSword1 is now known as PaperSword
202025-01-30T03:51:34 *** Guest27 <Guest27!~Guest27@2a09:bac2:a20d:6e::b:25e> has joined #bitcoin-core-dev
212025-01-30T03:52:42 *** Guest27 <Guest27!~Guest27@2a09:bac2:a20d:6e::b:25e> has quit IRC (Client Quit)
222025-01-30T03:56:05 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 248 seconds)
232025-01-30T03:56:29 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
242025-01-30T04:01:21 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Read error: Connection reset by peer)
252025-01-30T04:02:11 *** PaperSword1 <PaperSword1!~Thunderbi@ec2-3-129-110-246.us-east-2.compute.amazonaws.com> has joined #bitcoin-core-dev
262025-01-30T04:02:38 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
272025-01-30T04:03:28 *** PaperSword <PaperSword!~Thunderbi@ec2-3-129-110-246.us-east-2.compute.amazonaws.com> has quit IRC (Ping timeout: 244 seconds)
282025-01-30T04:03:28 *** PaperSword1 is now known as PaperSword
292025-01-30T04:10:19 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Read error: Connection reset by peer)
302025-01-30T04:12:36 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
312025-01-30T04:23:27 <glozow> sipa: this is with a per-peer weight limit
322025-01-30T04:24:01 <glozow> er wait, "this" = how we get the problem with looping a lot before we evict something?
332025-01-30T04:41:42 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has quit IRC (Quit: leaving)
342025-01-30T05:01:01 *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
352025-01-30T05:01:32 *** cmirror <cmirror!~cmirror@4.53.92.114> has joined #bitcoin-core-dev
362025-01-30T05:39:18 *** agentcasey <agentcasey!agentcasey@2600:3c03::f03c:93ff:febe:5054> has quit IRC (Read error: Connection reset by peer)
372025-01-30T05:41:02 *** agentcasey <agentcasey!agentcasey@2600:3c03::f03c:93ff:febe:5054> has joined #bitcoin-core-dev
382025-01-30T06:01:05 *** mcey_ <mcey_!~emcy@148.252.144.118> has quit IRC (Remote host closed the connection)
392025-01-30T06:01:18 *** mcey_ <mcey_!~emcy@148.252.144.118> has joined #bitcoin-core-dev
402025-01-30T06:37:57 *** MyNetAz <MyNetAz!~MyNetAz@user/MyNetAz> has joined #bitcoin-core-dev
412025-01-30T07:36:20 <_aj_> glozow: if each of 100 inbounds announce the same 10k txs -- you add each tx to the orphan request tracker, prioritized randomly, hit the per-peer-limit as you're going, remove that peer's lowest priority tx, repeat? those should all be O(log(peers*peer_orphan_count_limit)) ? the peer_orphan_count_limit should presumably be lower than MAX_PEER_TX_ANNOUNCEMENTS=5000 since you need to keep the orphan
422025-01-30T07:36:20 <_aj_> tx around, not just a txid
432025-01-30T07:51:57 <glozow> _aj_: are you thinking of the orphan request tracker TxRequestTracker?
442025-01-30T07:52:30 <_aj_> glozow: yeah?
452025-01-30T07:52:33 <glozow> (In this situation we're remembering which invs correspond to which orphan txns so we can drop them right?)
462025-01-30T07:53:22 <glozow> ok so, we ended up dropping that, and just add the parent txids to normal `m_txrequest`
472025-01-30T07:54:13 <_aj_> glozow: the parent txid or a pointer to an orphan tracker?
482025-01-30T07:54:31 <glozow> the parent txid
492025-01-30T07:54:38 <_aj_> glozow: (32B for every non-orphan requested seems slightly lame)
502025-01-30T07:55:11 <glozow> what do you mean?
512025-01-30T07:56:27 <_aj_> if you have tx O as an orphan, with missing parents P1 and P2, you tock P1{O} and P2{O} into m_txrequest or you stick O into m_txrequest?
522025-01-30T07:56:36 <_aj_> tock? stick
532025-01-30T07:56:50 <glozow> we put P1 and P2 in m_txrequest
542025-01-30T07:57:07 <glozow> and don't remember that they are related to O
552025-01-30T07:58:17 <glozow> https://github.com/bitcoin/bitcoin/blob/809d7e763cc9bdfff3288860a1c530460c76ffff/src/node/txdownloadman_impl.cpp#L403-L424
562025-01-30T07:59:16 <_aj_> hmm, why did the orphan tx tracker get dropped? seems much more efficient to have it, than not?
572025-01-30T08:01:29 <_aj_> (dropped from the design, i mean, not much value implementing it with the orphanage as it is currently)
582025-01-30T08:01:48 <glozow> yeah, it didn't add much value with the current orphan reso method
592025-01-30T08:02:13 <glozow> It's more helpful in the package relay world
602025-01-30T08:10:06 <_aj_> maybe make it PackageRequestTracker (where an orphaned child implies the pacakge of the child and its missing parents) and use it for making orphan handling efficient, and generalise it more as package relay progresses further? not having that and ending up with O(n^2) stuff doesn't seem surprising; that was what ~exactly the tracker was there to fix
612025-01-30T08:52:45 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
622025-01-30T09:26:46 *** szkl <szkl!uid110435@id-110435.uxbridge.irccloud.com> has joined #bitcoin-core-dev
632025-01-30T10:02:31 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 265 seconds)
642025-01-30T10:06:22 <bitcoin-git> [bitcoin] maximevtush opened pull request #31761: Update LICENSE (master...master) https://github.com/bitcoin/bitcoin/pull/31761
652025-01-30T10:07:07 <bitcoin-git> [bitcoin] fanquake closed pull request #31761: Update LICENSE (master...master) https://github.com/bitcoin/bitcoin/pull/31761
662025-01-30T11:03:23 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
672025-01-30T11:06:15 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Client Quit)
682025-01-30T11:29:46 *** MyNetAz <MyNetAz!~MyNetAz@user/MyNetAz> has quit IRC (Remote host closed the connection)
692025-01-30T11:31:02 *** MyNetAz <MyNetAz!~MyNetAz@user/MyNetAz> has joined #bitcoin-core-dev
702025-01-30T11:32:50 <instagibbs> > O(log(peers*peer_orphan_count_limit))
712025-01-30T11:32:50 <instagibbs> it's this afaict, but if peer_orphan_count_limit is large, this ends up being substantial, especially if if you have ~120 inbounds
722025-01-30T11:38:58 *** jespada <jespada!~jespada@2800:a4:2225:fa00:219b:97a5:1505:5c5f> has joined #bitcoin-core-dev
732025-01-30T11:45:23 <bitcoin-git> [bitcoin] Sjors opened pull request #31763: Pass custom DEP_OPTS and CONFIG_FLAGS to guix-build (master...2025/01/guix-config-flags) https://github.com/bitcoin/bitcoin/pull/31763
742025-01-30T12:04:25 *** eval-exec <eval-exec!~Thunderbi@23.106.134.43.16clouds.com> has joined #bitcoin-core-dev
752025-01-30T12:10:06 *** eval-exec <eval-exec!~Thunderbi@23.106.134.43.16clouds.com> has quit IRC (Quit: eval-exec)
762025-01-30T12:12:55 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
772025-01-30T12:20:49 *** eval-exec <eval-exec!~Thunderbi@23.106.134.43.16clouds.com> has joined #bitcoin-core-dev
782025-01-30T12:27:23 *** dni <dni!~dni@64.226.100.125> has joined #bitcoin-core-dev
792025-01-30T12:33:29 <bitcoin-git> [bitcoin] hebasto opened pull request #31764: cmake: Generate man pages at install time (master...250130-man-install) https://github.com/bitcoin/bitcoin/pull/31764
802025-01-30T12:38:13 *** BrandonOdiwuor <BrandonOdiwuor!~BrandonOd@105.163.157.80> has joined #bitcoin-core-dev
812025-01-30T12:48:35 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev (Closing Window)
822025-01-30T12:53:16 *** jespada <jespada!~jespada@2800:a4:2225:fa00:219b:97a5:1505:5c5f> has quit IRC (Ping timeout: 244 seconds)
832025-01-30T12:57:40 <bitcoin-git> [bitcoin] hebasto closed pull request #31764: cmake: Generate man pages at install time (master...250130-man-install) https://github.com/bitcoin/bitcoin/pull/31764
842025-01-30T12:57:58 *** jespada <jespada!~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb> has joined #bitcoin-core-dev
852025-01-30T13:14:13 <bitcoin-git> [bitcoin] hebasto opened pull request #31765: cmake: Install man pages for built targets only (master...250130-man-inst) https://github.com/bitcoin/bitcoin/pull/31765
862025-01-30T13:31:40 *** dni <dni!~dni@64.226.100.125> has quit IRC (Ping timeout: 240 seconds)
872025-01-30T13:50:02 *** ajonas <ajonas!uid385278@id-385278.helmsley.irccloud.com> has joined #bitcoin-core-dev
882025-01-30T13:59:59 *** Guest25 <Guest25!~Guest25@ppp-49-237-12-244.revip6.asianet.co.th> has joined #bitcoin-core-dev
892025-01-30T14:00:55 <bitcoin-git> [leveldb-subtree] fanquake opened pull request #47: Fix C++23 compilation errors in leveldb (bitcoin-fork...cpp_std_23) https://github.com/bitcoin-core/leveldb-subtree/pull/47
902025-01-30T14:01:33 <bitcoin-git> [bitcoin] fanquake opened pull request #31766: [WIP] leveldb: pull upstream C++23 changes (master...leveldb_cpp23) https://github.com/bitcoin/bitcoin/pull/31766
912025-01-30T14:09:14 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
922025-01-30T14:27:41 *** Guest25 <Guest25!~Guest25@ppp-49-237-12-244.revip6.asianet.co.th> has quit IRC (Quit: Client closed)
932025-01-30T14:36:53 <instagibbs> ð¦
942025-01-30T14:39:34 *** johnny9dev584508 <johnny9dev584508!~johnny9de@136.56.172.142> has quit IRC (Ping timeout: 245 seconds)
952025-01-30T14:47:13 *** johnny9dev584508 <johnny9dev584508!~johnny9de@136.56.172.142> has joined #bitcoin-core-dev
962025-01-30T14:50:33 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Quit: = "")
972025-01-30T14:51:45 *** johnny9dev584508 <johnny9dev584508!~johnny9de@136.56.172.142> has quit IRC (Client Quit)
982025-01-30T15:07:23 *** johnny9dev584508 <johnny9dev584508!~johnny9de@136.56.172.142> has joined #bitcoin-core-dev
992025-01-30T15:19:22 *** jespada <jespada!~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzzâ¦)
1002025-01-30T15:20:39 *** jespada <jespada!~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb> has joined #bitcoin-core-dev
1012025-01-30T15:22:27 *** jespada <jespada!~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb> has quit IRC (Client Quit)
1022025-01-30T15:27:41 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:6563:60d0:ec85:17b0> has joined #bitcoin-core-dev
1032025-01-30T15:31:21 *** rszarka <rszarka!~szarka@2603:3003:4eac:100:6563:60d0:ec85:17b0> has quit IRC (Ping timeout: 276 seconds)
1042025-01-30T15:33:41 *** eval-exec <eval-exec!~Thunderbi@23.106.134.43.16clouds.com> has quit IRC (Ping timeout: 248 seconds)
1052025-01-30T15:36:49 *** midnight <midnight!~midnight@user/midnight> has quit IRC (Remote host closed the connection)
1062025-01-30T15:37:09 *** midnight <midnight!~midnight@user/midnight> has joined #bitcoin-core-dev
1072025-01-30T15:38:01 *** conman <conman!~con@180-150-21-3.b49615.mel.static.aussiebb.net> has quit IRC (Read error: Connection reset by peer)
1082025-01-30T15:38:06 *** cman <cman!~con@180-150-21-3.b49615.mel.static.aussiebb.net> has joined #bitcoin-core-dev
1092025-01-30T15:40:42 *** rszarka <rszarka!~szarka@2603:3003:4eac:100:6563:60d0:ec85:17b0> has joined #bitcoin-core-dev
1102025-01-30T15:44:00 *** robszarka <robszarka!~szarka@2603:3003:4eac:100:6563:60d0:ec85:17b0> has quit IRC (Ping timeout: 260 seconds)
1112025-01-30T15:48:15 <achow101> jonatack: wanted to check that you no longer want to talk about the "release management rotation" you proposed at the end of last week's meeting
1122025-01-30T16:00:22 *** Emc99 <Emc99!~Emc99@212.129.76.76> has joined #bitcoin-core-dev
1132025-01-30T16:00:31 <glozow> hi
1142025-01-30T16:00:34 <tdb3> hi
1152025-01-30T16:00:39 <achow101> #startmeeting
1162025-01-30T16:00:39 <corebot> achow101: Meeting started at 2025-01-30T16:00+0000
1172025-01-30T16:00:40 <corebot> achow101: Current chairs: achow101
1182025-01-30T16:00:41 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
1192025-01-30T16:00:41 *** brunoerg_ <brunoerg_!~brunoerg@2804:14d:5285:84b2::1001> has quit IRC ()
1202025-01-30T16:00:42 <instagibbs> hallo
1212025-01-30T16:00:43 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
1222025-01-30T16:00:44 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
1232025-01-30T16:00:47 <achow101> #bitcoin-core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto 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
1242025-01-30T16:00:48 <jonatack> achow101: not at this time, ty
1252025-01-30T16:00:50 <jonatack> hi
1262025-01-30T16:00:50 *** brunoerg <brunoerg!~brunoerg@2804:14d:5285:84b2::1001> has joined #bitcoin-core-dev
1272025-01-30T16:00:53 <TheCharlatan> hi
1282025-01-30T16:00:57 <kevkevin> hi
1292025-01-30T16:01:02 <sr_gi[m]> Hi
1302025-01-30T16:01:03 <hebasto> hi
1312025-01-30T16:01:09 <ajonas> hi
1322025-01-30T16:01:09 <darosior> hi
1332025-01-30T16:01:10 <achow101> There are 2 preproposed topics this week. Any last minute ones to add?
1342025-01-30T16:01:13 <brunoerg> hi
1352025-01-30T16:01:16 <kevkevin> #here
1362025-01-30T16:01:18 <sipa> hi
1372025-01-30T16:01:23 <pinheadmz> yo
1382025-01-30T16:01:26 <darosior> #here \" DROP TABLE actions
1392025-01-30T16:01:28 <Sjors[m]> hi
1402025-01-30T16:01:32 <cfields> hi
1412025-01-30T16:01:37 <hodlinator> hi
1422025-01-30T16:01:40 <achow101> darosior: rude
1432025-01-30T16:01:56 <lightlike> hi
1442025-01-30T16:01:59 <achow101> #topic Erlay WG Update (sr_gi, gleb, marcofleon)
1452025-01-30T16:02:35 <fjahr> hi
1462025-01-30T16:02:48 *** abubakarsadiq <abubakarsadiq!uid602234@id-602234.hampstead.irccloud.com> has quit IRC ()
1472025-01-30T16:03:04 *** abubakarsadiq <abubakarsadiq!uid602234@id-602234.hampstead.irccloud.com> has joined #bitcoin-core-dev
1482025-01-30T16:03:07 <sr_gi[m]> Following from last weekâs meeting, I mentioned that after running a wide range experiment with different combinations of parameters for how to select fanout peers, a less static approach was proposed by @murch: instead of having a fixed fanout rate (selecting some inbounds and outbounds), we could have a variable rate based on how the peer has received the transaction
1492025-01-30T16:03:11 <abubakarsadiq> hi
1502025-01-30T16:03:13 <furszy> hi
1512025-01-30T16:04:00 <sr_gi[m]> This tries to guess how propagated the transaction is to use more fanout or more reconciliation to keep propagating it
1522025-01-30T16:05:00 <sr_gi[m]> It is something we previously tried by checking how many peers may have announced a transaction by the time we needed to pick to how many peers to fanout to, but that approach, while promising, didn't seem to work too well
1532025-01-30T16:05:21 <sr_gi[m]> Long story short, @murch suggestion yield really interesting results
1542025-01-30T16:05:56 <sr_gi[m]> Reducing the transaction propagation latency by a significant bit while not affecting the bandwidth too much
1552025-01-30T16:06:38 <sr_gi[m]> A full explanation of the approach, experiment, results and conclusions can be found here, for those interested: https://srgi.notion.site/Define-the-transaction-fanout-rate-based-on-whether-the-node-has-received-the-transaction-via-fanout-18a7b3fef9778097a922fac307125de2#18a7b3fef97780b59ebbfede420d76d7
1562025-01-30T16:08:03 <jonatack> nice
1572025-01-30T16:08:24 <sr_gi[m]> Next is to decide if modifying the poisson timers for erlay, in order to achieve better latency, is acceptable, and to what extend, or if we could find an alternative solution that may be less intrusive
1582025-01-30T16:08:39 <sr_gi[m]> That's it on my end
1592025-01-30T16:09:02 <achow101> #topic Kernel WG Update (TheCharlatan)
1602025-01-30T16:09:14 <TheCharlatan> I don't have much to share this week, but stickies-v published a python wheel https://www.piwheels.org/project/py-bitcoinkernel/ for the pip package https://pypi.org/project/py-bitcoinkernel/ for wrapping the proposed kernel API.
1612025-01-30T16:09:35 <TheCharlatan> Seems like some people already are using them for gathering transaction and block data.
1622025-01-30T16:10:01 <abubakarsadiq> nice, this is more convenient to use
1632025-01-30T16:10:24 <TheCharlatan> Other than that I am looking for review on #31382.
1642025-01-30T16:10:34 <sipa> #31382
1652025-01-30T16:10:36 <corebot> https://github.com/bitcoin/bitcoin/issues/31382 | kernel: Flush in ChainstateManager destructor by TheCharlatan · Pull Request #31382 · bitcoin/bitcoin · GitHub
1662025-01-30T16:10:49 <TheCharlatan> ty :)
1672025-01-30T16:12:11 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
1682025-01-30T16:12:44 <sdaftuar> oh hi
1692025-01-30T16:13:11 <sdaftuar> my update is that i was able to rebase my big PR on sipa's work, so #28676 can be looked at to get an idea of how sipa's code will be used
1702025-01-30T16:13:15 <corebot> https://github.com/bitcoin/bitcoin/issues/28676 | [WIP] Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
1712025-01-30T16:13:18 <Murch[m]> Hi (think I wasnât authed earlier)
1722025-01-30T16:13:38 <sdaftuar> i still need to do more cleanups on my branch, so leaving it in draft (as sipa's PRs still need review anyway)
1732025-01-30T16:13:57 <sdaftuar> that's it from me
1742025-01-30T16:14:09 <achow101> #topic Stratum v2 WG Update (sjors)
1752025-01-30T16:14:13 <instagibbs> I've been taking a peek, thanks sdaftuar
1762025-01-30T16:14:20 <glozow> thanks sdaftuar!
1772025-01-30T16:14:37 <Sjors[m]> There's a Matrix chat for the work group, that's mostly quiet
1782025-01-30T16:14:52 <Sjors[m]> But you can dm your Matrix username to be added there. Or we can try another platofmr.
1792025-01-30T16:14:56 *** BrandonOdiwuor <BrandonOdiwuor!~BrandonOd@105.163.157.80> has quit IRC (Quit: Client closed)
1802025-01-30T16:15:04 <Sjors[m]> #31756 is a good followup of last weeks discussion
1812025-01-30T16:15:05 <corebot> https://github.com/bitcoin/bitcoin/issues/31756 | RFC: multiprocess binaries in 29.0 · Issue #31756 · bitcoin/bitcoin · GitHub
1822025-01-30T16:15:45 <Sjors[m]> I'm personally not assuming we'll meet the v29 release, but it would be good to continue the discussion there so we're on the same page for e.g. v30
1832025-01-30T16:16:07 <Sjors[m]> Next on peoples review list, suggested: #31283
1842025-01-30T16:16:09 <corebot> https://github.com/bitcoin/bitcoin/issues/31283 | Add waitNext() to BlockTemplate interface by Sjors · Pull Request #31283 · bitcoin/bitcoin · GitHub
1852025-01-30T16:16:27 <Sjors[m]> That's the last bit of the interface.
1862025-01-30T16:16:46 <Sjors[m]> The interface and getting multiprocess in A release is pretty much all that's needed.
1872025-01-30T16:18:32 <achow101> #topic MuSig2 WG Update (achow101)
1882025-01-30T16:18:43 <abubakarsadiq> nice I will take a look! @sjors[m] I see you rebase your branch on #31384, can we have the 29.0 milestone on it?
1892025-01-30T16:19:02 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has joined #bitcoin-core-dev
1902025-01-30T16:19:08 <achow101> No update really, been a bit incapacitated this week. Still planning to write some psbt test vectors soon(tm)
1912025-01-30T16:19:28 <achow101> The next pr to review is #31243
1922025-01-30T16:19:30 <corebot> https://github.com/bitcoin/bitcoin/issues/31243 | descriptor: Move filling of keys from `DescriptorImpl::MakeScripts` to `PubkeyProvider::GetPubKey` by achow101 · Pull Request #31243 · bitcoin/bitcoin · GitHub
1932025-01-30T16:19:35 <Sjors[m]> abubakarsadiq: that milestone only makes sense if we still aim for v29
1942025-01-30T16:19:44 <achow101> #topic Legacy Wallet Removal WG Update (achow101)
1952025-01-30T16:20:17 <achow101> #31241 was merged. The next pr is #31495 which looks like there is some review I need to address.
1962025-01-30T16:20:20 <corebot> https://github.com/bitcoin/bitcoin/issues/31241 | wallet: remove BDB dependency from wallet migration benchmark by furszy · Pull Request #31241 · bitcoin/bitcoin · GitHub
1972025-01-30T16:20:25 <corebot> achow101: Error: That URL raised <Connection timed out.>
1982025-01-30T16:20:37 <achow101> Other than that, not much else
1992025-01-30T16:20:46 <sipa> #31495
2002025-01-30T16:20:49 <corebot> https://github.com/bitcoin/bitcoin/issues/31495 | wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases by achow101 · Pull Request #31495 · bitcoin/bitcoin · GitHub
2012025-01-30T16:21:07 <abubakarsadiq> Milestone for
2022025-01-30T16:21:09 <abubakarsadiq> #31384
2032025-01-30T16:21:14 <corebot> https://github.com/bitcoin/bitcoin/issues/31384 | mining: bugfix: Fix duplicate coinbase tx weight reservation by ismaelsadeeq · Pull Request #31384 · bitcoin/bitcoin · GitHub
2042025-01-30T16:21:24 <achow101> #topic orphan resolution WG Update (glozow)
2052025-01-30T16:21:36 <glozow> I'm working on my per-peer orphanage branch, which is maybe 80% of the way there.
2062025-01-30T16:21:46 <glozow> (80%TM)
2072025-01-30T16:22:03 <sipa> the second 80% might take less than the first 80%
2082025-01-30T16:22:19 <glozow> I'm trying to get #31666 merged soon as it's based on that. A little bit of active discussion left on the the AddChildrenToWorkset assignment, happy to punt that or defend it
2092025-01-30T16:22:21 <corebot> https://github.com/bitcoin/bitcoin/issues/31666 | multi-peer orphan resolution followups by glozow · Pull Request #31666 · bitcoin/bitcoin · GitHub
2102025-01-30T16:23:02 *** jespada <jespada!~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb> has joined #bitcoin-core-dev
2112025-01-30T16:23:28 <glozow> sipa: haha. I'm going a little bit back and forth on the count limits thing, might just end up incorporating the struct memory usage after benching it
2122025-01-30T16:23:38 <glozow> anyway I hope to have my PR up soon
2132025-01-30T16:24:11 <sipa> glozow: happy to discuss more
2142025-01-30T16:24:21 <glozow> I might actually trim things like "give outbounds more space than inbounds" to make it smaller / more realistic for v29
2152025-01-30T16:24:36 <glozow> sipa: thanks
2162025-01-30T16:24:44 <sipa> as in 400 kWU for everyone?
2172025-01-30T16:24:47 <glozow> yes
2182025-01-30T16:25:18 <sipa> do we have a way of gathering data whether or not that would affect any actual tx relay right now?
2192025-01-30T16:26:07 <instagibbs> I asked timo but he's busy this week, so if anyone has high quality node data
2202025-01-30T16:26:16 <glozow> hmmm, is the best way to analyze that to measure how many bytes peers use right now?
2212025-01-30T16:26:17 <instagibbs> (read: not randomly shutting machines off like mine)
2222025-01-30T16:26:27 <sipa> glozow: i think so
2232025-01-30T16:26:58 <glozow> my byte accounting code seems correct(TM), we could start running that now
2242025-01-30T16:27:32 <glozow> well this can also be inferred from the `getorphantxs` RPC results
2252025-01-30T16:27:34 <instagibbs> beneficial to make sure logging is decent for 29.0. whatever happens?
2262025-01-30T16:27:40 <instagibbs> I expect it to be very bursty
2272025-01-30T16:28:07 <glozow> yeah i expect it to be very high at first, and then taper off
2282025-01-30T16:28:24 <glozow> idea: orphanage can borrow some space from mempool when it's not full?
2292025-01-30T16:28:58 <glozow> (maybe we should continue this later? meeting can go on?)
2302025-01-30T16:29:05 <instagibbs> â
2312025-01-30T16:29:06 <sipa> let's discuss after
2322025-01-30T16:29:10 <achow101> #topic mutation testing (brunoerg)
2332025-01-30T16:29:27 <brunoerg> Hi, just a quick announcement that Iâm performing mutation testing and publishing the reports at bitcoincore.space. I do it based on master branch once a week (every Monday, I guess) and then I update the website with the results
2342025-01-30T16:29:35 <brunoerg> I started to do it on more important/critical part of the codebase (pow, tx_check, script interpreter, etc) but I intend to expand it soon. Any suggestions for function/code file to include next on it, let me know.
2352025-01-30T16:30:02 <brunoerg> that's it
2362025-01-30T16:30:21 <sipa> you run that website?
2372025-01-30T16:30:25 <brunoerg> yes
2382025-01-30T16:30:26 <achow101> how are you generating mutations? by hand?
2392025-01-30T16:30:40 <brunoerg> no, using my own tool
2402025-01-30T16:30:56 <brunoerg> https://github.com/brunoerg/mutation-core
2412025-01-30T16:31:06 <darosior> Nice.
2422025-01-30T16:31:08 <sipa> nice site
2432025-01-30T16:31:11 <achow101> neat
2442025-01-30T16:32:10 <achow101> #topic What should be the mid to long term goals of the project? (darosior)
2452025-01-30T16:32:22 <achow101> this sounds like a question for coredev
2462025-01-30T16:32:25 <darosior> Hi, see https://antoinep.com/posts/core_project_direction for the longer version but here is the TL;DR. With limited resources there is an upper bound on the amount of stuff the project can maintain. We can pay in either a limited project scope or a reduced overall software quality but we can't have it for free.
2472025-01-30T16:32:25 <darosior> Resources are also spread inequally. It's very hard to onboard and make meaningful impact in important areas. With key people leaving or reducing their involvement we've at best had constant resources despite an increasing number of contributors. Despite this, the scope of the project has been constantly increasing.
2482025-01-30T16:32:25 <darosior> Bitcoin Core cannot be the "everything Bitcoin app" without also diluting priorities. Not doing anything about it is making this choice by default. Finally, defining a scope is not only about pruning stuff. It can also help us shift focus toward things we would see as in-scope but not making enough progress.
2492025-01-30T16:32:25 <darosior> For the purpose of this meeting i'm interested in:
2502025-01-30T16:32:25 <darosior> 1. do people make the same observation / agree with the problem statement in the first place?
2512025-01-30T16:32:25 <darosior> 2. do people agree that defining a scope / long term vision for the project is an appropriate solution?
2522025-01-30T16:32:25 <darosior> 3. hearing about others' thoughts about this issue.
2532025-01-30T16:32:26 <darosior> Note i obviously do not expect to find a solution in a single IRC meeting. But i think it's good to kick off the discussion here, and continue it at Coredev.
2542025-01-30T16:32:43 <darosior> achow101: yes but i figured it could be helpful to start the discussion here
2552025-01-30T16:34:11 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has quit IRC (Quit: leaving)
2562025-01-30T16:35:09 <Sjors[m]> In what areas has the scope been increasing in e.g. the last 5 years though?
2572025-01-30T16:35:12 <glozow> I agree it's hard to do the topic justice in this meeting. appreciate that you're posting this here ahead of coredev
2582025-01-30T16:35:25 <Sjors[m]> There's been 0 new GUI features, IIRC only a handful of new RPC calls.
2592025-01-30T16:35:34 <sipa> i have many thoughts about this, but i'll try to organize them before coredev
2602025-01-30T16:36:15 <Sjors[m]> There's certainly a desire to increase scope in various places, but this often goes nowhere because - as you point out - we're already quite stretched.
2612025-01-30T16:36:42 *** zeropoint <zeropoint!~alex@45-28-139-114.lightspeed.sntcca.sbcglobal.net> has joined #bitcoin-core-dev
2622025-01-30T16:36:57 <achow101> have a few thoughts on this as well, will also try to organize them before coredev
2632025-01-30T16:37:18 <glozow> I disagree the scope hasn't increased - "a handful of RPCs" in the last 5 years is around 50. the security requirements certainly have increased
2642025-01-30T16:37:35 <darosior> Sjors[m]: i don't want to make this a discussion about "should we drop the GUI", although removing it from the main project could definitely be part of defining a scope.
2652025-01-30T16:37:47 <abubakarsadiq> @sjors[m] this might be an indicator that the gui is not getting much improvements
2662025-01-30T16:38:58 <TheCharlatan> darosior beyond the three questions you are asking is there further homework we could be doing to be better prepared when discussing in person?
2672025-01-30T16:39:13 <darosior> Sjors[m]: it's pretty obvious the project has been getting bigger in any metric one can think of, and you static you are not seeing that is an illustration of the issue we are facing here.
2682025-01-30T16:39:22 <darosior> s/static/stating
2692025-01-30T16:39:32 <sipa> I think RPCs are a bad metric for measuring scope creep, dilution, or lakc of focus (all of which are real problems we suffer from). The actual maintenance cost for most RPCs, on a per-RPC basis, is small; the cost is in the code subsystem behind it.
2702025-01-30T16:40:18 <glozow> Right, should we be preparing our thoughts on what we think the goals should be + to what extent we think we should/can be planning?
2712025-01-30T16:40:44 <darosior> TheCharlatan: thanks for asking, yes i think it would be nice if we all thought about "What should be the scope of the project", "What should be Bitcoin Core's mission", so we can get inputs from as many people as possible for this discussion
2722025-01-30T16:40:45 <glozow> er yes, agree number of RPCs is not that meaningful, I just had a nitpick moment
2732025-01-30T16:40:47 <jonatack> i've had concerns for some time now about the collectivist "we" approach, particularly in a project where decentralization is the fundamental value
2742025-01-30T16:40:56 <fanquake> Sjors: I have a hard time agreeing with no scope increase. If we haven't increased our scope at all, what are the hundreds of thousands of new lines of code for
2752025-01-30T16:41:27 <Sjors[m]> I'm using a fairly narrow defination of scope, things like features and functionality.
2762025-01-30T16:41:46 <achow101> perhaps the first exercise is to define "scope"
2772025-01-30T16:41:50 <Sjors[m]> But if you mean "scope" as in things people work on, then there's more, that would include refactors.
2782025-01-30T16:41:50 <darosior> jonatack: yeah i agree with that, but also individual actions have negative externalities on the project at large and we need collective actions to work against them.
2792025-01-30T16:41:58 <sipa> I also disagree that an expanding scope is *necessarily* a problem. I believe it's a natural consequence of shifting interesting in a software being developed, even if no prioritization/focus issues existed.
2802025-01-30T16:42:02 <lightlike> what would help is concrete example of stuff that has been merged in the past but wouldn't / shouldn't have been merged with a "scope".
2812025-01-30T16:42:27 <sipa> lightlike: yes, making this concrete helps for the purpose of discussion.
2822025-01-30T16:43:00 <fanquake> lightlike: I think it's less things wouldn't have been merged, and more we need to face the reality that we can't keep adding new stuff with continued brain drain/flat-if-not-declining engineering capacity
2832025-01-30T16:43:06 <darosior> jonatack: there is a balance to strike between "everyone work on their stuff and the project decays" and "some people decide what everybody else should be spending their time on"
2842025-01-30T16:43:17 <sipa> darosior: agreed
2852025-01-30T16:43:56 <darosior> achow101: yes i agree, when thinking about this i found that defining scope would be the first step to then layout a set of priorities and then take action upon those priorities
2862025-01-30T16:44:02 <fanquake> we are already shipping things that you could consider unmaintained. i.e a GUI that doesn't work out of the box on one of the platforms we support (macOS)
2872025-01-30T16:44:24 <sipa> fanquake: yes, but i think the correct thing to look at is concrete examples that cause us maintenance cost. I believe there can exist maintained, fully functional, but not being-developed, features in the codebase, which do not cause the project a high cost.
2882025-01-30T16:44:51 <sipa> While there are other examples of things that exist in a half-finished state, which interact with lots of other things, and possible detract review power from other, more impactful things.
2892025-01-30T16:45:16 <sipa> So I think it's important to keep this concrete, and not just look at the codebase and "look, more RPCs, more lines of code, bad!".
2902025-01-30T16:45:26 <darosior> lightlike: yes i can try to compile a list of things that should have seen more focus and others that should have seen less before Coredev, but this is necessarily going to be stepping on eggs
2912025-01-30T16:45:38 <fanquake> sipa: possibly, but that doesn't solve the issue that the poeple that wrote that code are dissapearing, and the new people don't understand/can't maintain it if needed
2922025-01-30T16:45:58 <sipa> fanquake: that's fair, but i don't think this applies to the vast majority of the codebase
2932025-01-30T16:46:12 <fanquake> sure, but it applies to the most important parts
2942025-01-30T16:46:30 <glozow> I think we could focus more on how we spend resources + existing efforts to increase resources. That could potentially be a more productive conversation, though there are no easy solutions
2952025-01-30T16:46:32 <sipa> so, i'd like to encourage people to come up with specific examples
2962025-01-30T16:47:11 <ajonas> Coredev or here, I think the format to have this discussion is a challenge. Venting is healthy but there have been attempts to address meta-level project improvements in the past and it's hard to get to meat of it or come to any concrete steps going forward. It'd be great if there were ideas to discuss this in something other than a 1-to-N way where most people stay silent.
2972025-01-30T16:47:12 <Sjors[m]> darosior: bring eggs :-) it's good to have examples as a starting point
2982025-01-30T16:48:18 <sipa> We should discuss this on a meta-level too of course, but there is only so much talk can accomplish. Actually talking about specific projects can help people focus on them (for review, or for discussion on deprecation/removal/moving out alike!), and ultimately that is the only thing that will change things.
2992025-01-30T16:48:29 <jonatack> darosior: when in doubt, I think the balance to strike is in favor of decentralizad, ad hoc, less process
3002025-01-30T16:48:48 <laanwj> is the gui broken on macos?
3012025-01-30T16:49:10 <darosior> jonatack: this is a bunch of undefined terms that are not helpful to take concrete actions
3022025-01-30T16:49:14 <fanquake> laanwj: yes, it is unsable for any non-technical user, due to lack of notarization/codesigning issues
3032025-01-30T16:49:27 <achow101> fanquake: there's literally a pr for that
3042025-01-30T16:49:36 <fanquake> yes, with literally 0 review
3052025-01-30T16:49:42 <darosior> achow101: that has seen no review
3062025-01-30T16:49:44 <laanwj> fanquake oh, that, i was afraid it'd be another qt issue but that seems kind of meta
3072025-01-30T16:49:52 <darosior> ie, nobody cares enough
3082025-01-30T16:49:57 <achow101> fanquake: you're one of 2 people with the macos code signing key, you're the reviewer
3092025-01-30T16:50:08 <darosior> haha
3102025-01-30T16:50:09 <fanquake> we can't claim that we need to have feature x, but at the same time nobody is reivewing the changes needed to ship feature x
3112025-01-30T16:50:28 <fanquake> achow101: I don't see how who has the signing keys is relevant here
3122025-01-30T16:50:51 <sipa> fanquake: i think it's important to distinguish between "we should have feature X", and "hey guys we talked about feature X, it seems people want it, can it be reviewed please?".
3132025-01-30T16:51:17 <darosior> Alright, i guess i've done my advertisement. Please everyone do a bit of thinking about the issue before Coredev so we all participate in this discussion and finally are able to take actions. We have been talking about this for years now.
3142025-01-30T16:51:22 <fanquake> sipa: sure. I guess here I am talking about things we already have, which are just degrading
3152025-01-30T16:51:36 <sipa> fanquake: i'd really like you to be specific :)
3162025-01-30T16:51:42 <fanquake> sipa: the macOS gui
3172025-01-30T16:51:46 <Sjors[m]> I do occasionally review those macOS signing key PRs, but they're often impossible to test without signatures.
3182025-01-30T16:51:48 <fanquake> which doesn't work
3192025-01-30T16:52:02 <Sjors[m]> IIRC I asked for those a while back, but can check again.
3202025-01-30T16:52:13 <achow101> fanquake: a code signature from a code signer makes reviewing code signing changes easier/possible
3212025-01-30T16:52:36 <sipa> ok, who here uses macOs?
3222025-01-30T16:52:38 <fanquake> achow101: sure, if someone pings me for one in that PR I can provide, as can the other signer
3232025-01-30T16:52:46 <Sjors[m]> And I use the macOS GUI all the time
3242025-01-30T16:52:52 <laanwj> the only mac is have is old and support for its version of macos was dropped so i can't help in that regard, at least not with testing
3252025-01-30T16:52:55 <sipa> achow101: what's the PR?
3262025-01-30T16:53:00 <achow101> #31407
3272025-01-30T16:53:02 <jonatack> I have a recent mac
3282025-01-30T16:53:02 <corebot> https://github.com/bitcoin/bitcoin/issues/31407 | guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries by achow101 · Pull Request #31407 · bitcoin/bitcoin · GitHub
3292025-01-30T16:53:40 <darosior> Let's not derail the discussion into specifics
3302025-01-30T16:53:53 *** greypw149508 <greypw149508!~greypw@user/greypw> has quit IRC (Remote host closed the connection)
3312025-01-30T16:54:07 <Sjors[m]> And I know people run into lack of codesigning for the daemon too, see #29749.
3322025-01-30T16:54:12 *** greypw149508 <greypw149508!~greypw@user/greypw> has joined #bitcoin-core-dev
3332025-01-30T16:54:20 <laanwj> it's just that discussion about reducing scope always goes into "drop the gui" and "drop the wallet" which happen to be the parts i find very importnat
3342025-01-30T16:54:34 <achow101> laanwj: indeed
3352025-01-30T16:55:04 <Sjors[m]> Indeed, and the wallet is also a useful reference for other projects. See e.g. recent revival of PSBTv2 review.
3362025-01-30T16:55:09 <jonatack> Regarding the specific case of the GUI, getting funding for working on it has been a non-starter for years, perhaps somewha partially related to moving out of the bitcoin core repo
3372025-01-30T16:55:17 <jonatack> laanwj: achow101: agree
3382025-01-30T16:55:26 <glozow> Ok so I think the meat here is "we seem to have lots of people, but people are not spending their energy on the right things. There are parts of the codebase that deserve significantly more/less attention than they're getting now. That can be dangerous for particularly important areas." I think we should come prepared to talk about what those specific areas are *with a specific focus on areas that require more attention, not less*. And think
3392025-01-30T16:55:26 <glozow> about why we personally don't work on certain things. Perhaps people naturally haven't learned much about an area. Obviously we have limited time. Maybe people are not incentivized/encouraged to do so (I don't just mean economically but that is part of it).
3402025-01-30T16:55:28 <darosior> jonatack: to be more concrete as to your concern which i would interpret as keeping enough "emergent process" in the project, i think this is desirable and not contradictory with defining a scope. Also, we can only take collective action about the scope of the project if there is rough consensus about said scope. If there is not, i don't think it
3412025-01-30T16:55:28 <darosior> will be possible to take action. I also think it would be a pretty bad outcome for the project.
3422025-01-30T16:55:54 <laanwj> re the gui, one reason for me losing the joy of working on it were these kind of discussions, it's always on the chopping block
3432025-01-30T16:56:36 <laanwj> has been since 2012 or so
3442025-01-30T16:57:09 <Sjors[m]> laanwj: it also just really hard to work with qt5. I'm hoping either QML + QT6 or multiprocess and external GUI will get things moving again eventually.
3452025-01-30T16:57:21 *** PaperSword1 <PaperSword1!~Thunderbi@securemail.qrsnap.io> has joined #bitcoin-core-dev
3462025-01-30T16:57:56 <hebasto> further gui development requires expanding dependencies. itâs another concern
3472025-01-30T16:58:08 <laanwj> in any case, i agree with keeping limit on scope creep in general, that's also what i've always tried, not every random RPC or GUI feature anyone asks for needs to be added, but i don't think that's the case either
3482025-01-30T16:58:30 *** PaperSword <PaperSword!~Thunderbi@ec2-3-129-110-246.us-east-2.compute.amazonaws.com> has quit IRC (Ping timeout: 252 seconds)
3492025-01-30T16:58:30 *** PaperSword1 is now known as PaperSword
3502025-01-30T16:58:56 <sipa> laanwj: agreed, it's not like we willy nilly take on extra features; "seems too tangential, can be done elsewhere" has long been a reason not to take things
3512025-01-30T16:58:58 <darosior> Alright, thanks everyone for chiming in. I'll try and compile more thoughts and data/examples about this issue.
3522025-01-30T16:59:00 <laanwj> hebasto: yeah, i tried limiting the build-time dependencies with my qtsowrap work last year, but there was almost no attention for it
3532025-01-30T16:59:06 <sipa> laanwj: :(
3542025-01-30T16:59:24 <sipa> i really liked that idea, but i also don't use the GUI
3552025-01-30T16:59:25 <lightlike> glozow: there is no real guidance for newer contributors as to which areas of the codebase would need more attention. maybe a good thing would be if some experienced contributors would just publish a list of areas that they think could need more attention.
3562025-01-30T16:59:55 <jonatack> laanwj: I empathize
3572025-01-30T17:00:04 <laanwj> well it has to be updated for qt6 anyhow, that should go first
3582025-01-30T17:00:08 <sipa> laanwj: another idea i've seen more recently is the possibility with multiprocess of having a few-dependency (maybe statically built) core, and having a gui binary connect to it with more dependencies
3592025-01-30T17:00:21 <laanwj> but if we yet again go "oh maybe we should drop the gui" i find it hard to invest time in it
3602025-01-30T17:00:40 <laanwj> sipa: that would make sense
3612025-01-30T17:00:46 <jonatack> lightlike: yes. in general, I like the idea of contributors expressing these things in personal blog posts (rather than, say, in core dev documentation or processes)
3622025-01-30T17:00:48 <sipa> so that everyone still uses the same release core binary, focusing testing/review, but if you want to use the gui, you take on the (inevitable) cost of having more dependencies too
3632025-01-30T17:01:06 *** szkl <szkl!uid110435@id-110435.uxbridge.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
3642025-01-30T17:01:08 <fanquake> statically built core is certainly already possible, it's just somewhat of a mess to integrate without somewhat overhauling how we build releases, as we'll likely need to split into separete non-gui and gui builds
3652025-01-30T17:01:17 <achow101> I believe we're getting a bit off topic and into the weeds, so I'll end the meeting here. Feel free to continue discussing.
3662025-01-30T17:01:21 <achow101> #endmeeting
3672025-01-30T17:01:21 <corebot> achow101: Meeting ended at 2025-01-30T17:01+0000
3682025-01-30T17:01:22 <corebot> achow101: Raw log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-01-30_16_00.log.json
3692025-01-30T17:01:23 <corebot> achow101: Formatted log: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-01-30_16_00.log.html
3702025-01-30T17:01:24 <corebot> achow101: Minutes: https://achow101.com/ircmeetings/2025/bitcoin-core-dev.2025-01-30_16_00.html
3712025-01-30T17:01:36 <fanquake> (to get have less complication / get the benefits of not having to boostrap all the qt deps in the build where they aren't needed)
3722025-01-30T17:02:03 <achow101> fanquake: #31407 changes the workflow for macos code signers. I think it's completely reasonable, and in fact required, for at least one of, if not both of, the macos code signers to review and test it
3732025-01-30T17:02:05 <corebot> https://github.com/bitcoin/bitcoin/issues/31407 | guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries by achow101 · Pull Request #31407 · bitcoin/bitcoin · GitHub
3742025-01-30T17:02:24 <achow101> not to mention that it also requires additional credentials to be gotten from apple, which afaik, you're the only one who can do that.
3752025-01-30T17:02:26 <fanquake> sipa: it's not even the cost of more deps, it's stuff like, us upgrading our fuzzing/test infra a new LLVM is blocked because some qt (or dep) doesn't compile
3762025-01-30T17:03:07 <darosior> Yes there is risks to users, but the costs are mostly for maintenance and future work
3772025-01-30T17:03:29 <sipa> fanquake: by "cost of deps" i mostly meant as a user, you get the cost of increased security surface
3782025-01-30T17:03:38 <fanquake> the cost of features just get externalized to people working on other parts of the code
3792025-01-30T17:03:42 <Sjors[m]> Is there an index for https://bitcoincore.org/depends-sources ?
3802025-01-30T17:03:44 <glozow> lightlike: I agree! And I was intimidated by certain projects/areas after learning about them, maybe others have a similar experience but idk. Perhaps we can do more to help people move out of their comfort zones
3812025-01-30T17:04:06 <sipa> fanquake: of course for maintenance dependencies have a cost too, but that's inherent to having a GUI in the first place
3822025-01-30T17:04:29 <bitcoin-git> [bitcoin] danielabrozzoni opened pull request #31767: rpc: Ensure -debug=0/none behaves consistently with -nodebug (master...debug_flag_consistency) https://github.com/bitcoin/bitcoin/pull/31767
3832025-01-30T17:05:04 <darosior> Multiprocess will also make it possible to have different software that live in completely separate repositories. This would make it possible for people interested in working on one process to make progress, and possibly even iterate faster, without imposing cost on contributors interested in the node process.
3842025-01-30T17:05:20 <fanquake> sipa: sure, but also not GUI specific, which is why we've generally pushed back on deps
3852025-01-30T17:05:26 <sipa> fanquake: absolutely
3862025-01-30T17:05:31 <glozow> great, so why isn't everybody working on multiprocess?
3872025-01-30T17:05:38 <darosior> glozow: yes
3882025-01-30T17:05:59 <darosior> Exactly this. Defining long term goals would help.
3892025-01-30T17:06:04 <sipa> glozow: probably because... everybody sees it's not moving fast, so it's unclear to individual contributors how much their personal decision to contribute will have impact
3902025-01-30T17:06:16 <achow101> Sjors[m]: I don't think so, and setting one up would be non-trivial at this time.
3912025-01-30T17:06:21 <sipa> yay for self-fullfilling prophecies
3922025-01-30T17:06:52 <Sjors[m]> achow101: ok, I'm trying to see if capnp is there, but I'm not sure what the URI would be. I'll try some guesses.
3932025-01-30T17:07:11 <fanquake> glozow: probably the same reason most contributors were not working on the high priority for review items
3942025-01-30T17:08:12 <glozow> I think before we tackle "why aren't other people working on the important things" we should fully grok "why haven't I been working on the things I claimed were important to me"
3952025-01-30T17:08:34 <fanquake> or other deemed-high-priority-for-the-project project
3962025-01-30T17:09:19 <sipa> jonatack: re decentralization, i think it's important to distinguish between coordination and control. I fully believe that nobody gets to decide what anyone works on. If someone has their own pet peeve project that they want to keep working on, and aren't interested in working on anything else, that's their right. But if nobody else is interested in reviewing/helping with it, that person should
3972025-01-30T17:09:25 <sipa> also accept it might not go anywhere. Coordination is about...
3982025-01-30T17:09:27 <sipa> trying - for people who want - to find common grounds for things that might have sufficient critical mass to make progress, so time can be spent on those.
3992025-01-30T17:10:21 <darosior> sipa: It's not because something is being worked on and gets reviewed that it needs to live in Bitcoin Core.
4002025-01-30T17:10:46 <sipa> darosior: that is true too, but that's part of the review process
4012025-01-30T17:11:13 <darosior> sipa: there is a conflict about "right" here. It's as much the right of other contributors (especially maintainers) to not bear the cost of more stuff being added, as the right of people to work on what they want.
4022025-01-30T17:11:32 <fanquake> That is also hard though, because it's unclear for reviewers (especially new ones) how to decide what should/shouldn't live in Core, without any real guidance.
4032025-01-30T17:11:43 <sipa> darosior: i think that's a matter of speaking up
4042025-01-30T17:11:52 <sipa> (which, we definitely don't do enough)
4052025-01-30T17:12:12 <fanquake> (also because it's easier to ignore things than actually NACK)
4062025-01-30T17:12:17 <sipa> fanquake: indeed
4072025-01-30T17:12:19 <darosior> Not everyone affected by the costs of adding more stuff get to say it in the review process. Plus the cost is dispersed among everyone, current and future contributors, whereas the benefits of "getting my stuff merged in Bitcoin Core" are concentrated.
4082025-01-30T17:12:20 <sipa> but a review comment of the form "this unduly increases the maintenance burden for the project" is fully valid
4092025-01-30T17:12:52 *** Emc99 <Emc99!~Emc99@212.129.76.76> has quit IRC (Quit: Client closed)
4102025-01-30T17:13:07 <darosior> sipa: yes but it's often too small to warrant blocking something individually, but it adds up
4112025-01-30T17:14:06 * darosior lunch
4122025-01-30T17:14:32 * sipa lunch
4132025-01-30T17:27:55 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 244 seconds)
4142025-01-30T17:28:46 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
4152025-01-30T17:34:46 <instagibbs> 99.94% of txns seen in my orphanage are <=4kWU, 99.99% by 16kWU, 100% by 40kWU
4162025-01-30T17:39:59 <jonatack> sipa: yes, I think for coordination when in doubt prefer ad hoc, informal, opt-in, organic, bottom up, lighter, less
4172025-01-30T17:40:12 <instagibbs> (well, maybe 5 9's, not 100%)
4182025-01-30T17:56:20 *** andytoshi <andytoshi!~apoelstra@user/andytoshi> has quit IRC (Ping timeout: 244 seconds)
4192025-01-30T17:56:23 <lightlike> instagibbs: are you running with #31666, and if so, do you see whether your orphanage is smaller on average compared to before, due to more orphans being resolved quickly?
4202025-01-30T17:58:24 <instagibbs> don't have those stats handy, my first pass was to look at the average case tx size, so if we go to per peer limits, in practice the storage capacity will go way up
4212025-01-30T18:02:55 <lightlike> i see. i did getorphantxs before updating to #31666 (it was pretty well populated, at least 50 entries) and after (empty / almost empty) but it's just anecdotal (not enough datapoints).
4222025-01-30T18:02:56 <Murch[m]> Could someone please ban https://github.com/Aldocapurro from the org? The account has been spamming empty reviews for a few days
4232025-01-30T18:02:58 <corebot> https://github.com/bitcoin/bitcoin/issues/31666 | multi-peer orphan resolution followups by glozow · Pull Request #31666 · bitcoin/bitcoin · GitHub
4242025-01-30T18:03:16 *** andytoshi <andytoshi!~apoelstra@user/andytoshi> has joined #bitcoin-core-dev
4252025-01-30T18:05:21 <instagibbs> lightlike yeah I think scraping logs and doing some comparisons there would make sense?
4262025-01-30T18:07:01 <lightlike> or just calling getorphantxs and getting the count every 10 minutes, both pre- and after #31666.
4272025-01-30T18:07:15 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
4282025-01-30T18:07:45 <instagibbs> you could poll more often and count how many are "stuck" based on their age and reasonable lifespan
4292025-01-30T18:10:11 <instagibbs> ~2.5% of my node's total orphan bytes came from txns >4kWU, to normalize the statistic a bit
4302025-01-30T18:19:03 <achow101> Murch[m]: they've been blocked
4312025-01-30T18:19:19 <Murch[m]> achow101: Thanks
4322025-01-30T18:22:13 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Remote host closed the connection)
4332025-01-30T18:32:06 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has joined #bitcoin-core-dev
4342025-01-30T18:36:24 *** kevkevin <kevkevin!~kevkevin@209.242.39.30> has quit IRC (Ping timeout: 252 seconds)
4352025-01-30T18:43:47 *** jespada <jespada!~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb> has quit IRC (Quit: My Mac has gone to sleep. ZZZzzzâ¦)
4362025-01-30T18:45:08 *** jespada <jespada!~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb> has joined #bitcoin-core-dev
4372025-01-30T18:55:49 <glozow> instagibbs: thanks for checking, now wondering if these pesky inbounds even deserve 400kwu
4382025-01-30T18:58:05 <instagibbs> being the same amount is simpler...
4392025-01-30T18:58:10 <glozow> true
4402025-01-30T18:58:43 <glozow> also, I guess more accurate would be to look at the orphans that actually become useful. theoretically there could be a lot of small ones because somebody is already doing the "lots of tiny orphans" attack
4412025-01-30T18:59:14 <instagibbs> yeah my data didnt actually filter for resolved orphans, which would be more interesting
4422025-01-30T18:59:27 <glozow> not to knock the very helpful data
4432025-01-30T19:01:10 <bitcoin-git> [bitcoin] brunoerg opened pull request #31768: test: check `scanning` field from `getwalletinfo` (master...2025-01-test-wallet-scan) https://github.com/bitcoin/bitcoin/pull/31768
4442025-01-30T19:07:56 <instagibbs> though if we're regularly under attack by small orphan tx griefers, we already are hosed :)
4452025-01-30T19:10:42 *** PaperSword <PaperSword!~Thunderbi@securemail.qrsnap.io> has quit IRC (Ping timeout: 248 seconds)
4462025-01-30T19:10:46 *** PaperSword1 <PaperSword1!~Thunderbi@ec2-3-129-110-246.us-east-2.compute.amazonaws.com> has joined #bitcoin-core-dev
4472025-01-30T19:13:05 *** PaperSword1 is now known as PaperSword
4482025-01-30T19:16:28 *** MyNetAz <MyNetAz!~MyNetAz@user/MyNetAz> has quit IRC (Remote host closed the connection)
4492025-01-30T19:17:44 *** MyNetAz <MyNetAz!~MyNetAz@user/MyNetAz> has joined #bitcoin-core-dev
4502025-01-30T19:30:42 *** Guest26 <Guest26!~Guest26@2a09:bac5:7cab:1cd2::2df:c4> has joined #bitcoin-core-dev
4512025-01-30T19:35:35 *** Guest26 <Guest26!~Guest26@2a09:bac5:7cab:1cd2::2df:c4> has quit IRC (Client Quit)
4522025-01-30T19:48:01 *** kevkevin <kevkevin!~kevkevin@23-127-18-192.lightspeed.cicril.sbcglobal.net> has joined #bitcoin-core-dev
4532025-01-30T20:03:18 *** PaperSword1 <PaperSword1!~Thunderbi@securemail.qrsnap.io> has joined #bitcoin-core-dev
4542025-01-30T20:05:09 *** PaperSword <PaperSword!~Thunderbi@ec2-3-129-110-246.us-east-2.compute.amazonaws.com> has quit IRC (Ping timeout: 260 seconds)
4552025-01-30T20:05:09 *** PaperSword1 is now known as PaperSword
4562025-01-30T20:26:04 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
4572025-01-30T20:34:46 *** dviola <dviola!~diego@user/dviola> has joined #bitcoin-core-dev
4582025-01-30T20:40:16 *** kevkevin <kevkevin!~kevkevin@23-127-18-192.lightspeed.cicril.sbcglobal.net> has quit IRC (Remote host closed the connection)
4592025-01-30T21:34:39 *** jespada <jespada!~jespada@2800:a4:220c:6700:19eb:694f:b602:3bcb> has quit IRC (Ping timeout: 246 seconds)
4602025-01-30T21:50:03 *** abubakarsadiq <abubakarsadiq!uid602234@id-602234.hampstead.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
4612025-01-30T21:59:23 *** bugs_ <bugs_!~bugs@user/bugs/x-5128603> has quit IRC (Quit: Leaving)
4622025-01-30T21:59:43 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 272 seconds)
4632025-01-30T22:01:24 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
4642025-01-30T22:24:34 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Read error: Connection reset by peer)
4652025-01-30T22:25:58 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
4662025-01-30T23:17:24 *** tstearns <tstearns!~tstearns@partridge.tstearns.net> has quit IRC (Ping timeout: 276 seconds)
4672025-01-30T23:18:44 *** vasild <vasild!~vd@user/vasild> has quit IRC (Remote host closed the connection)
4682025-01-30T23:18:54 *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev