--- Log opened Thu Sep 18 00:00:43 2025
00:00 -!- vincenzopalazzo [~vincenzop@static.14.246.108.65.clients.your-server.de] has joined #bitcoin-core-dev
00:16 -!- f321x [~f321x@user/f321x] has joined #bitcoin-core-dev
00:23 -!- saturday7 [~saturday7@206.83.123.110] has quit [Quit: ZNC 1.10.1 - https://znc.in]
00:28 -!- f321x [~f321x@user/f321x] has quit [Quit: f321x]
00:28 -!- f321x [~f321x@user/f321x] has joined #bitcoin-core-dev
00:28 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
00:29 -!- f321x [~f321x@user/f321x] has quit [Client Quit]
00:30 -!- f321x [~f321x@user/f321x] has joined #bitcoin-core-dev
00:39 -!- saturday7 [~saturday7@206.83.123.110] has quit [Ping timeout: 244 seconds]
00:40 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
00:43 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
00:45 -!- janb84 [~janb84@user/janb84] has quit [Ping timeout: 248 seconds]
00:47 -!- janb84 [~janb84@user/janb84] has joined #bitcoin-core-dev
01:13 -!- Guyver2_ [Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
01:14 -!- rszarka [~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809] has joined #bitcoin-core-dev
01:16 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has quit [Ping timeout: 256 seconds]
01:16 -!- thelounge496669 [~thelounge@149.106.235.56] has quit [Read error: Connection reset by peer]
01:17 -!- robszarka [~szarka@2603:3003:4eac:100:a908:7546:dcc7:a00b] has quit [Ping timeout: 260 seconds]
01:23 -!- saturday7 [~saturday7@206.83.123.110] has quit [Quit: ZNC 1.10.1 - https://znc.in]
01:27 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
01:29 -!- saturday7 [~saturday7@206.83.123.110] has quit [Client Quit]
01:32 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
01:43 -!- Guyver2_ [Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev []
01:49 -!- saturday7 [~saturday7@206.83.123.110] has quit [Quit: ZNC 1.10.1 - https://znc.in]
01:50 -!- Cory51 [~Cory47@user/pasha] has quit [Quit: Client closed]
01:51 -!- Cory51 [~Cory51@user/pasha] has joined #bitcoin-core-dev
01:54 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
01:58 -!- saturday7 [~saturday7@206.83.123.110] has quit [Client Quit]
02:05 -!- vincenzopalazzo [~vincenzop@static.14.246.108.65.clients.your-server.de] has quit [Read error: Connection reset by peer]
02:12 -!- saturday7 [~saturday7@206.83.123.110] has joined #bitcoin-core-dev
02:20 -!- sdfgsdfg3d [~sdfgsdfg3@2001:4479:5b06:3700:cd4d:e98e:c2c8:4fd1] has joined #bitcoin-core-dev
02:53 -!- f321x [~f321x@user/f321x] has quit [Quit: f321x]
03:22 -!- f321x [~f321x@user/f321x] has joined #bitcoin-core-dev
03:25 -!- sdfgsdfg3d [~sdfgsdfg3@2001:4479:5b06:3700:cd4d:e98e:c2c8:4fd1] has quit [Quit: Client closed]
04:07 < 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
04:08 < sipa> if we think that's too much, maybe it's just the 1000 constant that should be reduced?
04:09 -!- Christoph_ [~Christoph@68.250.227.98] has joined #bitcoin-core-dev
04:12 -!- Christoph_ [~Christoph@68.250.227.98] has quit [Client Quit]
04:14 < sipa> any reason not to do (BASE + to_send.size() / 200) ? 
04:48 -!- f321x [~f321x@user/f321x] has quit [Remote host closed the connection]
04:49 -!- f321x [~f321x@user/f321x] has joined #bitcoin-core-dev
04:56 -!- robszarka [~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809] has joined #bitcoin-core-dev
04:59 -!- rszarka [~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809] has quit [Ping timeout: 256 seconds]
05:14 -!- robszarka [~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809] has quit [Quit: Leaving]
05:14 -!- szarka [~szarka@2603:3003:4eac:100:34cc:b5a6:e5f2:f809] has joined #bitcoin-core-dev
05:15 -!- Cory51 [~Cory51@user/pasha] has quit [Quit: Client closed]
05:15 -!- Cory51 [~Cory51@user/pasha] has joined #bitcoin-core-dev
05:19 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
05:25 < hebasto> #proposedmeetingtopic Support for Ubuntu 22.04 LTS as a build platform
05:39 < _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 
05:39 < _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.
05:39 < corebot> https://github.com/bitcoin/bitcoin/issues/27630 | p2p: Increase tx relay rate by sdaftuar · Pull Request #27630 · bitcoin/bitcoin · GitHub
05:40 < _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
05:50 < sipa> _aj_: yeah, i don't object to raising it 2x, but want to reason through it a bit more
05:55 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has joined #bitcoin-core-dev
05:57 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has joined #bitcoin-core-dev
06:04 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has quit [Quit: Client closed]
06:08 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
06:14 -!- Guest73 [~Guest73@143.105.151.212] has joined #bitcoin-core-dev
06:18 -!- Guest73 [~Guest73@143.105.151.212] has quit [Client Quit]
06:29 < darosior> Relevant to this discussion: https://mainnet.observer/charts/transactions-per-day/
06:30 < 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.
06:40 < darosior> 200k transactions a day is 2.3 tx/s. Why was the value chosen to be thrice as much?
06:41 < 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
06:41 < sipa> so you want some overshoot to account for temporary variations around the average
06:42 < 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
06:42 < 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.
06:45 < 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
06:46 < sipa> darosior: in the steady state, the size of the queue will be ~200x the number of transactions you receive between any two sends
06:47 < sipa> for sufficiently large inbound tx rate
06:47 < 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?
06:48 < 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.
06:48 < sipa> per peer you're limited by the roundtrip time of an INV-GETDATA-TX cycle, times the number of transactions permitted in txrequest
06:49 < 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
06:52 < darosior> sipa: sorry could you expand on the ~200x figure? Not sure to follow.
06:53 < sipa> darosior: the formula for how much to send, approximated, is (invs_to_send.size() / 200)
06:53 < sipa> in the steady state, the amount of tx you send equals how many transactions get added to the queue in between two sends
06:54 < 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
06:54 < sipa> which is when invs_to_send.size() == 200 * 300 = 60000
06:55 < 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.
06:56 < sipa> darosior: well the steady state is what you end up
06:57 < sipa> the queue will grow until it hits that point
06:59 -!- Christoph_ [~Christoph@68.250.227.98] has joined #bitcoin-core-dev
07:04 -!- Christoph_ [~Christoph@68.250.227.98] has quit [Client Quit]
07:06  * darosior clarified with sipa IRL, he was talking about instagibbs' question i was talking about _aj_'s proposal to increase the default rate
07:07 -!- jespada [~jespada@2800:a4:2204:1500:d939:f1ea:9009:f60] has joined #bitcoin-core-dev
07:07 < 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
07:08 < sipa> if not, i'd suggest something simpler like always send the top 20-40% (randomly selected) of the queue?
07:09 < sipa> darosior points out that that may mean never actually sending the bottom part
07:09 < instagibbs> darosior ok them I'm confused now
07:10 < instagibbs> just throwing an idea out there, I've not thought hard about it
07:10 < 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
07:10 < instagibbs> sipa 👍
07:10 < sipa> so they can be unbounded, but only if the incoming transaction rate is unbounded, and txgraph prevents that
07:11 < sipa> eh, txrequest
07:11 < sipa> but the rate can be pretty high
07:11 < darosior> txgraph txrequest txdownload
07:11 < instagibbs> I think it only seems problematic if nodes arent sending invs to you and direct sending
07:11 < darosior> tx* is the new *man
07:12 < sipa> needs more "mini"
07:13 < sipa> minitxman
07:14 < darosior> if we call it mini it cannot grow unbounded
07:15 < sipa> right
07:16 -!- Christoph_ [~Christoph@68.250.227.98] has joined #bitcoin-core-dev
07:17 -!- Cory51 [~Cory51@user/pasha] has quit [Quit: Client closed]
07:17 -!- jespada [~jespada@2800:a4:2204:1500:d939:f1ea:9009:f60] has quit [Ping timeout: 244 seconds]
07:17 -!- Cory51 [~Cory51@user/pasha] has joined #bitcoin-core-dev
07:26 < 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
07:26 < 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?
07:26 < darosior> s/the highest we've been/the highest we've seen/
07:31 -!- Christoph_ [~Christoph@68.250.227.98] has quit [Quit: Christoph_]
07:34 < 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)
07:34 < sipa> plus X% of the highest-feerate stuff in the queue that isn't timed out yet
07:37 < instagibbs> dont have to sort timed out stuff either 
07:37 < instagibbs> iiuc
07:38 < sipa> we may still want to, to guarantee topology
07:38 < sipa> and probably better for privacy anyway
07:38 < instagibbs> ah right
07:38 < instagibbs> doing stuff before sorting can help if you're *dropping* it for various reasons
07:40 < 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
07:44 -!- Cory51 [~Cory51@user/pasha] has quit [Quit: Client closed]
07:45 -!- Cory51 [~Cory51@user/pasha] has joined #bitcoin-core-dev
07:48 < _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
07:49 < instagibbs> clearly not optimal, only better than crashing
07:52 < _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
07:52 < sipa> right
07:52 < sipa> the primary privacy benefit the queueing/batching has is hiding the relative order of transactions
07:54 < _aj_> darosior: "mini-inf, another name for aleph0 or the cardinality of the integers, ..."
07:57 < _aj_> darosior: 2024-04-23 on that graph claims 927010 txs per day, which is 10.7/second
07:57 < 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
07:58 < 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
07:59 < sipa> but in addition, from a personal DoS protection perspective, we need to limit the size of the queue
08:00 -!- dzxzg [~qualify@user/dzxzg] has joined #bitcoin-core-dev
08:01 < sipa> what about: send_now = std::min(to_send.size(), time_since_last_send * R + (to_send.size() ** 2) / M)
08:01 < sipa> where R is the "everyone can handle this tx rate" number, and M is the maximum queue size
08:03 < 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
08:04 < _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 
08:04 < _aj_> when the mempool empties out (which could just be "the sending wallet resubmits")
08:05 < 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
08:07 < _aj_> sure, bip153/sendtemplate's my answer to that :)
08:07 < _aj_> anyone remember how many txs were in the mempool back when we had huge backlogs?
08:09 < _aj_> hmm, i have significantly fewer txs in my mempool than mempool.space reports (87k vs 130k?)
08:11 < sipa> is there an RPC to get node uptime?
08:12 < sipa> ah, `uptime` ~!
08:12 < fanquake> uptime
08:12 < sipa> that was way too obvious
08:12 < sipa> why isn't it getnodeuptimeinfo ?
08:13 < 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)
08:13 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has joined #bitcoin-core-dev
08:14 < sipa> eh
08:14 < sipa> 100 sat/kvB or 0.1 sat/vB
08:17 < fanquake> sipa: how long running?
08:17 < sipa> 33 days
08:18 < _aj_> #10400 ; could have gone into `getinfo`, but that was already being deprecated
08:18 < 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
08:23 -!- dzxzg [~qualify@user/dzxzg] has quit [Quit: Konversation terminated!]
08:23 -!- dzxzg [~qualify@user/dzxzg] has joined #bitcoin-core-dev
08:23 -!- purpleKarrot [~purpleKar@user/purpleKarrot] has quit [Quit: purpleKarrot]
08:24 -!- jadi [~jadi@d75-157-6-90.bchsia.telus.net] has quit [Ping timeout: 256 seconds]
08:25 < _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, 
08:25 < _aj_> without using up extra memory or compute
08:32 < sipa> the mempool relayed_at index would use memory?
08:32 < _aj_> whether or not peers lag wouldn't change how much memory was used, i mean
08:33 < _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
08:35 -!- purpleKarrot [~purpleKar@185.240.173.188] has joined #bitcoin-core-dev
08:36 < _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
08:37 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
08:38 < _aj_> (ie, rebroadcasting via existing methods that currently work such as the wallet or sendrawtransaction)
08:39 -!- Cory44 [~Cory51@user/pasha] has joined #bitcoin-core-dev
08:40 -!- dzxzg [~qualify@user/dzxzg] has quit [Quit: Konversation terminated!]
08:42 -!- alvroble [~alvroble@user/alvroble] has joined #bitcoin-core-dev
08:42 -!- Cory51 [~Cory51@user/pasha] has quit [Quit: Client closed]
08:43 -!- f321x [~f321x@user/f321x] has quit [Quit: f321x]
08:48 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has joined #bitcoin-core-dev
08:48 -!- BGL [ninety@75.149.171.58] has quit [Ping timeout: 260 seconds]
08:49 -!- enochazariah [~enochazar@2c0f:f5c0:56e:19c3:8bd4:6340:ed29:c498] has joined #bitcoin-core-dev
08:49 -!- jeremyrubin [~jeremyrub@ec2-44-199-24-18.compute-1.amazonaws.com] has joined #bitcoin-core-dev
08:49 < QUBIT_ABHAY> hi
08:49 -!- dzxzg [~qualify@user/dzxzg] has joined #bitcoin-core-dev
08:49 -!- enochazariah70 [~enochazar@2c0f:2a80:ed:5010:f66:3de6:494d:87fc] has joined #bitcoin-core-dev
08:51 -!- enochazariah70 [~enochazar@2c0f:2a80:ed:5010:f66:3de6:494d:87fc] has quit [Client Quit]
08:52 -!- enochazariah89 [~enochazar@2c0f:2a80:ed:5010:f66:3de6:494d:87fc] has joined #bitcoin-core-dev
08:53 -!- enochazariah24 [~enochazar@2c0f:2a80:ed:5010:173e:165c:d0f:7cb6] has joined #bitcoin-core-dev
08:53 -!- enochazariah24 [~enochazar@2c0f:2a80:ed:5010:173e:165c:d0f:7cb6] has quit [Client Quit]
08:53 -!- enochazariah [~enochazar@2c0f:f5c0:56e:19c3:8bd4:6340:ed29:c498] has quit [Ping timeout: 250 seconds]
08:54 -!- enochazariah [uid710351@id-710351.hampstead.irccloud.com] has joined #bitcoin-core-dev
08:56 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has quit [Quit: Client closed]
08:56 -!- eugenesiegel [~eugenesie@user/eugenesiegel] has joined #bitcoin-core-dev
08:56 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has joined #bitcoin-core-dev
08:56 -!- enochazariah89 [~enochazar@2c0f:2a80:ed:5010:f66:3de6:494d:87fc] has quit [Ping timeout: 250 seconds]
08:57 -!- Cory90 [~Cory44@user/pasha] has joined #bitcoin-core-dev
08:59 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
08:59 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has quit [Client Quit]
09:00 -!- Cory44 [~Cory51@user/pasha] has quit [Ping timeout: 250 seconds]
09:00 < achow101> #startmeeting
09:00 < corebot> achow101: Meeting started at 2025-09-18T16:00+0000
09:00 < corebot> achow101: Current chairs: achow101
09:00 < corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
09:00 < corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
09:00 < corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
09:00 < Sjors[m]1> hi
09:00 < darosior> hi
09:00 < janb84> hi
09:00 < hebasto> hi
09:00 < dzxzg> hi hi
09:00 < sipa> hi
09:00 < 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
09:00 < instagibbs> hi
09:00 < hodlinator> hi
09:01 < QUBIT_ABHAY> hi
09:01 < pinheadmz> 🪇
09:01 < TheCharlatan> hi
09:01 < abubakarsadiq> hi
09:01 < alvroble> hi
09:01 < Murch[m]> hi
09:01 < achow101> There is 1 preproposed meeting topic this week, any last minute ones to add?
09:01 < brunoerg_> hi
09:01 < QUBIT_ABHAY> #here
09:01 < lightlike> hi
09:01 < laanwj> hi
09:02 < achow101> #topic Kernel WG Update (TheCharlatan)
09:02 < kanzure> hi
09:03 < TheCharlatan> not much to share this week besides wanting to ask for review on the API PR #30595
09:03 < corebot> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce initial C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
09:03 -!- l0rinc [~l0rinc@user/l0rinc] has joined #bitcoin-core-dev
09:03 < eugenesiegel> hi
09:03 < l0rinc> hi
09:03 < 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. 
09:04 < TheCharlatan> that's all
09:04 < achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
09:05 < sipa> main PR to review remains sdaftuar's #28676
09:05 < corebot> https://github.com/bitcoin/bitcoin/issues/28676 | Cluster mempool implementation by sdaftuar · Pull Request #28676 · bitcoin/bitcoin · GitHub
09:05 < sipa> which has been rebased and is getting reviews addressed
09:06 < 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)
09:06 < corebot> https://github.com/bitcoin/bitcoin/issues/33157 | cluster mempool: control/optimize TxGraph memory usage by sipa · Pull Request #33157 · bitcoin/bitcoin · GitHub
09:06 -!- QUBIT_ABHAY [~QUBIT_ABH@user/QUBIT-ABHAY:31682] has quit [Quit: Client closed]
09:06 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
09:07 < sipa> we've been talking with glozow and sdaftuar about package RBF, for after cluster mempool
09:07 -!- Christoph_ [~Christoph@108-236-117-225.lightspeed.sntcca.sbcglobal.net] has quit [Client Quit]
09:07 < jonatack> hi
09:07 < sipa> that's it from me, i think
09:07 < instagibbs> sipa I wouldnt mind being included
09:08 < sipa> #include "instagibbs.h"
09:08 < corebot> sipa: Unknown command: #include
09:08 < glozow> from gibbs import insta
09:08 < achow101> #topic Stratum v2 WG Update (sjors)
09:08 < Sjors[m]1> Review welcome on #33374. Would be nice to get in v30, but no need to delay the release for it. 
09:08 < Sjors[m]1> There's also a bunch of fixes that have been backported, not sure when we want to cut rc2?
09:08 < Sjors[m]1> ryanofsky anything you need? Just a subtree update or more?
09:08 < corebot> https://github.com/bitcoin/bitcoin/issues/33374 | mining: add applySolution() to interface by Sjors · Pull Request #33374 · bitcoin/bitcoin · GitHub
09:09 < fanquake> sjors: how are you planning to handle version in the multiprocess subtree going forward?
09:09 < fanquake> *versioning
09:09 < Sjors[m]1> fanquake: do you mean versioning of the interface or of the multiprocess dependency?
09:10 < 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
09:10 < Sjors[m]1> For the latter we should probably tag whatever is in v30
09:10 < fanquake> We also don't generally backport subtree updates, so this would also be new for multiprocess
09:10 < sipa> if a subtree has a bugfix that matters, it does seem reasonable to backport it
09:11 < fanquake> Sure, but that might have to be selective, rather than a full pull
09:11 < sipa> yeah, makes sense
09:11 < fanquake> so by default isn't a clean backport
09:12 < 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